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

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

тпрууу. Какой хитрый механизм? Каких наработок?

а существующие наработки - это какие?

>>> Более того, что мешает использовать ту же библиотеку для mc'шного VFS?

>>Архитектура vfs в mc. См. выше.

>Значит исправляйте проблемы, а не городите огород новых уровней. Оккам наверное не раз бы уже порезался своей бритвой.

Я использую fuse и буду ходить туда из mc как в обычный каталог. В чём проблема? Правда ещё придётся чуток переписать в mc, если надо будет сделать монтирование архивов автоматическим.

>А что делать с не-гномовскими приложениями?

> Разницы нет никакой. Вам сначала нужно запустить что-то, что попытается залезть в архив, например щелкнуть мышкой в nautilus. По этому щелчку nautilus запустит 'fusemount $archive $dst_path', а вместо этого мог бы сделать 'tar -zxf $archive $dst_path', или unrar, или что там нужно для обработки данного файла.

А если я зашёл из файл-менеджера в архив, а потом хочу там сделать ls? Или натравить vim на какой-то файл? mc в таком случае ругнётся "нельзя исполнять команды на не-локальных фс".

Быструю распаковку архива можно повесить в контекстное меню.

> grep $archive никоим образом не замонтирует (куда?) этот файл как распакованную директорию и не запустит grep.

Так, давайте сначала. Мне нужно прогрепать файл в архиве. Я могу:

1. распаковать, прогрепать, удалить

2. смонтировать архив через zipfs, потом перейти в точку монтирования и там грепать

3. обучить grep ходить по архивам.

1 - это Ваш вариант, 2 - мой, 3 - то, что сейчас есть в приложениях, поддерживающих kio или gnome vfs

> Именно поэтому нет никакой разницы между fuse и userspace обработчиком. FUSE только полезен для какой-нибудь sshfs или ftpfs, когда приложение представляет из себя какую-то оболочку над шеллом.

То есть fuseiso Вы тоже не жалуете?

>unix-way :)

>glib - не часть гнома, и даже не часть gtk. Хотя gtk зависит от glib, а gnome - от gtk. Но gtk - не часть gnome

> как всё сложно, да? =)

Жуть как запутано, в КДЕ ето выглядело бы так:

glibc - не часть KDE, и даже не часть Qt. хотя Qt зависит от glibc, а KDE - от Qt. Но Qt - не часть KDE.

Уф-ф-ф, запарился!!!

Вопрос - в каком месте GNOME юникс-вей?

Напротив в КДЕ сто лет как все модульно, и каждая софтина не тянет за собой свою реализацию, допустим, khtml.

> а существующие наработки - это какие?

FUSE

> грубо говоря, на инод ~/.gvfs вешается (fuse-модуль) как только идет запрос open('~/.gvfs/Network/ftp/bla.bla.com/pub/бла.rar') - модуль разбирает путь на /Network - ага, значит по сети /ftp - ага, значит протокол ftp /pub/ /бла.rar - ага, значит rar и работает через соответствующий модуль

Вот это я назвал хитрым механизмом.

> Э? Похоже тут промахнулось наше маугли

Эх, не доросли вы до жестоких схваток на LOR! ;)

# rpm -q --requires kdenetwork-kopete | grep glib libglib-2.0.so.0

Платочек дать?

> А артсом убогим врядли кто сейчас пользуется.

Без звука сидите? Ну-ну. ;)

P.S. Ох, какая молодёжь пошла наглая и недалёкая. ;)

Опять прийдётся свои проги переписывать...

Ну и что? артс тоже установлен, да я им не пользуюсь.

Платочек взять.

>между прочим, в ядре такое собирались сделать - прямой доступ к содержимому архива через #

Я бы с этой опцией не стал собираться. Так и представляю, как система перестаёт отвечать на запросы, а я дро занимает оба камня. И всё из-за того, что я неудачно решил заглянуть в bz2 архив размером метров... ну предположим 500.

>Но это дистрибутивный пакет с archlinux.org, которым занимается своя команда мэинтейнеров.

Это ещё один уровень допущений, энтропии и ошибок :) Поэтому уж если берётесь о чём-то судить - то только по результатам "на себе", чтобы потом не оправдываться чужими решениями

> GNOME != GTK, GTK != Glib. Это тебе не KDE, где вся функциональность в паре-тройке пакетов.

KDE != Qt. В случае с 4-ой версией Qt будут зависеть от разных модулей. Так что не надо «ля-ля» про KDE. ;)

>Вопрос - в каком месте GNOME юникс-вей?

ну вот тебе пример - glib, gtk, xmllib, libxslt, gconf, atk ,glade, cairo, pango, etc. Кажется, аналоги кде прибиты гвоздями к кде, емнип. За исключением зумлевых либ, которые используются те же, что и в гноме.

>Напротив в КДЕ сто лет как все модульно, и каждая софтина не тянет за собой свою реализацию, допустим, khtml.

потому что она тянет за собой единственный модуль kdelibs и qt, да? :)

а всё уже там, красота. Вот что значит модульность. А мужики-то не знают :)

Слышь, старичок!

Я конечно уважаю твой вклад в КДЕ и т.д., но буду тебя постарше, и поумнее, и пользую для воспроизведения звука OSS и sox(для системных звучков КДЕ). А артс - убожество.

>> grep $archive никоим образом не замонтирует (куда?) этот файл как распакованную директорию и не запустит grep.

>Так, давайте сначала. Мне нужно прогрепать файл в архиве. Я могу:
>1. распаковать, прогрепать, удалить
>2. смонтировать архив через zipfs, потом перейти в точку монтирования и там грепать
>3. обучить grep ходить по архивам.

>1 - это Ваш вариант, 2 - мой, 3 - то, что сейчас есть в приложениях, поддерживающих kio или gnome vfs

Именно! При всем при том, что 1 и 2 есть абсолютно одинаковые варианты :)
Только в 2 добавляется дополнительная прослойка для fuse. По накладным расходам, времени выполнения и т.п. они примерно одинаковы (может быть fuse несколько мeдленнее).

>> Именно поэтому нет никакой разницы между fuse и userspace обработчиком. FUSE только полезен для какой-нибудь sshfs или ftpfs, когда приложение представляет из себя какую-то оболочку над шеллом.

>То есть fuseiso Вы тоже не жалуете?

А зачем? Если mc/nautilus/[любая другая файлосмотрелка] поддерживает работу с нормальной vfs библиотекой (как какой-нибудь аналог mc'шного vfs, только прямой), то проблема автоматически изчезает.

Вы возразите, что fuse'шные обработчики и есть такой vfs уровень, но это не так, т.к. вовлекать ядро каждый раз, когда вам нужно выполнить простейшие userspace операции, неверно, т.к. это замедляет процесс и имеет бОльшую вероятность содержать (в том числе и фатальные в случае проблем в ядерной части fuse) ошибки.

>KDE != Qt.

в смысле, кде наконец-то перепишут на gtk? =)

Т.е. предлагается для юниксвейности побить kdelibs на модули, и получится аналог твоего glib, gtk, xmllib, libxslt, gconf, atk ,glade, cairo, pango.

Так?

>Вот это я назвал хитрым механизмом.

гм. и чего тут хитрого? прозрачно, аж нимагу

ЗЫ. Ето, покажь мне поддержку допустим smb в kdelibs. Не модульно говоришь?

>Без звука сидите? Ну-ну. ;)

Лично у меня всё работает через алса. Кроме нескольких стареньких нативных игрушек типа homm3, smac и q3. Еслиб мне пришлось каждый раз перед их запуском идти прибивать артс... я бы дописал killall -w artsd; к их значкам в меню. К счастью артс не нужен.

>>Так, давайте сначала. Мне нужно прогрепать файл в архиве. Я могу: >1. распаковать, прогрепать, удалить >>2. смонтировать архив через zipfs, потом перейти в точку монтирования и там грепать >>3. обучить grep ходить по архивам.

>>1 - это Ваш вариант, 2 - мой, 3 - то, что сейчас есть в приложениях, поддерживающих kio или gnome vfs

>Именно! При всем при том, что 1 и 2 есть абсолютно одинаковые варианты :) >Только в 2 добавляется дополнительная прослойка для fuse. По накладным расходам, времени выполнения и т.п. они примерно одинаковы (может быть fuse несколько мeдленнее).

В случае использования fuse можно(не для tar.bz2) сделать быстрее за счёт кеширования. Ещё раз повторю: если нужен 1 файл, незачем распаковывать сто метров других файлов.

>>> Именно поэтому нет никакой разницы между fuse и userspace обработчиком. FUSE только полезен для какой-нибудь sshfs или ftpfs, когда приложение представляет из себя какую-то оболочку над шеллом.

>>То есть fuseiso Вы тоже не жалуете?

> А зачем? Если mc/nautilus/[любая другая файлосмотрелка] поддерживает работу с нормальной vfs библиотекой (как какой-нибудь аналог mc'шного vfs, только прямой), то проблема автоматически изчезает.

А если я хочу погрепать файлы в iso-образе? Мне придётся с не-fuse выкладывать этот файл куда-то(/tmp) а потом его там грепать. Не очень удобно.

> Вы возразите, что fuse'шные обработчики и есть такой vfs уровень, но это не так, т.к. вовлекать ядро каждый раз, когда вам нужно выполнить простейшие userspace операции, неверно, т.к. это замедляет процесс и

Не факт, что замедлит. Работа с архивами в totalcmd или krusader потому и быстра, что не надо распаковывать всё.

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

ошибки могут быть везде.

> Ну и что? артс тоже установлен, да я им не пользуюсь.

Тогда чего прёте на паровоз с неприятием glib? ;)

>Т.е. предлагается для юниксвейности побить kdelibs на модули, и получится аналог твоего glib, gtk, xmllib, libxslt, gconf, atk ,glade, cairo, pango.

угу. Чтобы соответствующие модули не были прибиты к qt и kdelibs :)

если мы вспомним, что кделибсы сделаны поверх qt - то поймем, что задача не имеет решения :)

>ЗЫ. Ето, покажь мне поддержку допустим smb в kdelibs. Не модульно говоришь?

ты этот модуль можешь вне кде юзать?

Да похрен мне глиб. Я говорю, что гномеры==велосипедисты, а вы тут все усераетесь.

>> Вот это я назвал хитрым механизмом.

> гм. и чего тут хитрого? прозрачно, аж нимагу

А ничего, что для этого придётся ядро переписать? А если rar-архив будет иметь расширение .jopa-rar? Придётся снова ядро перекомпилять?

FUSE уже есть и хорошо оттестировано. А geek придумал свой суперпупермегамеханизм работы с vfs.

>ты этот модуль можешь вне кде юзать?

Могу.

> Кажется, аналоги кде прибиты гвоздями к кде, емнип.

Да ну?! Про Qt слышал что-нибудь?

> потому что она тянет за собой единственный модуль kdelibs и qt, да? :)

Как пакет kdelibs можно разбить, но не было смысла поступать как в зоопарке GTK+. Хотя библиотеки сами разные.

P.S. geek, не подставляйся. ;)

>т.к. вовлекать ядро каждый раз, когда вам нужно выполнить простейшие userspace операции, неверно

ну, если напрячь память, то можно вспомнить, что простейшие userspace операции open/read проходят через едро. В случае с fuse просто больше переключений

Какие допущения, какая энтропия? Вы видели официальные требования на сайте KDE?

Чужое решение, когда всё собирается именно так, как задумывалось в mainstream, меня, обычно, устраивает.

> но буду тебя постарше, и поумнее

Судя по максимализму, или врёшь или уже впал в маразм. ;)

> и пользую для воспроизведения звука OSS и sox(для системных звучков КДЕ). А артс - убожество.

А остальные пользуются Arts и ALSA и ничего, живут. Красноглазым гентушникам или счастливым обладателям RedHat 5.2 этого не понять. ;)

> в смысле, кде наконец-то перепишут на gtk? =)

А GNOME на Qt? ;)

>Именно! При всем при том, что 1 и 2 есть абсолютно одинаковые варианты :)

Нет. Перелопачивать весь архив для получения файла из конца нужно только в: непрерывном rar, 7zip, tar.*z. И то возможны оптимизации. Большинство остальных архивов пзволяют распаковать конкретный файл без накладных расходов. И 2й вариант будет сильно-сильно быстрее.

Вот, они тоже начинают понимать очевидные вещи, которые в GNOME присутствуют пракически с самого начала. ;)

>Да ну?! Про Qt слышал что-нибудь?

представь, да. Qt - это тоже один большой модуль =)

отдельно там только интерфейсы к базам данным, емнип. Про доки/девтулсы не говорим, ага?

>Как пакет kdelibs можно разбить, но не было смысла поступать как в зоопарке GTK+

потому что любая из частей потребует и qt и kdelibs? Действительно, не было смысла =)

>Могу.

ну давай. Покажи его dep'ы :)

> если мы вспомним, что кделибсы сделаны поверх qt - то поймем, что задача не имеет решения :)

Ровно то же самое можно сказать насчёт glib, gtk, xmllib, libxslt, gconf, atk ,glade, cairo, pango с отрывом друг от друга. ;)

> Qt - это тоже один большой модуль =) отдельно там только интерфейсы к базам данным, емнип. Про доки/девтулсы не говорим, ага?

qt4=qt4-gui + qt4-core + qt4-sql

>А ничего, что для этого придётся ядро переписать?

вообще-то не придется.

>А если rar-архив будет иметь расширение .jopa-rar?

про эту проблему я упоминал много выше

>FUSE уже есть и хорошо оттестировано. А geek придумал свой суперпупермегамеханизм работы с vfs.

так я описал рекурсивное использование FUSE :) Думаю, не большая проблема научить fuse рекурсии и дергать /usr/bin/file для определения типа файла (а то вдруг архив)

>В случае использования fuse можно(не для tar.bz2) сделать быстрее за счёт кеширования. Ещё раз повторю: если нужен 1 файл, незачем распаковывать сто метров других файлов.

Не удаляйте директорию после разархивирования так же как вы не станете отмонтировать директорию после выхода из нее. Если отмонтируете - результат такой же: при повторном запске потребуется заново разархивировать.

>А если я хочу погрепать файлы в iso-образе? Мне придётся с не-fuse выкладывать этот файл куда-то(/tmp) а потом его там грепать. Не очень удобно.

А в случае с fuse вы где будете грепать? Не забывайте про астрал, fuse с ним все-таки не работает, я проверил исходники - fuse'шный userspace модуль перекатит iso архив в список файлов в памяти, которая будет передана в ядерный fuse модуль как указатель на специальные структуры, которые вы потом можете представить в виде (внимание!) списка файлов! Так почему бы просто не распаковать iso в /tmp или ramdisk и забыть про проблемы?

Даже с ftpfs так можно делать (что и делает mc'шный vfs).

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

>ошибки могут быть везде.

Только в случае с MC и userspace vfs layer система не упадет из-за ошибки, если же ошибка в ядерной части fuse...

> Да похрен мне глиб. Я говорю, что гномеры==велосипедисты, а вы тут все усераетесь.

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

>qt4=qt4-gui + qt4-core + qt4-sql

опупеть. три модуля. К 4 версии они разбили qt аж на три модуля. Сдохнуть можно. В 3-й было 5 =)

> так я описал рекурсивное использование FUSE :) Думаю, не большая проблема научить fuse рекурсии и дергать /usr/bin/file для определения типа файла (а то вдруг архив)

Ну а зачём всё так сложно, зачем вводить какой-то модуль, который будет определять что-то через /bin/file?

Пользователю надо смонтировать архив как каталог - он монтирует. если потом в смонтированом окажется ещё один архив - его так же легко можно будет смонтировать.

Описанное, наверно, для того, как представлять путь к файлу в строке адреса браузера/файлменеджера? Так?

$ kioclient cp myfile sftp://whatever

2 Skull. Я не гентушник, тем более не красноглазый, и п###дить необучен. И я выбрал для себя OSS и sox. Просто надо на место ставить некоторых выродков, орущих "то не нужно, это мастдай, наш выбор - самый кошерный".

Насчет редхата - у меня OpenSuSE 10.2.

> представь, да. Qt - это тоже один большой модуль =)

Какой версии? geek, ты давно из анабиоза? ;)

>Нет. Перелопачивать весь архив для получения файла из конца нужно только в: непрерывном rar, 7zip, tar.*z. И то возможны оптимизации. Большинство остальных архивов пзволяют распаковать конкретный файл без накладных расходов. И 2й вариант будет сильно-сильно быстрее.

Не осилили прдыдущие страницы? Почитайте снова.

Никто не мешает вытащить ваш файл из архива в /tmp, если это поддерживает архиватор. FUSE для этого горидить не нужно.

> Просто надо на место ставить некоторых выродков, орущих "то не нужно, это мастдай, наш выбор - самый кошерный".

Начните с себя, делающие такие заявления про Arts. ;)

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

По моему скромному мнению наиболее правильным архитектурным решением для них является стена.

Простите, вырвалось :)

> Так почему бы просто не распаковать iso в /tmp или ramdisk и забыть про проблемы?

Проблемы в скорости. Вариант с полной распаковкой медленнее. (В случае, если надо извлечь _все_ файлы - он будет только чуток быстрее)

> Только в случае с MC и userspace vfs layer система не упадет из-за ошибки, если же ошибка в ядерной части fuse...

Ядерную часть уже единожды написали. А то, что выполняется в юзерспейсе систему не порушит.

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

Я на Гноме-1 сидел, сам собирал под редхат 5.2 кстати, тогда он был юзабелен. К чему они щаз пришли, не устраивая революций - логическому осмыслению не поддается, в него надо просто тупо верить, аки гик.

ЗЫ. Не дай бог мне участвовать в таких проектах, а то можно мозгами тронуться.