>> Ага, "сообщение Эндрю Мортона о том, что проблемы производительности файловых систем, основанных
>> на FUSE, нельзя решить только за счет перемещения их кода в
>> ядро".
>> Стало быть критерии оценки ФУЗЕ должны быть те же, что и к
>> ядерным ФС. А по ним они сливают.
> По кому по "ним"? По каким ещё, кроме скорости? Всё, что я
> услышал от здешних ораторов, это отсылки к скорости работы и апологетика
> скорости работы как единственно верного критерия.

А от апологетов ФУЗЕ основной аргумент скорость и безопасность написания.

>>>> Ага, упустить или скрыть контекст дискуссии из которого взята фраза Торвальдса. Не
>>>> знает или намеренно вводит в заблуждение.
>>> И каков же контекст, просветите?
>> См. выше.
> Посмотрел и не пойму, какие ко мне претензии. Вы их сформулируете, быть
> может?

Фраза и Торвальдса  и Мортона в контексте обсуждения переноса ФУЗЕ ФС в ядро.

>>> Ошибки в ядерном драйвере потенциально ведут к краху системы или отказу подсистемы.
>>> Ошибка в FUSE-драйвере - к краху только драйвера, с возможностью последующего
>>> перезапуска.
>> Повторение мантры не доказательство. Тем более устойчивость к последствиям краха не единственный
> Вы с фактами свои заявления сопоставляете? Это многократно, эмпирически доказанная истина.

Сопоставляю. Проблем с ядерным драйвером на порядок меньше чем с ФУЗЕ.

> Я вам больше сказжу: при отказе ядерного драйвера все процессы, которые
> обращаются к файлам на отказавшем разделе, входят в контекст ядра и
> висят там безвозвратно, что не позволяет перезапустить не только драйвер, но
> и приложения. Впрочем вам-то, умудрённому опытом нетеоретику, об этом откуда знать...

Ну да, мы, умудренные опытом нетеоретики, используя прямые средства просто не продим по ФУЗЕ граблям.

>> пункт в понятии "надежность". Да и банально ядерная ФС часто не
>> заметит тех проблем, что приведут к краху ФУЗЕ, банально проца не
>> хватило и упс.
> Проца не хватило? Стыда у вас не хватило, такую чушь нести.

Аргумент железный. У вас конечно ФУЗЕ систему не грузит, а мы просто готовить не умеем.

>> Вопервых смотря какого пользователя.
> Оставьте это беспомощное сотрясание нумерацией. Во-первых, беспредметная чушь. Во-вторых,
> FUD.

С вашей стороны да, ибо аргументов у вас нет.

>> Вовторых вероятность существования неизвестной
>> уязвимости в ядерном драйвере меньше, нежели в случае ФУЗЕ.
> С чего бы это вдруг, торагой друг?

С того, что ядерные дрова используются гораздо чаще ФУЗЕ. Потому проблемы при наличии оных более вероятно обнаружить в коде ядерных дров.

>>> FUSE-драйвер можно писать на типобезопасных, верифицируемых языках вроде Ada/SPARK.
>> Втретьих Ада для писания ФУЗЕ можно, но смысла немного. Да и чаще
> Надо думать, смысла немного, потому что немного. Гладиолус. Кого вы тут мантры
> читать отучали?

Вы хотите сказать опытных ада-разработчиков так много, что они еще согласятся ФУЗЕ писать?
Одним аргументом в пользу ФУЗЕ была простота написания ФУЗЕ софта, при использовании АДА, этот плюс исчезнет и разницы между ФУЗЕ и ядерным драйвером не будет. Если для вас это гладиолус, то флаг вам в руки и 42 навстречу.

>> всего ФУЗЕ используют для наиболее простого решения задачи, забывая, что нередко
>> простота хуже воровства.
> Характер использования FUSE кем-либо не характеризует все случаи его использования.

Всегда есть альтернатива использованию ФУЗЕ. Причем более прямая альтернатива.

>>> 3. Скорость разработки и свобода выбора инструментария
>>> Драйвер ядра придётся писать на Си для пространства ядра - медленно, дорого,
>>> неудобно тестировать. FUSE-драйвер можно писать на более удобных языках, с более
>>> развитыми средствами профилирования, тестирования и отладки.
>> А это специфика ядра. Хочешь надежно - не жлобись на время, знания
>> и деньги.
> Это специфика программирования на Си под монолиты. Которую вы признаёте, но кишка
> тонка сказать об этом прямо. Поэтому вы встаёте в позу и
> заворачиваете пассажи на тему, кому и на что не следует "жлобиться".

Ну конечно, вы видимо можете писать быстро и надежно и дешево, а вот остальные могут только два из трех пунктов реализовать.

>>> 4. Адаптация удобных традиционных абстракций
>>> Вещи, вроде s3fs, sshfs, copyfs - надёжнее, безопаснее и быстрее пишутся под
>>> FUSE.
>> Надежнее и безопаснее пишутся? Это что то новое.
> Ещё бы вам знать. Конечно новое.

Ну да фантастика она всегда новая. Сказки от дядушки Примуса.

>> Пишуться то они пишуться,
>> но быстро, надежно и безопасно работать таки не работают.
> Потому что не работают. Сколько-нибудь достойно аргументировать вы в принципе способны?

Аргументов было достаточно. Sapienti sat