Комментарии 78
Жабогадюкинг
Великодушный диктатор, все такое
Да, и в данном случае он совершенно прав.
Заморозка добавления новой функциональности производится не из-за личного каприза, а чтобы на следующей стадии отловить все добавленные вместе с ней проблемы, и отдать пользователям достаточно стабильный релиз.
Прав, но такой стиль управления слишком завязан на личность. Завтра его автобус собьёт и ой.
> собьёт и ...
... выберут нового лидера разработки из числа активных мантейнеров. И он тоже не будет принимать патчи с новой функциональностью во время окна стабилизации нового релиза.
А не проще сделать форк или хотя бы собственную ветку и уже в ней плевать на правила окна стабилизации релиза, принимая новые фичи хоть прямо перед выкладкой?
Уверен, она станет пользоваться огромной популярностью у пользователей ))
Может она будет пользоваться популярностью у гиков, желающих посмотреть на новый функционал, но никак у большей части пользователей, которым важна стабильность, и неожиданные баги и уязвимости ни к чему
Больше фрагментации богу фрагментации? Так себе идея. Выбор нужных функций в одном продукте, совсем не то же самое, что выбор из многих, пусть и похожих, продуктов.
Договариваться надо, без подобных радикальных решений (с обоих сторон).
Есть правила работы над основной веткой ядра, включающие в себя заморозку принятия новых фич перед релизом. Правила, практически стандартные для индустрии, выстраданные и проверенные тысячами суммарных человеко-лет, потраченными на разгребание свежих багов в сыром продукте.
Есть ФС, основной автор которой кладёт на эти правила, причём уже не первый раз.
Как вы предлагаете с ним договариваться? Тратить время всех вышестоящих мантейнеров на каждый его патч, внимательно проверяя, не засунул ли он опять туда новые фичи?
Не хочет играть в общей песочнице по общим правилам - пусть идёт играть в свою личную. Или сначала договаривается со всеми про изменение этих правил. А то, блин, "я художник, я так вижу".
Как вы предлагаете с ним договариваться?
Очень просто. Вместо выкидывания автора из проекта, написать ему что-то вроде - Введение в проект ваших новых правок отложено до следующей версии. И пусть себе пишет на здоровье. Заморозить их принятие, как это правилами и оговорено. Зачем от сотрудничества отказываться-то?
В целом, прекрасно понимаю и Л.Т., и желание автора максимально быстро ввести обновление.
Но о чём они договорились в личной переписке... Так что, вполне могли разобраться вдрызг, более того, ЛТ весьма авторитарный и если шоея попала под хвост - значит так будет.
ЗЫ. Несколько отстал от всех новинок, в чём ценность bcachefs, из-за чего весь сыр-бор?
За 30+ лет много чего было как реализовано, так и позже выкинуто, не смотря на актуальность.
У Линуса банально нет времени уговаривать каждого, что принятые правила разработки в основной ветке надо соблюдать. Его работа - управлять развитием большого и сложного проекта, а не работать воспитателем в детском саду.
Правила известны, если человек упорно продолжает их нарушать после нескольких замечаний - пусть отдохнёт и подумает.
Зачем от сотрудничества отказываться-то?
Затем, что автор упорно, не первый раз нарушает принятые правила. И этим тратит время и силы вышестоящих мантейнеров, вынужденных внимательно перепроверять, что он там присылает.
Из проекта его никто не выкинул, его выкинули из основной ветки ядра, работа над которой ведётся в соответствии с принятыми правилами, на которые автор упорно класть хотел.
Задача руководителя (любого уровня) в том и состоит, чтобы разгребать подобного рода нюансы (а иначе зачем он нужен-то, если всё и так идёт как написано?). Кто-то, как автор bcachefs, бежит впереди паровоза, от кого-то наоборот, не доплачешься нужного, кто-то нередко косячит, но человек в целом нужный/полезный и т.д. и т.п. И главный, должен это учитывать и нивелировать. Тем более, если это уже не впервые.
Может где-то в идеальном мире всё и происходит исключительно по правилам, как вы говорите, но в этом мире, я не знаю вообще ничего идеального. И очень печально, что из-за таких стычек режется функционал.
А если нюанс не разгребается, потому что создающий его человек последовательно игнорирует, что ему говорят - то задача руководителя убрать этого человека из проекта. В коммерческой компании этому соответствует увольнение или перевод на другую должность.
Руководитель точно не обязан обеспечить каждому, кто захочет, участие в проекте, несмотря ни на какие закидоны. Мы же говорим не об уроке рисования в классе для детей с особенностями развития?
печально, что из-за таких стычек режется функционал
Не особенно. Ядро Линукс уже умеет ну очень много всякого. Тех же новых модных ФС с разными плюшками в нём как минимум ещё 2 - btrfs и zfs, плюс часть этой функциональности есть в LVM. zfs, кстати, развивается как сторонний проект вне основной ветки ядра(лицензионные заморочки) - и вроде успешно живёт. Тут скорее пора думать, что и как выкидывать или переводить в отдельные проекты, чтобы вся эта конструкция под собственной тяжестью не рухнула.
почему фрагментация? просто патчи к ядру от стороннего разработчега...
раньше это было обычным делом при выходе новой версии ядра - пройтись по любимым патчам и посмотреть вышли ли новые версии патчей для нового ядра...
Вы частично правы.
Линус сам давно заметил, что ему заглядывают в рот, потому даже отстранялся от управления.
На деле же, трудно не вести себя так, когда ты, в общем-то, автор этого творения. Наверное есть некоторая излишняя опека над проектом.
С обратной стороны.
А не правы вы с той стороны, что Линус озвучивает решение не исходя из просто хотелок, а всё же из принципов, которые выработаны (И как мы видим, даже не блокирующе жесткие).
Линуса однажды не станет в любом случае. А принципы останутся.
Линуса однажды не станет в любом случае. А принципы останутся.
Не факт, что Линукс надолго переживёт Линуса.
На Линукс, как на основу для своего стека, полагается огромная куча богатых и серьёзных компаний, от гугла и фейсбука до опенэйай и майкрософта(в Azure). Если не случится какого-нибудь апокалипсиса, то Линукс гарантированно переживёт всех своих нынешних мантейнеров.
Почти любая программа под Линукс без труда переносится например, на macOS (в большинстве случаев простой перекомпиляцией). Что показывает, что дело в POSIX API, а не в ядре. Поэтому выкинуть Линукс и заменить другой Unix-совместимой системой – дело в большинстве случаев не особенно сложное. Во всяком случае, проще, чем провозглашённый рядом лиц переход с C/C++ на Rust.
Скорее всего, будущие мейнтейнеры просто не захотят разбираться с наследием старых и заменят ядро целиком.
Допустим, написали новую ОС, быструю-модную-молодёжную. А кто будет тратить тысячи человеко-лет, чтобы написать под неё драйвера ко всему актуальному железу и протестировать их достаточную стабильность для продакшена на том самом железе?
Производителям железа тратить деньги и время на разработку под неизвестную ОС нафиг не надо. Портировать из того же Линукса? Нереально без очень серьёзной переработки, модули жёстко завязаны на низкоуровневое API ядра.
А кто будет писать драйвера к новому железу под линукс? Это естественный процесс обновления.
Производители нового железа пишут для него драйвера для распространённых ОС, которые потребители будут запускать на этом железе.
Для никому неизвестной ОС они ничего писать не будут, пока она не наберёт достаточную популярность, чтобы наличие драйвера для неё влияло на продажи.
А популярность она не наберёт, пока не будет нормально поддерживать всё актуальное железо, спокойно заменяя собой линукс.
Кроме того, она должна при этом сразу иметь какие-то настолько существенные преимущества, что они оправдают затраты времени и денег на переход.
Послушайте, есть часы приемов и из придумали не спроста.
Больше того, новый функционал требует более тщательной и глубокой проверки. Но извините мы не робот. У меня есть часы приема по большим вопросам, а когда я не принимаю, я пью пиво например. И если у нас есть дюже активный экспериментатор, то я его поздравлю за энтузиазм, но пиво стынет.
Да он то прав. Странно, что разговор этот заходит сейчас, когда поддержка этой ФС уже встроена, и на неё полагаются столько людей.
Те быть это на начальном этапе, было бы все суперпонятно. Но автор, что, только сейчас начал закидоны?
А Линус, несмотря что мнение высказывает верное, будучи диктатором (о чем я и напомнил) понимает, как всякий диктатор, что от него зависят юзеры по всему миру.
Вариант, что ФС вынесут в отдельный пакет/модуль - жизнеспособный. Тогда его будут по умолчанию встраивать авторы всех дистров, поскольку должны (ожидается, что должны бы) поставлять новые ядра с теми же фичами, как и старые.
А иначе у многих в мире ято-то, да навернется.
Её не объявляли стабильной, и нацеленные на LTS дистрибутивы типа RedHat и Ubuntu никогда её не рекомендовали для продакшена.
Да даже сами авторы пишут https://bcachefs.org/FAQ/ :
> Is bcachefs stable for production use? Bcachefs can currently be considered beta quality.
Очень вряд ли кто-то держит её в боевом продакшене(не путайте с bcache, который доступен и стабилен уже много лет).
Если вы внимательно посмотрите на самые долгоживущие проекты в ИТ, то вы, возможно, с удивлением для себя обнаружите, что они были построены на очень жёстких принципах, и либо одном человеке, либо очень закрытом совете, которые все эти продукты поддерживали и развивали.
Оверстрит однозначно неправ, разработка Linux это системная коллективная работа, подстраивать её под одного разработчика это безумие.
В рамках патча Оверстрита добавленная опция journal_rewind откатывала изменения в журнале для сброса ФС в более раннее состояние.
хм... Может быть, лучше было бы написать "в предыдущее" или "в одно из предыдущих"?
А. вообще, было интересно узнать про достижения в области построения файловых систем. Казалось, все принципиальные вопросы должны быть уже решены, а решения — повсюду внедрены. Разве не так?
А. вообще, было интересно узнать про достижения в области построения файловых систем. Казалось, все принципиальные вопросы должны быть уже решены, а решения — повсюду внедрены. Разве не так?
Как и с БД, универсальных решений нет и вероятно быть не может. Список принципиальных вопросов различен для разных применений (скорость записи/чтения, поддержка миллионов мелких файлов, много мелких файлов или огромные файлы, поддержка распределённости, дружелюбность к флеш-памяти или hdd, etc...), отчего любую систему можно счесть неприменимой в некотором специфическом профиле использования.
Далеко нет. У разных файловых системах разные сильные и слабые стороны: одни быстрее, другие надёжнее, третьи имеют свои особенности: встроенное сжатие данных, встроенное шифрование, ориентированность на работу с flash накопителями или вовсе специфичными
Посмотреть на них можно тут: https://wiki.archlinux.org/title/File_systems
Казалось, все принципиальные вопросы должны быть уже решены, а решения — повсюду внедрены. Разве не так?
Чтобы "повсюду", они должны быть бесплатными и универсальными (не только распределённые, не только для дорогих однотипных СХД), а кто их оплатит? Linux - это люди с горящими красными глазами или миллиарды долларов от IBM?
Теодор Тс'о (он же мейнтейнер ext4) недавно рассуждал про файловые системы только в ключе окупаемости. Sun сделала ZFS - и где теперь Sun? Оценил готовую к применению btrfs в 100 человеко-лет и услышал, что руководство никогда не одобрит разработку, если увидит это число. Новые фичи в ext4 можно, если проспонсируете; вырастут ли продажи вашего продукта из-за доработки ext4?
В Ext4 продолжают включать новые возможности, но это та функциональность, которую компании готовы финансировать, потому что окупаемость инвестиций в разработку новых возможностей имеет смысл с точки зрения затрат и выгод.
reflinks - более интересен, но я не смог найти заказчика, готового оплатить расходы на разработку, или компанию, которая считает, что продажи их продукта возрастут, если добавить reflinks в ext4.
я должен хорошо понимать, как я приношу работодателю пользу, по крайней мере, в 10 раз превышающую мою зарплату.
многие компании, приславшие своих представителей на встречу, отказались предоставить инженеров для работы над btrfs, и это, конечно, не помогло. Но, вероятно, это было связано с тем, что компании - рациональные организации, принимающие собственные решения об окупаемости инвестиций
В btrfs вкладывается фейсбук. Но фейсбуку не нужна функциональность массивов в btrfs, поэтому неготовность RAID 5/6 вроде уже достигла совершеннолетия.
Снапшоты ради-традиционных-ФС-но-без-LVM-и-лучше-чем-в-LVM в мейнлайн два раза безуспешно пытались протолкнуть. Со смазкой шансов было бы больше.
В обсуждении этой новости на Phoronix иронизируют над тем, что у Intel и AMD смазка есть ("Intel ... Linux 6.16-rc3 ... bit of feature code was pulled"[1] и ещё какие-то случаи).
Модели и концепции развиваются. В результате идут разные изменения, причём нелинейные.
"The PostgreSQL performance atop Bcachefs was still the slowest of the tested file-systems with the defaults being tested on each file-system."
Какая разница, какая производительность с настройками по умолчанию? Важно, какая производительность достигается с настройками под задачу.
Ожидаемо. Так как COW файловые системы не для СУБД.
Оценивать работу файловой системы по производительности СУБД поверх неё – в общем-то извращение. Неслучайно продвинутые СУБД поддерживают работу с голыми разделами.
Товальдс, конечно, тот ещё молодец, но если в статье описана реальность, как она есть, и чел перед релизом присылает крупные патчи в уже стабилизированное ядро, то претензии Торвальдса по этому вопросу обоснованы.
Linus не прав. Нельзя применять столь радикальные меры к живому, нужному, грамотному и востребованному проекту. Исключение утилит и всего, что связано с этой ФС, из кодовой базы ударит по тысячам пользователей системы. Жизнь Кента и Линуса от этого не особо изменится. Думаю, что у Линуса нет морального права выбросить проект из кода основной ветки ядра.
что у Линуса нет морального права выбросить проект из кода основной ветки ядра.
Именно у него такое право есть, и он им пользуется по делу.
Если в основную ветку принимать каждый "живой, нужный и востребованный проект", который плавать хотел на соблюдение установленных там правил - то через некоторое время это основная ветка превратится в огромный сборник багов и недоделанных фич.
Исключение утилит и всего, что связано с этой ФС, из кодовой базы ударит по тысячам пользователей системы.
Да в общем-то не особо. Просто будут ставить отдельно.
Весь вопрос-то на самом деле в том, насколько соответствуют друг другу принципы дистрибуции ядра и этой ФС.
Как бы не наезжали на характер господина Торвальлса, но его стиль единственго верный в сложных проектах. Большинству людей пока не устроишь выволочку - они мозгом думать не хотят. И верят что все должны решать только их проблемы, потом он просто идет пить пиво и ни разу не волнутся о том что создал дополнительную внеплановую работу остальным. Тут дело не в разработке как таковой, а в любом сложном проекте, нянькаться со всеми никакого времени не хватит.
На данном этапе развития Linux как ядро мало влияет на пользовательский опыт обычного пользователя.
У линукса мизерная доля на десктопе из-за фрагментированного и не всегда стабильного, собственно, десктопного софта под линукс. Ну и из-за легаси - если дорогая нужная проф. прога есть только под винду, то пользователь поставит винду; если пользователи ставят винду, то прогу будут делать для винды.
Стабильность или функциональность ядра - точно не те факторы, что тормозят приход линукса на десктоп.
У линукса минимальная доля, потому что пользователь не смотрит что там ядро, а что драйвера или ещё какой-то внешний софт, он пользуется продуктом. А как готовый продукт, линукса для десктопа вечно сломанный и багованный кусок даже на самых популярных дистрибутивах в "готовых" сборках.
Ну и сразу отвечаю на дефолтное возражение - рад, что у вас такая же нога, но не болит
Ядро линукс является наиболее распространённым из всех существующих ядер операционных систем, о чем вы говорите.
Только 2 замечания
Линус Товальдс прав в подходе к промышленной разработке, но монолитное ядро и один единственный мейнтейнер такого монстра уже не вывозит,
Bcachefs не нужен, пользовал 10 лет назад как безальтернативной решение, один раз потерял все вместе с SSD диском, но и скорости по тестам были прям сильно хуже целевых. Потом вышла новая версия LVM и на новой системе уже использовал это решение. Сейчас LVM и ZFS дают результаты не хуже (не даю зуб, но по интернетам так и есть) и при этом все как-то лучше интегрированно
У ZFS есть пачка недостатков даже перед Btrfs, а bcacheFS задумывался как следующая итерация подхода Btrfs.
Можно про недостатки zfs?
Под линух она не в ядре и производительность из-за этого страдает
Очень ограничены возможности что-то сделать с разделом, содержащим данные, не стирая их. RAID из разделов разных размеров тоже ограничен. Ещё ZFS теряет скорость до улитки ясеня на shitted shingled HDD. В некоторых случаях RAID на таких дисках невозможно восстановить, хотя он не умер - просто операция займёт годы.
Всё перечисленное энтерпрайзу нафиг не нужно. Поэтому его и нет в ZFS. (Вроде как и архитектура не позволит уже). А вот в бюджетной системе это всё здорово помогает сэкономить на железе.
В Btrfs можно взять три диска 5 и 2 и 1 Тб, получить из них RAID1 полезным объёмом 3 Тб, набить данными, потом принести новый диск 8Тб и увеличить объём RAID1 до 8 без стирания данных или нарушения надёжности. Потом, уменьшив хранимые данные до менее 5Тб, старые диски на 1 и 2 выкинуть из массива, и остаться с 5Тб RAID1.
Чёт не очень понял, как в парадигму ZFS вписали LVM. Можете раскрыть тему поподробнее? А главное "для чего"?
10 лет назад bcachefs не было.
И связка lvm+zfs очень странная, идея zfs как раз в отказе от лишних прослоек, фс работает напрямую с накопителями, обеспечивая весь функционал lvm внутри себя
Да, спутал с bcache, там создавалось блочное устройство, на которое уже ставилась ФС
Отписываться выше, я имел в виду, что обе эти системы по отдельности поддерживают добавление кеширующих дисков. В truenas добавлял на лету парой кликов мыши. Соответственно можно продолжать использовать привычные инструмент, но с приятным дополнением
Понимаю , проходили в меньших масштабах.
5 команд откоммитились, 2 обязательно несколько ревертов и только "важные изменения" от бизнеса.
Флоу порвали.
1 я линия в сапорт накидывает после релиза.
Вводишь более строгие политики - Токс !
А тут стабильность ядра, репутация и т.д. лучше "пере*" чем "недо...".
и Т. прав. Поддержка ФС это все-таки глобальный кейс, который напрямую связан с хранением данных, а значит его глюки это потеря денег. Такое перед выкаткой всеж стоит отладить по максимуму.
Кто нибудь пользуется этой ФС, может она в ядре и не нужна?
Поверхностно, по описанию, к кэшу отношение имеет опосредованное - название уже кликбейт.
Торвальдс последовательно становится капризным диктатором
конечно же, ведь основатель и мейнтейнер такого проекта как linux обязан реагировать на каждый ишью в равной степени не отделяя чей этот ишью - от Васяна из Сызрани, или от огромного вендора типа Intel. Должен быть вежлив и писать на каждый ишью 100500 строк с извенениями и пояснениями, что бы не задеть чувства Васяна
жесть что за бред. это его право, комьюнити это приняло и выстроило нужные инструменты. Если кому-то не нравиться - делай форк, главное не оказаться очередным Патриком Фолькердингом с никому ненужным slackware.
У слаки многомиллионное комьюнити, а ты кто такой, чтобы называть их всех никем? Оверстрита ты назвал Васяном-ноунеймом, а сам ты кто такой, чем знаменит?
конечно щас господни Radish все по полкам разложит, и все его непременно послушаются. ведь господин Radish переходит на ты, и он чем-то знаменит.
ps. Фолькеринг себе в 18 году собирал денег, но не на проект, а на жизнь. На ремонт дома и оплату мед. счетов. и я был среди тех кто донатил. Но эта ситуация - это именно характеристики того что слака как коммерческий проект никому не интересна, только миллионам интузиастов на морально-волевых
Кто-то может объяснить позицию Кента? Он не первый раз упирается же.
Я понимаю, что ему не хочется поддерживать несколько веток, далеко не всегда можно сделать cherry-pick для переноса исправлений. Но почему просто не отложить патчи до следующего merge window? Это лучше, чем если его фс вообще выбросят.
Думаю, что он чувствует себя виноватым, что у кого-то могут потеряться данные из-за ошибки в ФС, которая фактически уже устранена, но багфикс не доведён до пользователей. В этом есть своя правда. Фактически он считает, что исправления, связанные с возможной потерей данных, должны иметь абсолютный приоритет.
Так буквально через несколько недель будет новый merge window
Но результат тогда войдёт только в следующий релиз ядра?
…, которые выходят каждый 2 месяца, или около того.
Я ещё могу понять ажиотаж, который возникает перед выходом версии, которая готовится стать lts, а рядовые версии ядра… На них сидят полтора гика, которые могут и обновиться, если что.
Опять же, судя по всему, риторика с потерей данных притянута за уши. Fs экспериментальная, так что мега-надёжности от неё и не ждут. А исправления не прямо-таки critical (на что Линус и указывает, после закрытия merge window принимаются только небольшие патчи, исправляющие ошибки, не нужно каждый раз тащить многокилометровые портянки с новой версией).
В общем, мои симпатии тут на стороне Линуса.
В конце концов, в чужой монастырь со своим уставом не ходят. Или ты готовишь изолированные патчи, исправляющие ошибки (и больше ничего не меняющие) в rc, или ждёшь следующего merge window. Такая модель принята в разработке Linux, время показало, что она вполне рабочая, ради одного разработчика ее никто ломать не будет.
Линус Товальдс сообщил автору Bcachefs Кенту Оверстриту, что намерен исключить код Bcachefs из ядра Linux 6.17