Прощай GnomeVFS, привет GIO/GVFS

> Согласен. Придумайте лучшую библиотеку vfs и ее с радостью используют гномеры и кдешники

дык это и есть fuse. Нормальных аргументов убогости fuse не было приведено.

Может по-твоему? Я как раз об этом и говорю с самого начала, прочитай тред целиком.

И вообще, если быть точным, то GLib:

> GLib Reference Manual

http://library.gnome.org/devel/glib/unstable/index.html

>дык это и есть fuse. Нормальных аргументов убогости fuse не было приведено.

Тогда уберите пелену с глаз и прочтите все заново. Скорость, фатальность ошибок в ядерной части, использование не по назначению - это все не аргумент...

BTW, в новости по ссылке, которую я цитировал, тоже Glib. Тоже облажались, да. :(

> Повторю, если вам лень это делать: вам не обязательно читать все файлы из архива, если нужны только 5, и архив поддерживает частичную разархивацию - вы можете вытащить ваши 5 файлов во временную директорию и запустить с ними внешнее приложение. А потом вытащить следующие. А затем удалить директорию. И это будет быстрее fuse. Просто используйте правильную vfs библиотеку - для ядерных задач ядро, для распаковки архивов - чистый userspace.

Я хочу запустить какой-либо скрипт или же открыть файл проекта kdevelop из архива. И я не хочу при это задумываться о том, какие для этого файлы мне надо вытащить. А никакой умный файлменеджер за меня это не сделает.

Теперь понятно, что я хочу от vfs?

>Тогда уберите пелену с глаз и прочтите все заново. Скорость, фатальность ошибок в ядерной части, использование не по назначению - это все не аргумент...

не вижу особых причин говорить о фатальных ошибках fuse, пока я не слышал о таких, да и с такой логикой можно обосрать люьой драйвер для нвоого устройтва.

насчет скорости, скажите, каким образом она просядет при хождении по smb шарам, или по ftp/sftp серверам? То, что архивы смотреть через fuse - убогость, я уже давно сказал, я и не вижу применения ему в данном случае.

так что - не аргумент

зато плюсов от fuse куча, покрывающая с головой пару сомнительных минусов

>Гномеры идут правильным путём, не устраивая революций, но двигаясь к приемлемому и архитектурно грамотному решению.

и в чем появляется "архитектурная грамотность решения"?

Да, с дефолтной темой выглядит красиво. Да, "в два клика" меняется на 'о-о-очень красиво!"

А вот пользоваться всей этой красотой - как? Почему наутилус сразу отожрал 48% памяти? Почему он окно перемещает куда захочет, когда в директорию с зажатым шифтом перехожу? Он лучше меня знает, где у меня окно должно находиться?

> Вполне стандартизированный путь. Ещё скажите, что пайпы не нужны, т.к. всё можно сделать записью в файл, а потом чтением из него.

А чем пайп отличается от файла? Тем что имени в ФС нет?

> А вы в курсе, что mountpoint и структуру VFS для FUSE... представляет ядро?

В курсе. Ядро много кому чего предоставляет ;)

KDE умирает. Его разрабатывает только Novell, которого аноны ненавидят.
Гном обошёл его по популярности на 20% в следующем году, думаю будет 3:1 в пользу Гнома

>Теперь понятно, что я хочу от vfs?

Но кто-то же за вас запустит fusemount? Начинаете путаться...

> Скорость...

Даа?.. Предположим, у нас есть программа, в ней есть функция fuckme(), которую мы вызываем в main(). А теперь предположим, что у нас есть ядро, в котором аналогичная функция fuckme() уже отлажена, доведена до ума и несколько раз перепроверена. И мы её в программе используем. Основы реализации, причём, не сильно отличаются.

Вопрос на засыпку: насколько будет отличаться скорость выполнения, и как она будет связана со скоростью разработки?

> ...использование не по назначению...

По моему, создание виртуальных ФС - это и есть назначение FUSE.

> и в чем появляется "архитектурная грамотность решения"? Да, с дефолтной темой выглядит красиво.

О! Блондинки будут рассуждать об архитектуре по внешнему виду? ;)

> А вот пользоваться всей этой красотой - как? Почему наутилус сразу отожрал 48% памяти?

А почему у меня не так? ;)

>не вижу особых причин говорить о фатальных ошибках fuse, пока я не слышал о таких, да и с такой логикой можно обосрать люьой драйвер для нвоого устройтва.

Ога, его переписывали... Правда до включения в ядро.

>насчет скорости, скажите, каким образом она просядет при хождении по smb шарам, или по ftp/sftp серверам? То, что архивы смотреть через fuse - убогость, я уже давно сказал, я и не вижу применения ему в данном случае.

При работе с ftp/sftp это удобная штука, согласен, хотя и mc vfs такое умеет. В этом случае накладные будут в том, что при вычитывании блока данных вы потенциально этот блок будете отправлять в ядро, т.к. это будет часть файловой иерархии, т.е. в 2 раза больше системных вызовов. Если блок маленький, то это может стать основным источнком тормозов (попробуйте сделать dd с размером блока в 1 кб или 100 байт).

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

>>Теперь понятно, что я хочу от vfs?

>Но кто-то же за вас запустит fusemount? Начинаете путаться...

смонтирует умный файл-менеджер. но никакеи 5 файлов из 100 он за меня выбирать не будет.

я так вижу, что по существу Вам уже возразить нечего...

>По моему, создание виртуальных ФС - это и есть назначение FUSE.

Да, только чтение архива к этому не относится - в конце концов это не виртуальная файловая система.

Хотя обладая достаточной одухотворенностью, можно все представить как файловую систему, однако это не является оптимальным решением.

Судя по всему, у вас как раз такое сознание :)

>>Но кто-то же за вас запустит fusemount? Начинаете путаться...

>смонтирует умный файл-менеджер. но никакеи 5 файлов из 100 он за меня выбирать не будет.

Вам в графической мордочке появится список файлов, который вернет библиотека vfs, а там вы сможете щелкать мышкой и выбирать.

Так понятнее? :)

> KDE умирает.

Все бы так умирали! ;)

> Его разрабатывает только Novell, которого аноны ненавидят.

Да ну? Смотрите KDE Commit Digest, любитель чтения «жёлтой прессы». ;)

> Гном обошёл его по популярности на 20% в следующем году

Машина времени LOR в действии? ;)

> думаю будет 3:1 в пользу Гнома

В России тенденция обратная (http://linuxforum.ru/index.php?showtopic=44549). Наверное, мы не сильно падки на халяву, как пиндустанцы и европейцы.

>>>Но кто-то же за вас запустит fusemount? Начинаете путаться...

>>смонтирует умный файл-менеджер. но никакеи 5 файлов из 100 он за меня выбирать не будет.

>Вам в графической мордочке появится список файлов, который вернет библиотека vfs, а там вы сможете щелкать мышкой и выбирать. Так понятнее? :)

Я найду там файл jopa.kdevelop и нажму на нём enter. Что дальше должен делать умный с точки зрения неиспользования fuse файловый менеджер? Как он поймёт, что этому проектному файлу нужно ещё пару десяткой файлов вынуть из архива?

>логично предположить что для приложений гнома это все будет работать как GIO (т.е. как KIO в кде), а снаружи будет видно как GVFS через FUSE. Т.е. без fuse его просто не увидят внешние приложения

Т.е. это, опять же, аналог древнего как мир fuse-kio?

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

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

>Ога, его переписывали... Правда до включения в ядро.

по части ошибок, то такие в скором времени даже если и есть, пофиксят, и эта проблема, на мой взгляд, окончательно исчерпает себя.

>При работе с ftp/sftp это удобная штука, cогласен, хотя и mc vfs такое умеет.

зато mc vfs меня привязывает только к определённому софту, которых его использует, и я не смогу обращаться к файлам лежащим на sftp отдельно через другую программу, которая не рассчитана на mc vfs. Основной же плюс fuse - это то, что я смогу работать с подобными файлами абсолютно во всех программах.

>о, у кде vfs уже не прибита гвоздями к кде и куте, и при этом предоставляет доступ к файлам всем приложениям, невзирая на используемый тулкит?

давно уже. см. fuse-kio.

>Тогда да - похоже так, что не отличишь

Когда в гноме сделают, тогда может и не отличисшь:)

>В смысле - без кде эта штука не заработает

Да. Ты же хотел, чтоб "все приложения в KDE, включая не-KDE-шные" могли использовать KIO? Получи - fuse-kio уже несколько лет. Или на ходу передумал условия?:)

>Признав дальнейшее развитие GnomeVFS тупиковым команда Gnome отказалась от него в пользу GIO/GVFS - аналога KIO (KDE).

Лед тронулся. Они начинают таки признавать свою ущербность

> Да, только чтение архива к этому не относится - в конце концов это не виртуальная файловая система.

Скажите, лучше, что из себя представляют файлы .cpio или .iso?

Или ещё вариант. Работал я с файлом blabla.bin, привязанным к /dev/loop0. Например, создал на нём файловую систему ext2. Можно ли это назвать виртуальной ФС? ;)

> Судя по всему, у вас как раз такое сознание :)

Ага, и вся Вселенная, IMHO - это одна большая файловая система... ;)

>зато mc vfs меня привязывает только к определённому софту, которых его использует, и я не смогу обращаться к файлам лежащим на sftp отдельно через другую программу, которая не рассчитана на mc vfs. Основной же плюс fuse - это то, что я смогу работать с подобными файлами абсолютно во всех программах.

Вам в любом случае нужно будет вызывать fusemount. С таким же успехом можно вызывать libvfs_mount, который во временной диреткории и т.д.

>>Я думаю, что и сабж без гнома вряд ли будет функционален.

>зря думаешь. Потому что будет - для этого и выносят =)

А зачем ещё один FUSE??? Это даже не велосипед, это самокат:)

>Вам в любом случае нужно будет вызывать fusemount. С таким же успехом можно вызывать libvfs_mount, который во временной диреткории и т.д.

один раз, да при том, в случае с fuse я смогу спокойно сохранить файл и он отправиться прямиком на удалённый сервер, а что делать с временным файлом, опять извращениями страдать?

>Скажите, лучше, что из себя представляют файлы .cpio или .iso?

Это, кстати, архивы, а не файловые системы :) Даже tar бОльшая файловая система, чем cpio. Но это по-прежнему недофайловая система, чтобы требовать для нее специальный mount.

А почему еще никто не предложил смотреть картинки, как файловую систему, где файлами являются точки в пространстве rgb?

или вот в процессе работы с приложением никак не связанным с файлобродилкой, мне понадобится открыть что то с другого сервера, не открывая нвоое окно и не делая лишних движений. С помощью fuse, который примонтировал мне ftpfs при загрузке системы я просто укажу путь в диалоге, а во ткак быть в ином случае?

>один раз, да при том, в случае с fuse я смогу спокойно сохранить файл и он отправиться прямиком на удалённый сервер, а что делать с временным файлом, опять извращениями страдать?

А какая разница? Что в /tmp/tmp_dir, что в /fusemount/tmp_dir...

>Я найду там файл jopa.kdevelop и нажму на нём enter. Что дальше должен делать умный с точки зрения неиспользования fuse файловый менеджер? Как он поймёт, что этому проектному файлу нужно ещё пару десяткой файлов вынуть из архива?

Знаете, что сделает fuse? Поймает open(). Знаете, как поймать open() в userspace? Легко...

Здесь готов обсуждать кривость решения, однако это будет даже более портабельно, чем fuse.

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

И fuse поймает open(). Так же легко поймать open() в случае userspace.

> А какая разница? Что в /tmp/tmp_dir, что в /fusemount/tmp_dir...

разница в том, что я сохраню в на удалённый сервер, а не в /tmp/tmp_dir/tmpfile

>А почему у меня не так? ;)

Предатель?

и это сделаю из абсолютно любого приложения

> О! Блондинки будут рассуждать об архитектуре по внешнему виду? ;)

А ты блондинка? похоже, коли не в состоянии связать смысл двух простых предложений, следующих одно за другим.

>А почему у меня не так? ;)

Можно предположить, что:

1. в твоем компе RAM > 1Гб

2. Ты не запускаешь Наутилус

3. Ты ниасилил top

4. Другое

Точно, .iso - самый настоящий архив. И то, что даже без FUSE можно сделать mount file.iso /mountpoint -o loop и получить произвольный доступ к файлам - это, вероятно, ошибка разработчиков. ;)

> Знаете, что сделает fuse? Поймает open(). Знаете, как поймать open() в userspace? Легко...

> Здесь готов обсуждать кривость решения, однако это будет даже более портабельно, чем fuse.

И эти люди говорят, что fuse - это криво и тормозно!

Зачем писать велосипед, если это уже сделано в fuse?

> И то, что даже без FUSE можно сделать mount file.iso /mountpoint -o loop и получить произвольный доступ к файлам - это, вероятно, ошибка разработчиков. ;)

А сейчас сделайте то же самое, только без прав рута :P

>А зачем ещё один FUSE??? Это даже не велосипед, это самокат:)

Тока гику & Co хрен докажешь ето. Они вон и Skull-у мозги промыли...

Ты три раза подряд написал, чтобы понятнее было? ;)

И вообще, fuse-kio - это тот самый недоделанный стафф, который ещё с 2004 года до stable допиливают, и который только из SVN доступен?.. ;)

>> А какая разница? Что в /tmp/tmp_dir, что в /fusemount/tmp_dir...

>разница в том, что я сохраню в на удалённый сервер, а не в /tmp/tmp_dir/tmpfile

open(/fusemount/tmp_dir/tmp_file) будет пойман fuse и преобразуется в посылку данных по сети. Абсолютно тоже самое можно сделать в userspace. Это будет портабельно на любой другой POSIX (или SUS запамятовал) из коробки, в отличие от fuse.

Я правильно понимаю, что для этого и нужно VFS?.. ;)

>> Здесь готов обсуждать кривость решения, однако это будет даже более портабельно, чем fuse.

>И эти люди говорят, что fuse - это криво и тормозно!

Это заметно прямее вызова из ядра обработчика архивов.

>Зачем писать велосипед, если это уже сделано в fuse?

Затем, что этол "криво и тормозно" :)

>Точно, .iso - самый настоящий архив. И то, что даже без FUSE можно сделать mount file.iso /mountpoint -o loop и получить произвольный доступ к файлам - это, вероятно, ошибка разработчиков. ;)

Ага, и mc в него может зайти, так что с того?

> Я правильно понимаю, что для этого и нужно VFS?.. ;)

Угу. А для того, чтобы это было единообразно, придуман fuse. Только некоторые люди его не приемлют и собираются городить LD_PRELOAD-извраты.

>open(/fusemount/tmp_dir/tmp_file) будет пойман fuse и преобразуется в посылку данных по сети. Абсолютно тоже самое можно сделать в userspace. Это будет портабельно на любой другой POSIX (или SUS запамятовал) из коробки, в отличие от fuse.

а как быть, если я не запускаю приложение из файлобродилки и не доделываю всякие LD_LIBRARY_PATH ? Есть другие варианты реализации этого, по нормальной схеме?

>>> Здесь готов обсуждать кривость решения, однако это будет даже более портабельно, чем fuse.

>>И эти люди говорят, что fuse - это криво и тормозно!

>Это заметно прямее вызова из ядра обработчика архивов.

Велосипед с более прямыми колёсами? ;)

>>Зачем писать велосипед, если это уже сделано в fuse?

>Затем, что этол "криво и тормозно" :)

Кстати, а как потом запаковывать назад изменённый файл? Развивайте свой теорию...