ммм, судя по solid.kde.org, SOLID - это для абстракции железа ?

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

http://www.kde.org/info/requirements/3.5.php

Внимательно смотреть на libxml2 >= 2.4.8, libxslt >= 1.0.7, а также чистый GLib >= 2.4 (для arts, kdenetwork).

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

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

Ви таки утверждаете, что gvfs работает через fuse?

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

Точно. Есть водка, бабы и сноубординг ;)

>Ви таки утверждаете, что gvfs работает через fuse?

http://live.gnome.org/GioToDo

см. внизу GVfs ToDo

а так gvfs пока вообще не работает, емнип

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

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

Ну вот и пришли к моему изначальному высказыванию. Всю функциональность можно сделать посредством fuse(сделав единожды через ядро) и незачем при этом юзать во всех программах какие-то gnomevfs или kioslave.

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

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

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

Я для того, чтобы добраться до содержимого файла, fuse предоставит прозрачным образом системные вызовы open()/read()/write(), чтобы его читать. И любая, даже самая старая программа, будет работать. В отличие от gvfs или kio, под которые надо специально затачивать.

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

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

А ничего, что на распаковку будет потрачено ненулевое время? Ничего, что оно займёт место в /tmp? FUSE лишена подобных накладных расходов.

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

Да. Только так можно сделать работу с архивом прозрачной.

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

Почему тогда я из-под KDE могу на ходу переключаться между KWin и Beryl?

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

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

Надо заняться, думаю, что будет популярно. Только можно я сначала зачёты сдам? ;)

>У меня так beryl-manager делает.

Да и без него можно... "kwin --replace", "metacitiy --replace"...

http://blogs.gnome.org/alexl/2007/11/23/file-operations-in-nautilus-gio-and-a...

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

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

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

Гик, оно может и есть, но это точно не про гном ;)

> контуженный gtk. расширяемости у него нет.

А что такое "расширяемость gtk"? И чем эта "расширяемость" уже, чем "расширяемость" qt? Блин, чего только от анонизмусов на лоре не услышишь :)

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

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

>Что они будут делать на системах без FUSE, то есть везде кроме Linux и FreeBSD? Более того, у меня не вкомпилен и не загружен FUSE, значит я не могу поставить Гном?

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

ещё один велосипед? когда ж они наконец объединят костыли в ДЕ независимый стандарт.

2 geek & Shaman

Гик, почему ты тут не откоментил?

http://www.linux.org.ru/view-message.jsp?msgid=2298812

Шаман, как ты мог ето в новости пропустить, ето ж провокацыя флейма в чистом виде. :-)))

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

ресурсы-то надо описывать.

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

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

Точнее cd /home/user/archive.tar.gz#un.tar.gz#

Хорошо бы. Но все cd, vi и grep никто переписывать не будет. glibc можно, но ошибок будет - мама родная...

С графическими программами, УЖЕ использующими KIO/gnome-vfs будет проще.

>"глобальные" реализации вещей вроде работы с архивами через указание протокола и подстановка пароля в URI есть зло.

Почему?

>Гик, почему ты тут не откоментил?

я там начал коментить, но потом понял, что сообщение снесут, как "Оскорбление участников дискуссии"

краткие тезисы комента: ты облажался. проект боянистый. признаков велосипеда не обнаружено.

>ещё один велосипед? когда ж они наконец объединят костыли в ДЕ независимый стандарт.

в чем велосипед? Чем вынос vfs в glib не избавление от DE? Skull там списочек приводил, где в кде glib юзается. Так что останется только выкинуть из кде kio :)

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

Как пример

ftp://host/pub/stuff/test.rar#un.rar#somedir1/somedir2/test2.tar.bz2#un.tar.bz2 #myfile

Сейчас похожая адресация в mc. Есть всяки фридекстоп.орг чтобы прорабатывать и стандартизировать такие вещи.

>Я для того, чтобы добраться до содержимого файла, fuse предоставит прозрачным образом системные вызовы open()/read()/write(), чтобы его читать. И любая, даже самая старая программа, будет работать. В отличие от gvfs или kio, под которые надо специально затачивать.

заодно научить ядро понимать схему, выяснять тип файла и парсить uri на предмет паролей.

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

wmaker наше все!

Отвечаю: Аргументы неубедительны. Проект действительно боянистый, и сильно напоминает KIO. Если 2 колеса педали и руль - не признак велосипеда, то кирпичи - круглые.

ЗЫ. А где твой друг JB?

>ftp://host/pub/stuff/test.rar#un.rar#somedir1/somedir2/test2.tar.bz2#un.tar.bz 2 #myfile

гы, ftp:// - cхема. Кто там возмущался по поводу zip:// ?

test.rar - вроде запароленый, нет? Куда пароль пихать?

осознаешь, что весь test.rar стянется по сети? Прозрачность вырождается в нехилую тормознутость.

>Сейчас похожая адресация в mc. Есть всяки фридекстоп.орг чтобы прорабатывать и стандартизировать такие вещи.

это надо посикс менять, бо там вроде регламентируется, что в open можно в качестве имени файла пихать. Скажем, создать файл ftp://блабла ты уже не сможешь

Glib пользует только aRts, AFAIK.

>Проект действительно боянистый, и сильно напоминает KIO

он ровно настолько же напоминает gnome-vfs

это просто отвязка vfs от DE. Чем это плохо?

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

>А ничего, что на распаковку будет потрачено ненулевое время? Ничего, что оно займёт место в /tmp? FUSE лишена подобных накладных расходов.

Я так и знал - FUSE распаковывает данные в астрал и оттуда общается с ними посредством ядерного оракула. При этом время на распаковку не тратится, и место в памяти не занимается.

Извините, но вы не представляете о чем говорите.

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

>Да. Только так можно сделать работу с архивом прозрачной.

Это самый кривой из способов "сделать работу с архивом прозрачной". Приведенный выше пример с распаковкой в память (ramdisk) или на диск в сотни раз проще, быстрее, надежнее и стало быть лучше. mc, total commander и все остальные именно так и поступают.

>Я так и знал - FUSE распаковывает данные в астрал и оттуда общается с ними посредством ядерного оракула. При этом время на распаковку не тратится, и место в памяти не занимается.

бугага

>это просто отвязка vfs от DE. Чем это плохо?

Да я не говорю, что ето плохо, наоборот. Тока вот на КДЕ будет похоже.

>ресурсы-то надо описывать.

Не надо. Один простой скрипт и одна строчка в auto.master для каждого _протокола_

>Да я не говорю, что ето плохо, наоборот. Тока вот на КДЕ будет похоже.

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

>Не надо. Один простой скрипт и одна строчка в auto.master для каждого _протокола_

гм, напиши-ка мне autofs скрипт для ftp и zip. А то что-то я запамятовал

>Glib пользует только aRts, AFAIK.

а kdenetwork? kdemultimedia-kio-plugins? Неужели акела промахнулсо?

а kdenetwork? kdemultimedia-kio-plugins? Неужели акела промахнулсо?

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

sabonez@sabonez:~> rpm -q --requires kdenetwork3
kdelibs3 >= 3.5.8
/bin/sh
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
libDCOP.so.4
libXext.so.6
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1.3)
libkdecore.so.4
libkdeprint.so.4
libkdeui.so.4
libkdnssd.so.1
libkhtml.so.4
libkio.so.4
libkparts.so.2
libpthread.so.0
libpthread.so.0(GLIBC_2.0)
libqt-mt.so.3
libslp.so.1
libstdc++.so.6
libstdc++.so.6(CXXABI_1.3)
libstdc++.so.6(GLIBCXX_3.4)
rpmlib(PayloadIsBzip2) <= 3.0.5-1

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

Есть такая фигня

----------------------------------------------------------
fuse-kio
----------------------------------------------------------
Description :
fuse_kio представляет собой мост между файловой системой KIO и FUSE (программой
для монтирования файловых систем в пользовательском окружении.
Этот шлюз даёт возможность монтировать ioslave'вы или общий ioslave-шлюз через
FUSE и, таким образом, делать их доступными для всех Линукс-программ.

> аллилуйя! до них дошло!

Люто, бешено +1. Хоть кто-то почесался.

не важно

$apt-cache depends libqt4-core
libqt4-core
  Зависит: libc6
  Зависит: libdbus-1-3
  Зависит: libfontconfig1
  Зависит: libgcc1
>  Зависит: libglib2.0-0
  Зависит: libstdc++6
  Зависит: zlib1g


будет зависеть :)


а пока - косвенно, Skull перечислял там всякие xml/xslt

>> Я для того, чтобы добраться до содержимого файла, fuse предоставит прозрачным образом системные вызовы open()/read()/write(), чтобы его читать. И любая, даже самая старая программа, будет работать. В отличие от gvfs или kio, под которые надо специально затачивать.

> заодно научить ядро понимать схему, выяснять тип файла и парсить uri на предмет паролей.

Имена, явки, пароли передаются в качестве параметров к fusermount. И не надо ядро чему-то учить, всё нужное в нём уже есть.

>Есть такая фигня

судя по названию - эта фигня прибита гвоздями кде. И монтировать сможет только из кде. В смысле - без кде эта штука не заработает

>Почему?

всё самое универсальное - есть зло от порождения лени

Ну ХЗ, может оно и так будет. Но пока именно так - как оно есть.

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

> ftp://host/pub/stuff/test.rar#un.rar#somedir1/somedir2/test2.tar.bz2#un.tar.bz2 #myfile

> Сейчас похожая адресация в mc.

Вы хоть пробовали смотреть, как реализованы vfs в mc? Это кошмар! Там вытягивание каждого файла из архива производится отдельно, потому вытянуть пару десятков файлов из kernel.tar.bz2 - задачка на вечер :)

>Имена, явки, пароли передаются в качестве параметров к fusermount.

пример приведи, как это выглядит. При вызове open()

>И не надо ядро чему-то учить, всё нужное в нём уже есть.

/usr/bin/file там есть? Надо поискать

> гм, напиши-ка мне autofs скрипт для ftp и zip. А то что-то я запамятовал

Для FTP легко, на то волшебный curlftpfs есть. Правда я только «статические» сервера прописывал, но динамика (/media/ftp/host.tld/...) там тоже реализуется, если я правильно понял когда доки читал.

А вот с архивами — таки да. Проблема.

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

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

>> А ничего, что на распаковку будет потрачено ненулевое время? Ничего, что оно займёт место в /tmp? FUSE лишена подобных накладных расходов.

> Я так и знал - FUSE распаковывает данные в астрал и оттуда общается с ними посредством ядерного оракула. При этом время на распаковку не тратится, и место в памяти не занимается.

Ну не надо до абсурда-то доводить. Да, fuse использует место, но ему _не обязательно_ распаковывать _всё_! Например, получить список файлов из rar-архива можно куда быстрее и менее накладно, чем распаковать архив и сделать ls.

>Да. Только так можно сделать работу с архивом прозрачной.

> Это самый кривой из способов "сделать работу с архивом прозрачной". Приведенный выше пример с распаковкой в память (ramdisk) или на диск в сотни раз проще, быстрее, надежнее и стало быть лучше. mc, total commander и все остальные именно так и поступают.

Проще. Не быстрее: происходит распаковка и запись _всего_ содержимого архива на диск, даже когда надо только получить список файлов.

mc (для rar архивов) каждый файл вынимает отдельно(через unrar), за счёт чего достать половину файлов оказывается медленнее чем распаковать весь архив.

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

>Например, получить список файлов из rar-архива можно куда быстрее и менее накладно, чем распаковать архив и сделать ls.

далеко не все архивы позволяют такой финт

>totalcmd использует библиотеку Unrar от автора архиватора

осталось найти исходники библиотеки unrar от автора архиватора.

>>Имена, явки, пароли передаются в качестве параметров к fusermount.

>пример приведи, как это выглядит. При вызове open()

Я не видел, чтобы это было реализовано. Но, например, в siefs(fuse-фс для диска мобильника) в параметрах задаётся расположение сериал-порта и скорость работы. Не вижу принципиальных отличий от логина/пароля.

>> И не надо ядро чему-то учить, всё нужное в нём уже есть.

> /usr/bin/file там есть? Надо поискать

Не понял, к чему это.