Комментарии 27
TLDR: Линус написал кривой GIT, где нет полноценных веток, а то, что есть нельзя закрывать, поэтому разработчики постоянно переписывают историю, и удаляют ветки после слияния, что вызывает проблемы с привязкой ревью-комментариев. Далее автор жалуется, что редакторы не умеют записывать в текстовые файлы лог операций вместо состояний, и что меркуриал ещё не изобрели.
Можете мне ответить на вопросы?
1) Какой толк от вашего корпоративного блога?
У меня представление, что блог нужен для того чтобы делиться тем, что проходит внутри компании. У вас же одни только переводы. Переводы закончились начали зачем-то документацию по фреймворкам переводить, которая уже есть в интернете.
2) Кто постоянно это плюсует? Стабильно 15-30 плюсув набирают статьи. Порой даже статья только вышла пару минут назад а уже куча плюсов.
Что до стонов про «не современно» и «отпугивает», то простите но… Это GPL. Форкайте и поддерживайте. В чем проблема-то? Если вдруг это действительно сработает, то вся жизнь планомерно перетечет в ваш огород. Только вот с учетом написанного выше (а так же воспитательного эффекта от правильного оформления патчей и умения культурно и уважительно общаться в списках рассылки) — сомневаюсь. И статья эта тому лучшее доказательство.
то простите но… Это GPL. Форкайте и поддерживайте. В чем проблема-то?
Форкать и поддерживать такой гигантский и сложные проект как Linux только из-за того, что не устраивают сложившиеся практики и процессы разработки? Вам не кажется, что это безумие? Даже если кто-то сделает такой форк с модными и современными инструментами и подходами к разработке, кто вообще будет пользоваться результатами этого сизифова труда? То есть ваше предложение (если это не шутка) выглядит абсолютно бескомпромиссно и неконструктивно.
Не очень понял суть вашего комментария.
или форк, или не форк
Это по вашему единственный компромисс? "Что-то не нравится? Вали отсюда, делай свой Linux!"? Других вариантов не рассматривается? Обычно, подобные вопросы выносятся на голосование, никто вас не пошлет с порога делать форк, обычно принято сначала конструктивно обсуждать.
Насколько я помню, против документации в reStructuredText тоже выступало достаточно много людей, но в итоге документация теперь пишется именно в этом формате с использованием Sphinx-doc.
Вали отсюда, делай свой Linux!
Никто ж не заставляет делать свой Linux. Возьмите уже существующий. Озадачьтесь актуализацией от родного проекта. Привлеките людей новыми возможностями в плане разработки. Толпа новых разработчиков сделают код лучше и все перейдут на использование вашего форка забросив старье (оставив его динозаврам). Посмотрите на толпу BSD систем. Там был именно такой путь. А если вы заранее считаете это провальным вариантом, то у меня есть вопросы к тем разработчикам, которых вы хотите привлечь… Может и правда лучше без них?
www.studiofuga.com/2019/07/18/adding-a-user-space-power-switch-to-your-embedded-linux
или
www.spinics.net/lists/devicetree/msg43880.html
что то же самое. Только вот доделать он не смог. Ладно ерунда с кодом — его бы потом поправили, но… Посмотрите на дальнейшую переписку… Это ж ужас. Вместо того чтобы просто исправить раздражающее «userspace» хотя бы просто на «user» (или лучше спросить а что написать) пошли обиды — мол я написал, я опробовал и даже в продакт засунул, а вы тут меня учить удумали… И в блоге повторяется та же обидка… И никакие новомодные системы в больших проектах от подобного не избавят.
Другое дело, что здесь совсем тривиальная задача (я сначала сам сделал, а потом решение нашел). Но знали бы вы сколько такого регулярно возникает. И опять же — список рассылки позволяет находить код очень легко. По путям, по сигнатурам… А вот найти то же самое в дебрях github'а… По крайней мере сильно сложнее.
Другое дело, что ситуация не самая приятная. Вроде разраб сделал основную работу. И вроде не взяли напрасно. Но, черт возьми, взять эту реализацию это открыть ящик пандоры и начать превращать устойчивый проект в сборище анархического кода. А так получается всем хорошо. И следы остались (для тех кто доделать захочет). И разраб сам для себя на сопровождение свой код взял. И проект даже не пошатнулся. Красота. Разве нет?
P.S.
Сейчас некогда, но наберется критическая масса таких мелочей (и будет поспокойнее в плане разработки) буду проталкивать. Переход на DTB очень много хороших вещей за бортом оставил. Уже сейчас мелочи есть и по I2C мультиплексорам, и по кодекам и даже по USB хостам. Увы, времени на все не хватает.
Я писал лишь о том, что создавать форк крупного старого проекта из-за мелочей — это неблагодарное дело. Обычно такие форки не выживают и просто забрасываются, не сумев перетянуть поток на себя, набрать критическую массу разработчиков и своих сторонников. История помнит множество таких форков. Имеет смысл делать форк только если на то есть серьёзные причины, как, например, с ffmpeg/libav или Libre/OpenOffice. В случае с Linux нет таких серьёзных причин для недовольства, потому что в принципе всех всё устраивает.
Вот сложная тема на самом деле. Одни хотят писать в ядре на плюсах, другие требуют возможности писать безопасные драйвера на Rust, третьи быстрые на Go. И вроде каждая хотелка сама по себе правильная. Если не быть Грегом или Линусом, конечно. И вроде у каждой сторонников толпа. Я, вон, на карме и рейтинге качаюсь как на волнах с такими сторонниками в комментариях общаясь (привет коллективному разуму). Так отчего бы не форкнуть? Все больше толку чем в комментариях со мной кусаться. Глядишь и меня таким образом в свои сети затянут. Разве нет? Вон Apple и Sony BSD под себя переделали и довольны. А поди тоже большой проект по началу страшил. Что мешает идти их путем?
Вот эта самая "недавняя статья" с критикой подходов чуть более чем полностью состоит из воды. Единственная конкретика (из тех, что я успел увидеть, пока мне окончательно не надоело читать эту пресноту) — это что для письма в LKML нужен аж целый почтовый клиент, который не будет делать из простого текста простыню на HTML. Вообще не описана проблема, которую Сара пытается решать, и вообще каждая её цитата в той статье — образец политического заявления (там, где высшим искусством считается сказать много слов, но при этом не сказать ничего).
Бросил читать ссылку, так и не докопавшись до сути претензий. Наверное, настоящие контрибьюторы — сущие ангелы с ангельским же терпением.
Полная ерунда. Чтобы отправить патч в ядро надо знать только две дополнительные команды: git format-patch и git send-email. Остальные требования как и в других крупных проектах. Сам многократно посылал патчи.
Разработчик sr.ht создал довольно много неплохих инструментов и туториалов для интеграции со списками рассылки. Хороший компромисс между моделью разработки ядра и жёсткими рамками GitHub/GitLab.
Linux существует уже почти три десятка лет. В ранние дни этой ОС Линус Торвальдс сам управлялся с кодом, написанным другими программистами, делающими вклад в развитие Linux. Тогда не было никаких систем контроля версий, всё делалось вручную.
Сегодня 2020 год. Три десятка лет назад — это 1990.
Год выпуска популярной системы контроля версий CVS — 1990.
Вполне вероятно что и до CVS существовали иные системы контроля версий.
Вместо
«Тогда не было никаких систем контроля версий»было бы корректнее написать «В проекте Linux тогда не использовались никакие системы контроля версий» ну или как-то так. Ну и было бы круто написать с какого времени они таки начали использоваться.
а система тем временем растет и развивается.
и, наверняка, многие из критиков и каких-нибудь «цать» лет назад и подумать не могли,
что система будет работать на миллиардах устройств — от сотового телефона до top500.
и да, никаких сложностей с посылкой патчей не существует, все предельно просто.
имею опыт с несколькими патчами в ext4.
Может ли существовать система, в которой можно описать изменения, вносимые в код, на более высоком уровне?
Конечно, есть — DARCS. Почитайте её документацию — там есть даже "алгебра патчей" с тем, что она может опознавать ситуации типа "переименование foo->bar, а тут переставили с патчем, который применил foo ещё в одном месте => заменим сами на bar". Почему не взлетела — вероятно, была чем-то ещё неудобна или сильно сложна.
И расширить git на такие вещи, конечно, можно — дополнительными метаданными коммитов типа "это форматирование", "это переименование". Но я бы предпочёл видеть это плагинами, а не основным кодом — потому что там поле непаханое вариантов вплоть до настоящего ИИ, и они должны быть сменными. (Например, на опознание, который из foo должен быть переименован, а который — нет.)
Есть ещё такое https://pijul.org/ как альтернатива git
Процесс разработки Linux: стоит ли игра свеч?