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

вообще итнересно и гном и кде изначально гробят идею X. ведь как было раньше - чистый Х и разные win managers. И можно было переключатся между нини на лету - без рестарта Х или logout. Конечно и сейчас это можно делать но уже не с Гномом/KDE. Так ведь скоро и вовсе останутся только DE - не будет уже чистых win managers?

>> А если архив большой, а из него надо вынуть 1 файл

> tar.bz2 тебе всё равно придётся распаковывать полностью

А zip, rar, iso?

>FUSE есть ещё и для mac OS X и для других систем. Если нет - допилят Как минимум для Win32 допилить будет трудно, а портирование Эволюшина одна из основных целей Novell'а.

Потом, я не понимаю зачем делать поддержку FUSE в Gnome, когда это нормальная файловая система. Тогда нужна еще и поддержка mount?

>>А вот мне инетересно Гномовики будут тоже backend менять ?

Сходи по ссылке :) GIO/GVFS - это новый API супротив KIO, который был 100 лет и три года лишних.

Ваша правда - Гном зашел в тупик, а КДЕ давно там. А тем временем M$ наблюдает за схваткой с холма и скоро мы изумлённая общественность увидит почти бесплатный Экплорер фор Линукс.

> вообще итнересно и гном и кде изначально гробят идею X. ведь как было раньше - чистый Х и разные win managers. И можно было переключатся между нини на лету - без рестарта Х или logout. Конечно и сейчас это можно делать но уже не с Гномом/KDE.

Никогда не пробовали убивать kwin и запускать другой менеджер окон во время сессии kde? А оно работает...

>>А zip, rar, iso?

для этих да. Но в мире OSS tar+gzip/bzip2 всё-таки распространённей :)

а iso - не архив и монтируется и так

Помоему, гном ваще тупиковая ветвь в развитии. Отомрет иза-своей сложности.

>Так ведь скоро и вовсе останутся только DE - не будет уже чистых win managers?

пользователи tiled wm передают вам привет.

>Потом, я не понимаю зачем делать поддержку FUSE в Gnome, когда это нормальная файловая система. Тогда нужна еще и поддержка mount?

наверное, чтобы в наутилупсе можно было написать sshfs://server/ и попасть куда надо?

> iso - не архив и монтируется и так

без прав рута?

>> Почему-то когда любая программ использует glibc и прочие библиотеки, никто по этому поводу не задумывается.

>То есть мне понадобится в grep добавлять поддержку этой libfuckinvfs? А зачем нужна лишняя ветка кода в десять лет назад отлаженном грепе? А что делать с проприетарщиками, которые эту libfuckinvfs не использовали?

grep работает с текстовыми (иногда бинарными) файлами, архив - это не тот файл, с которым работает grep. Вы же не возмущаетесь, что vim или emacs не смотрят фильм - хотя avi тоже файл, который можно открыть редактором.

>> Если так сильно хочется структуру директорий, сделайте временную директорию в /tmp или ramdisk, распакуйте туда архив и покажите ее всем.

>А если архив большой, а из него надо вынуть 1 файл?

А вы думаете FUSE модуль магическим образом вытащит оттуда один файл посредством астрального общения с оракулом? Он точно так же распакует его содержимое в пространство пользователя, откуда его можно будет посмотреть через FUSE'шные вызовы.

>> Но нет, нужно к гландам добираться необычным путем...

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

Опомнитесь, вы сравниваете распаковку архива в ядре с записью в пайп! Следующим ходом будет использование binfmt модулей для запуска текстового редактора...

>> А zip, rar, iso?

> для этих да. Но в мире OSS tar+gzip/bzip2 всё-таки распространённей :)

Ну я думаю, что можно извернуться и, используя две файловые системы: gzipfs и tarfs, распаковать-таки файл. Хотя tar создавался как архив для бэкапа на ленту, так что особо хорошей производительности от него в таком случае не стоит ждать.

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

>А zip, rar, iso?

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

> GIO/GVFS - это новый API супротив KIO

Я-таки не пойму, вы что, взамен предлагаете в GNOME KIO использовать?

Решение вполне нормальное, оно уже в Roadmap GNOME 2.22, его придумали ещё около полугода назад, и все эти комментарии типа "GIO - это переписанный под GNOME KIO" на него вряд ли повлияют... ;)

>Я-таки не пойму, вы что, взамен предлагаете в GNOME KIO использовать?

мы таки советуем узнать чего такое backend, а так же чего такое грамотный api(интерфейс).

>>То есть мне понадобится в grep добавлять поддержку этой libfuckinvfs? А зачем нужна лишняя ветка кода в десять лет назад отлаженном грепе? А что делать с проприетарщиками, которые эту libfuckinvfs не использовали?

> grep работает с текстовыми (иногда бинарными) файлами, архив - это не тот файл, с которым работает grep. Вы же не возмущаетесь, что vim или emacs не смотрят фильм - хотя avi тоже файл, который можно открыть редактором.

Сравнение некорректно. Допустим, мне надо прогрепать какую-то строку в файлах из архива. Мне что, распаковывать его, грепать, а потом удалять?

>>> Если так сильно хочется структуру директорий, сделайте временную директорию в /tmp или ramdisk, распакуйте туда архив и покажите ее всем.

>> А если архив большой, а из него надо вынуть 1 файл?

> А вы думаете FUSE модуль магическим образом вытащит оттуда один файл посредством астрального общения с оракулом? Он точно так же распакует его содержимое в пространство пользователя, откуда его можно будет посмотреть через FUSE'шные вызовы.

Ну это только в криво написанных fuse-файлосистемах. Для того, чтобы вытянуть из архива список файлов, вовсе не надо распаковывать его полностью!

И напомню, что всё это будет производиться абсолютно прозрачно для тех программ, которые будут пользоваться деревом каталогов внутри виртуальной фс.

>>> Но нет, нужно к гландам добираться необычным путем...

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

> Опомнитесь, вы сравниваете распаковку архива в ядре с записью в пайп!

Не в ядре, а в юзерспейсе.

>Труъ-решение, по-моему - сделать _простую_ обёртку для монтирования fuse-файловых систем, и написать fuse-модули для, например, архивов. Для sftp, ftp, iso уже модули есть и они работают.

вот это и есть gvfs. Какой велосипед? Откуда?

>>Я-таки не пойму, вы что, взамен предлагаете в GNOME KIO использовать?

с чего ты взял ? :)

>>и все эти комментарии типа "GIO - это переписанный под GNOME KIO" на него вряд ли повлияют... ;)

это далеко не ЛОРовские комментарии, сходи по ссылке.

Если нет, тогда к чему такие комментарии? Вы хоть бы матчасть почитали (информацию о GVFS), реализацию бы посмотрели... А то зацикленность мышления обычно мешает нормальному полноценному развитию... ;)

> One complaint about GnomeVFS is that mount points cannot be accessed by non-GnomeVFS-aware applications. GVFS uses a FUSE bridge to make these publicly accessible.

Нельзя не одобрить это решение. С другой стороны, времени и сил оно скушаетю наверное не мало?

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

Именно. Болле того, FUSE имеенно такой интерфейс и предоставляет.

>> А вы думаете FUSE модуль магическим образом вытащит оттуда один файл посредством астрального общения с оракулом? Он точно так же распакует его содержимое в пространство пользователя, откуда его можно будет посмотреть через FUSE'шные вызовы.

>Ну это только в криво написанных fuse-файлосистемах. Для того, чтобы вытянуть из архива список файлов, вовсе не надо распаковывать его полностью!

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

В архиве (не удивлюсь если вообще в любом) данные более не принадлежат отдельным файлам, есть только индекс использования, самих файлов больше нет. Данные при распаковке генерятся "на лету" из полученного индекса и несжатого остатка.

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

Распакуйте архив в tmp и "всё это будет производиться абсолютно прозрачно для тех программ, которые будут пользоваться деревом каталогов внутри виртуальной фс".

>> Опомнитесь, вы сравниваете распаковку архива в ядре с записью в пайп!

>Не в ядре, а в юзерспейсе.

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

Меня эта ссылка не очень интересует, live.gnome.org интереснее. ;)

Хотя по этой ссылке тоже есть интересные моменты, например:

> Essentially, it is a GNOME version of KIO, and will be shipped with GNOME 2.22 in March. (Actually, it will be shipped with Glib, which is shipped with GNOME.)

Думаю, вам заметна разница в реализации на уровне Glib, и на уровне kdelibs (которые этот самый Glib пользуют... ;)).

> Думаю, вам заметна разница в реализации на уровне Glib, и на уровне kdelibs (которые этот самый Glib пользуют... ;)).

Правда чтоли kdelibs использует Glib? Ссылки на источник можно?

Ну, на базовом уровне оно уже почти готово... :)

> There is a port of nautilus (gio-branch) which is nearing completion, and the gio APIs are feature complete (at least for the needs of Nautilus)

http://live.gnome.org/GioToDo

Теперь задача состоит в портировании некоторых приложений GNOME для поддержки ими GIO/GVFS. В Roadmap об этом подробнее написано. :)

В исходники загляните.

> В исходники загляните.

Oops, заглянул в исходники, kdelibs точно не использует. :)

>>Если нет, тогда к чему такие комментарии

Какие "такие" ? Я просто констатировал факт

>>А то зацикленность мышления обычно мешает нормальному полноценному развитию... ;)

По данной новости это очень заметно :) (GnomeVFS) The project basically was started off on the wrong foot, and it has been a mess from a developer standpoint ever since.

Парень не путает glib и glibc?

>Думаю, вам заметна разница в реализации на уровне Glib, и на уровне kdelibs (которые этот самый Glib пользуют... ;)).

Не путайте glib и glibc

>>В исходники загляните.

Ой... Ссылки на файлы можно ?

Нет, я перепутал реализации kdelibs и arts. В arts glib используется.

Мне вот интересно, мы опять получим бесполезную систему с идиотскими адресами типа zip:/ ? Нормальная VFS должна легко адресовать файл, находящийся в архиве, находящемся в запароленном архиве (пароль в URI) находящемся на фтп. Я таких ещё не видел. PS Не знаю как в гноме, а в kde работа с архивами отвратительна, лучшее что есть - это крузадер, но и он сливает тому же тоталкоммандеру.

http://websvn.kde.org/branches/arts/1.5/arts/flow/gsl/gslglib.c?revision=4389...

Ну с kdelibs, я, как говорится, fucked up. :)

> мы опять получим бесполезную систему с идиотскими адресами типа zip:/ ? Нормальная VFS должна

... позволять сделать cd /home/user/archive.tar.gz ; vi filename.txt ???

>Я не следил за KDE4 API, но там вроде как в KIO хотели поменять backend, чтобы он использовал FUSE на тех системах, где это доступно (*nix). Таким образом, система доступная через KIO будет доступна и из любого другого места.

Она зовётся SOLID и привязана к dbus помоему...

В винде нет ни KIO ни аналогов GnomeVFS, тотал&far выруливают толь за счёт _своих_ API и модулей, "глобальные" реализации вещей вроде работы с архивами через указание протокола и подстановка пароля в URI есть зло.

Вот выйдет в марте, тогла скачаем->поставим->посмотрим. Вот тогда и будем выводы делать, а чего сейчас орать?

> А не проще команде Gnome войти в команду КДЕ? Сразу все проблемы решатся

Как раз начнутся, так как без конкуренции начнётся совсестный гномокдекапец. :(

> КДЕ и так кривой/косой, но лучше пока ничего нет.

4.2. Как обычно.

>> КДЕ и так кривой/косой, но лучше пока ничего нет.

>4.2. Как обычно.

действительно 4.2.

есть лучше, есть! :)

>Нормальная VFS должна легко адресовать файл, находящийся в архиве, находящемся в запароленном архиве (пароль в URI) находящемся на фтп. Я таких ещё не видел.

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

> Труъ-решение, по-моему - сделать _простую_ обёртку для монтирования fuse-файловых систем, и написать fuse-модули для, например, архивов. Для sftp, ftp, iso уже модули есть и они работают.

Бери и делай. А то языком все молоть горазды. ;)

>есть лучше, есть! :)

Да, иногда лучше есть, чем говорить :)

> И можно было переключатся между нини на лету - без рестарта Х или logout.

У меня так beryl-manager делает. Я волшебник и единственный владелец сакрального знания «непердежа в лужу»? ;)

Лисапедостороители. Cобираются заново переписать autofs.

> наверное, чтобы в наутилупсе можно было написать sshfs://server/ и попасть куда надо?

Уже давно можно, по ssh:// или sftp://, не помню уже.

>Лисапедостороители. Cобираются заново переписать autofs.

по склерозу я тебя ещё не догнал, поэтому помню, что autofs делал несколько другое. Там надо было заранее точки монтирования создавать и рулесы прописывать =)