Розробник Linux Лінус Торвальдс оголосив про випуск Linux 6.19, що стане останнім оновленням у цьому циклі ядра. Нова версія додає підтримку сучасного драйвера AMDGPU для старіших відеокарт AMD GCN 1.0 та 1.1, таких як GPU серії Radeon HD 7000, а також підтримку Vulkan через драйвер RADV і покращене керування живленням.

Ключові нововведення версії 6.19

Linux 6.19 також включає покращену підтримку HDR завдяки додаванню DRM Color Pipeline, оновлений драйвер Asus Armoury, розширену підтримку новіших чіпів Intel Wildcat Lake та Nova Lake, шифрування з’єднань PCIe та автентифікацію пристроїв та інші вдосконалення.

Підтримка старіших відеокарт AMD

Ключовою особливістю цього оновлення стала підтримка сучасного драйвера AMDGPU для відеокарт AMD на базі архітектури GCN першого та другого покоління. Це означає, що власники старіших GPU серії Radeon HD 7000 тепер зможуть використовувати сучасний драйвер замість застарілого radeon, отримуючи при цьому підтримку Vulkan через RADV і покращене керування енергоспоживанням.

Анонс переходу на Linux 7.0

Разом із запуском Linux 6.19 Торвальдс також анонсував початок нового циклу ядра з наступним оновленням. «Як люди здебільшого зрозуміли, я досягаю точки, де мене бентежать великі числа (знову майже закінчуються пальці на руках і ногах), тому наступне ядро називатиметься 7.0», — пише Лінус у примітці до оновлення.

Наступне оновлення може включати ще більше покращень для GPU AMD, підтримку дисплеїв для чіпів Intel Nova Lake та Qualcomm Snapdragon 8 Elite Gen 5, а також розширену підтримку моніторингу сенсорів для материнських плат Asus серед інших змін.

Коли очікувати оновлення

Користувачі дистрибутивів Linux з постійними оновленнями, таких як Fedora та Arch, можуть очікувати найновішого оновлення ядра найближчим часом через звичайні системні оновлення. Дистрибутиви без моделі постійних оновлень можуть отримати оновлення ядра пізніше.

Ця стаття Вийшов Linux 6.19 з анонсом майбутньої версії 7.0 раніше була опублікована на сайті CyberCalm, її автор — Наталя Зарудня

Багато програмістів настільки молоді, що ніколи не знали світу без Git та розробницьких сайтів, побудованих навколо нього, таких як GitHub та GitLab. Вам варто радіти, і то дуже, що Лінус Торвальдс відчув необхідність створити кращу систему контролю версій (VCS).

До цього всі використовували системи управління вихідним кодом (SCM) першого покоління, такі як Revision Control System (RCS), що було… м’яко кажучи, болісно. Потім у 1986 році з’явилася Concurrent Versions System (CVS), а згодом, у 2000 році, – Subversion (SVN). Того ж року з’явився BitKeeper, колись система контролю версій (VCS) з відкритим кодом, який став першим SCM для Linux.

До цього Торвальдс задовольнявся тим, що впорядковував код Linux вручну. Але, як зауважив розробник Ларрі Маквой, до 1999 року Торвальдс був на межі вигорання. Проблема? Проблема була в тому, що самого Торвальдса масштабувати було неможливо. Йому потрібні були правильні інструменти, щоб розподілити навантаження. Маквой вважав, що відповіддю була його власна програма SCM, BitKeeper. Торвальдс не був так упевнений. Він хотів продовжувати робити все так, як робив завжди.

Дилема BitKeeper

Перенесемося в 2003 рік, і це вже інша історія. Ядро Linux 2.4 вийшло із запізненням, великим запізненням, а реліз 2.6 просувався ще повільніше. Тож Торвальдс нарешті перейшов на BitKeeper.

Спочатку все працювало чудово, але ложкою дьогтю завжди було те, що BitKeeper був пропрієтарною програмою. Щоправда, існувала безкоштовна версія BitKeeper, яку можна було використовувати лише з проєктами з відкритим кодом, але вона мала суттєві проблеми.

Як зауважив тоді розробник ядра Linux та редактор Linux Weekly News (LWN) Джонатан Корбет: “Ларрі хотів і рибку з’їсти, і на… сісти. Він справді хотів підтримувати розробку вільного програмного забезпечення — доки це ПЗ не загрожувало його власній бізнес-ніші. … Щоразу, коли BitMover [компанія Маквоя] відчувала загрозу своїй бізнес-моделі,” вона змінювала умови ліцензування “до такої міри, що ліцензія BitKeeper стала відомою в деяких колах як ‘ліцензія «не зли Ларрі»’.

Як прокоментував роками пізніше на Ycombinator Браян Кентрілл, відомий розробник і технічний директор Oxide Computer: “Велика іронія полягає в тому, що Ларрі був одним із найперших прихильників відкриття вихідного коду операційної системи в Sun… Тож, з одного боку, історію BitKeeper у контексті відкритого коду можна вважати майже грецькою трагедією за своїм масштабом”.

У 2005 році Ендрю Тріджелл, розробник ядра Linux, спробував здійснити зворотне проєктування протоколів BitKeeper, щоб створити клієнт BitKeeper з відкритим кодом. Це стало останньою краплею для Маквоя, який згодом припинив підтримку безкоштовної версії BitKeeper.

Однак Торвальдс не вважав справедливим звинувачувати Маквоя у розриві. У дописі до списку розсилки ядра Linux (LKM) він написав: “Не звинувачуйте BitMover, навіть якщо це, ймовірно, буде дуже поширеною реакцією. Ларрі, зокрема, справді намагався все налагодити, але дійшло до того, що я вирішив, що не хочу опинитися в ситуації, коли доводиться склеювати дві частини, які, здавалося, вимагали забагато клею”.

Незалежно від того, хто винен, Linux залишився без SCM. Що робити?

Створення Git

Відповіддю Торвальдса стало створення справжньої альтернативи VCS з відкритим кодом: Git. Всього за 10 днів він розробив робочу версію Git, перший коміт якої було зроблено 7 квітня 2005 року.

Звичайно, він думав про це вже деякий час. Конфлікт із BitKeeper назрівав майже від самого початку. У недавньому інтерв’ю GitHub Торвальдс сказав, що перед ним стояло питання: “Як мені зробити щось, що працює навіть краще, ніж BitKeeper, але робить це не так, як BitKeeper?”

Як тоді сказав Торвальдс, він не хотів змінювати інструменти управління конфігурацією програмного забезпечення; однак у нього не було іншого вибору, крім як відмовитися від BitKeeper і створити власну систему. “Сама назва насправді не має значення. Торвальдс пожартував, що це може бути “випадкова комбінація з трьох літер, яка вимовляється і фактично не використовується жодною поширеною командою Unix. Той факт, що це неправильна вимова слова ‘get’, може бути або не бути релевантним”. Або “дурний. нікчемний і мерзенний. Просто. Обирайте на свій смак зі словника сленгу”. Або “глобальний інформаційний трекер: [якщо] у вас гарний настрій, і він справді працює для вас. Ангели співають, і світло раптом заповнює кімнату”.

Ангели чи ні, але Торвальдс тоді не був упевнений, що Git стане постійною заміною. “Це молодий проєкт, і потрібен час, щоб речі дозріли. Це триватиме роками, якщо припустити, що жодна з інших SCM з відкритим кодом зрештою не виявить себе достатньо спроможною, щоб ми просто вирішили, що Git був хорошим тимчасовим мостом”.

Тривалий вплив

Гадаю, ми всі можемо погодитися, що Git виявився чимось більшим, ніж тимчасовий міст. За останніми підрахунками 6sense, Git займає понад 87% ринку SCM.

Зараз усі думають, що те, що робить Git, є очевидним. Тоді це було не так. Торвальдс сказав: “Те, що ви зараз кажете, що це очевидно, я думаю, тоді це не було очевидним. Я думаю, однією з причин, чому людям було дуже важко використовувати Git, було те, що більшість людей, які починали, не використовуючи Git, мали досвід роботи з чимось на зразок CVS. А я підійшов до мислення Git з точки зору людини, що працює з файловими системами, маючи зневагу і майже ненависть до більшості систем контролю версій, тому я зовсім не був зацікавлений у збереженні статус-кво”. Сьогодні його бачення управління програмним кодом стало тим способом, яким ми майже всі працюємо з кодом.

Досить кумедно, але Торвальдс сказав у 2019 році, що хоча він пишається створенням Linux, те, що робить його “щасливим щодо Git, – це не те, що він захопив світ. Це те, що ми всі маємо сумніви в собі, так? Ми всі думаємо: ‘А чи ми справді чогось варті?’ І одним із сумнівів, які я мав щодо Linux, було те, що це була просто реімплементація Unix, так? Чи можу я дати вам щось, що не є просто кращою версією чогось іншого? Git довів мені, що можу. Мати два проєкти, які наробили багато галасу, означає, що я не ‘поні з одним трюком'”.

Сьогодні майже вся розробка з відкритим кодом використовує Git. Хоча Linux тісно пов’язаний з Git, усі операційні системи тепер підтримують його.

Чому Git став таким успішним?

Децентралізований дизайн Git був революційним на той час. Він дозволив розробникам працювати незалежно та ефективно синхронізувати зміни. Цей підхід трансформував спосіб співпраці команд розробників та розробки проєктів. “Git став практично синонімом контролю версій”, – сказав Скотт Чакон, засновник GitHub, який вважає, що Git змінив хід його життя.

Крім того, як написав на LinkedIn Мохамед Яссер, архітектор програмного забезпечення: “Git — це не просто система контролю версій; це основа довіри. Запис бачення. Простір, де кожна гілка відображає думку, а кожен коміт несе намір”.

Вступаючи у своє третє десятиліття, Git продовжує формувати майбутнє розробки програмного забезпечення. Навіть якщо ви ніколи в житті не написали жодного рядка коду, ви використовували результати роботи, яка контролювалася у програмістському жорні Git.

Ця стаття Лінус Торвальдс створив Git за 10 днів – і навіть не уявляв, що він проіснує 20 років раніше була опублікована на сайті CyberCalm, її автор — Наталя Зарудня