> Ага, "сообщение Эндрю Мортона о том, что проблемы производительности файловых систем, основанных
> на FUSE, нельзя решить только за счет перемещения их кода в
> ядро".
> Стало быть критерии оценки ФУЗЕ должны быть те же, что и к
> ядерным ФС. А по ним они сливают.По кому по "ним"? По каким ещё, кроме скорости? Всё, что я услышал от здешних ораторов, это отсылки к скорости работы и апологетика скорости работы как единственно верного критерия.
>>> Ага, упустить или скрыть контекст дискуссии из которого взята фраза Торвальдса. Не
>>> знает или намеренно вводит в заблуждение.
>> И каков же контекст, просветите?
> См. выше.
Посмотрел и не пойму, какие ко мне претензии. Вы их сформулируете, быть может?
>> Ошибки в ядерном драйвере потенциально ведут к краху системы или отказу подсистемы.
>> Ошибка в FUSE-драйвере - к краху только драйвера, с возможностью последующего
>> перезапуска.
> Повторение мантры не доказательство. Тем более устойчивость к последствиям краха не единственный
Вы с фактами свои заявления сопоставляете? Это многократно, эмпирически доказанная истина. Я вам больше сказжу: при отказе ядерного драйвера все процессы, которые обращаются к файлам на отказавшем разделе, входят в контекст ядра и висят там безвозвратно, что не позволяет перезапустить не только драйвер, но и приложения. Впрочем вам-то, умудрённому опытом нетеоретику, об этом откуда знать...
> пункт в понятии "надежность". Да и банально ядерная ФС часто не
> заметит тех проблем, что приведут к краху ФУЗЕ, банально проца не
> хватило и упс.
Проца не хватило? Стыда у вас не хватило, такую чушь нести.
> Вопервых смотря какого пользователя.
Оставьте это беспомощное сотрясание нумерацией. Во-первых, беспредметная чушь. Во-вторых, FUD.
> Вовторых вероятность существования неизвестной
> уязвимости в ядерном драйвере меньше, нежели в случае ФУЗЕ.
С чего бы это вдруг, торагой друг?
>> FUSE-драйвер можно писать на типобезопасных, верифицируемых языках вроде Ada/SPARK.
> Втретьих Ада для писания ФУЗЕ можно, но смысла немного. Да и чаще
Надо думать, смысла немного, потому что немного. Гладиолус. Кого вы тут мантры читать отучали?
> всего ФУЗЕ используют для наиболее простого решения задачи, забывая, что нередко
> простота хуже воровства.
Характер использования FUSE кем-либо не характеризует все случаи его использования.
>> 3. Скорость разработки и свобода выбора инструментария
>> Драйвер ядра придётся писать на Си для пространства ядра - медленно, дорого,
>> неудобно тестировать. FUSE-драйвер можно писать на более удобных языках, с более
>> развитыми средствами профилирования, тестирования и отладки.
> А это специфика ядра. Хочешь надежно - не жлобись на время, знания
> и деньги.
Это специфика программирования на Си под монолиты. Которую вы признаёте, но кишка тонка сказать об этом прямо. Поэтому вы встаёте в позу и заворачиваете пассажи на тему, кому и на что не следует "жлобиться".
>> 4. Адаптация удобных традиционных абстракций
>> Вещи, вроде s3fs, sshfs, copyfs - надёжнее, безопаснее и быстрее пишутся под
>> FUSE.
> Надежнее и безопаснее пишутся? Это что то новое.
Ещё бы вам знать. Конечно новое.
> Пишуться то они пишуться,
> но быстро, надежно и безопасно работать таки не работают.
Потому что не работают. Сколько-нибудь достойно аргументировать вы в принципе способны?
