вот объясните почему бинарные модули вставлять в ядро можно, а файловую систему включить под свободной лицензией невозможно из-за какой-то там несовместимости....
>ну это то как раз легко объяснить. Кто баги будет фиксить и меинтейнить?
Так там же был русский меинтейнер, кторый даже поначалу что-то пилил. А потом я на эту драму забил и про сейчас не в курсе.
Но ведь если на твою работу будут в течении трех лет класть - у кого угодно же руки опустятся.
>Потому же, почему reiser3 убрали из умолчания в некоторых дистрах.
Потому что создатель жену убил, или были другие причины.
Я даже не могу представить адекватную причину, по которой btrfs и ext4 были в ядре, а рейзера не было.
>btrfs и ext4 есть кому поддерживать, reiser4 - некому
Как я уже писал - было кому, он в мейлинг листе с kernel team даже переписывался, и все-все объяснял, и со всеми претензиями разобрался. Но проект все-равно зарубили.
Впринципе, теоретически, ничто не мешает сделать серию патчей для ядра и основную часть реализации zfs выпустить в виде модуля. И патчи уже чтобы пользователь сам накладывал и модуль подгружал. Получится нечто похожее на проприетарные драйверы для linux.
Но кроме теории, есть некоторые жизненные особенности:
-авторитетные дядьки, тётьки и даже студенты не захотят допиливать zfs для линукса, зная о сомнительности будующего такого допила
-как ни крути, но подобный способ проканает нормально только в source-based дистрибах, так как пересобирать ядра в бинарных дистрибах непривыкли люди.
-довольно много работы по качественному портированию кода в ядро. Всё таки драйвер zfs пришёл из solaris, где ядрёное апи несколько иное.
Если скомбинировать пункты 1 и 3, то напрашивается вопрос: а кто тогда будет допиливать такой старт до уровня продакшин? А если скомбинировать все 3и пункта, то спрашивается - а кто будет тестировать допиленное? Ведь едва ли red hat, novell, cannonical заюзают такой сомнительный продукт.
Ну а поскольку сей продукт важен лиш на критических системах, где red hat и novell короли, то на кой это всё надо?
Ну вы поняли да, что сами сказали?:) Если нет, то кратко: никаких гарантий на это поделие, никакой поддержки и худшее что может быть - отсосная производительность. Да, теоретически можно и через fuse сделать хорошо. Но лучше, отказаться от fuse и реализовать свой метод общения с ядром и вынести код драйвера либо опять же в userspace, либо в ядро.
В любом случае для оптимальной работы нужно реальное тестирование на реальных серверах. А до тех пор, пока на zfs патенты, как бы она ни была реализована - ни red hat, ни novell, ни любая другая контора не включит реализацию zfs в свой продаваемый продукт.
Ну допустим даже здесь об этом упоминается - http://zfs-on-fuse.blogspot.com/
Хотя девелоперы, которые бы могли взяться за реализацию zfs с нуля под linux как раз и говорили что тема патентов первичная, а уже потом речь идёт о несовместимой лицензии. На крайний случай ведь никто не мешает часть кода вынести в юзерспейс, по крайней мере на начальной стадии реализации с чистого листа. И шаг за шагом отказываться от унаследованного кода. Но это не делается именно по причине патентов. Также как сейчас реализацию фата стараются кастрировать, чтобы не возникало желания преследовать.
Впрочем уверен что уважаемый iZEN вкурсе этого говна, и пост сей написал просто чтобы показать, что linux якобы имеет проблемы, которые по его мнению не имеют другие системы, например проблему лицензии.
> Так ведь бинарные модули не в составе линукса идут.
бывает что и прямо в ядро вставляют бинарный код (именно код который выполняется самим ядром а не firmware какое-нибудь для внешних устройств). Пример -- ath_hal из madwifi до того как они недавно открылись. Но это не вызывало проблем с включением в дистрибутивы.
>Насколько я понимаю, это фирмвари а не модули. Ядро не исполняет этот код, а грузит в девайсы.
А мне казалось, что фирмваре - это то, что находится в /lib/firmware, а все остальное - это дрова, то есть вполне себе модули
Если вы правы и в ядре закрытые бинарные модули, то придётся переходить на GNU HURD? Ведь это значит, что ядро Linux нарушает GPL. Я ж этого не перенесу. :'-(
>Если вы правы и в ядре закрытые бинарные модули, то придётся переходить на GNU HURD? Ведь это значит, что ядро Linux нарушает GPL. Я ж этого не перенесу. :'-(
Зачем сразу на HURD? Можно на соляру, бсд и kernel32.dll - там никто ничего не нарушает
> Ну вы поняли да, что сами сказали?:) Если нет, то кратко: никаких гарантий на это поделие, никакой поддержки и худшее что может быть - отсосная производительность. Да, теоретически можно и через fuse сделать хорошо. Но лучше, отказаться от fuse и реализовать свой метод общения с ядром и вынести код драйвера либо опять же в userspace, либо в ядро.
У реализации ZFS под FUSE есть одно существенное преимущество перед реализацией в виде модуля ядра Linux: она существует.
Кстати, я тут уже некоторое время копаюсь в FUSE и постепенно прихожу к выводу, что сделать хорошо под FUSE невозможно -- слишком много вызовов в юзер-спейс.
> В любом случае для оптимальной работы нужно реальное тестирование на реальных серверах. А до тех пор, пока на zfs патенты, как бы она ни была реализована - ни red hat, ни novell, ни любая другая контора не включит реализацию zfs в свой продаваемый продукт.
Ну вы как маленький, чесслово. :) Санки на то и рассчитывали, что в Линукс ZFS в продакшен никто использовать не будет. Это конкурентное преимущество Соляриса и только его (всякие БЗДи никому не интересны, особенно в ынтерпрайзе).