Gvfs linux что это

Обновлено: 08.07.2024

Покупая ноутбук с Windows, всегда получаешь изрядное количество предустановленных программ. Видимо, очень полезных с точки зрения производителя. Как правило, они только едят ресурсы, а антивирус (наверное, единственная полезная вещь) тут же начинает требовать дополнительных расходов на себя. Что делать с этим, известно — ставить чистую систему и устанавливать только те программы, в нужности которых есть твердая уверенность. Особенно это касается нетбуков, где на счету каждый такт.

Как ни странно, но с Linux ситуация почти такая же. Установив любой популярный дистрибутив с LiveCD, получаем набор ПО «для всего» и знакомое ощущение, что тут что-то явно лишнее. Например, у меня нетбук. Мне нужен браузер, плеер видео и аудио, смотрелка картинок и ssh. Мне не нужен сканер, у меня нет оптического привода, мне даже офис не нужен. Все, чем я буду пользоваться, должно быть быстрым и легким поэтому предустановленный аудиоплеер на Mono — это явный перебор. Можно устанавливать Desktop с DVD, но и в этом случае в инсталяторе выбор не слишком велик — либо очень крупные группы пакетов, либо кажый deb/rpm по отдельности. А есть что-нибудь среднее? Например, вариант установки ядра системы с оконным менеджером в минимальной конфигурации, и возможность добавлять приложения по своему вкусу?

В этой статье я расскажу о «крупноузловой» сборке Desktop-окружения по принципу «необходимый минимум, плюс только то, что я сам захочу» на примере Unity. Предполагается что читатель умеет пользоваться командной строкой и любит «заглядывать под капот».

Нам потребуется проводное подключение к Интернет, параметры прокси-сервера при его наличии и загрузочный USB с NetInstall или Alternate образом Ubuntu Natty. Загружаемся с носителя и выполняем установку. Если используеся Alternate USB, нажмите F4 при загрузке и выберите «Установить без графической среды». Если используеся NetInstall, не выбирайте ни одного пункта на этапе работы tasksel. После перезагрузки начинаем разбиратья.

ubuntu-desktop
compiz
unity
libdconf0
unity-place-*
indicator-session
indicator-application
indicator-appmenu
indicator-datetime
indicator-sound
appmenu-gtk
network-manager-gtk
modemmanager
gvfs-backends
acpi-support
cpufrequtils
language-pack-gnome-ru
compizconfig-settings-manager
ttf-ubuntu-*
dmz-cursor-theme
branding-ubuntu

Запускаем apt-get install весь-этот-список-пакетов, ждем завершения, перегружаемся. Наблюдаем изрядно похудевшую Unity, весьма отзывчивую даже на нетбуке

Все остальное — по желанию. Для добавления лучше использовать apt-cache + apt-get или synaptic, не забывая просматривать, что находится среди рекомендованных зависимостей. Некоторые программы могут молча не работать — так, я не сразу понял почему так мало типов подключения в окне «Соединиться с сервером», пока не вспомнил про gvfs.

GNOME (GNU Network Object Model Environment) — свободная среда рабочего стола для UNIX-подобных операционных систем. GNOME является частью проекта GNU.

Содержание

Происхождение

Проект GNOME был основан в августе 1997 года Мигелем де Икасой и Федерико Меной Кинтеро как попытка создать полностью свободную рабочую среду для операционной системы GNU/Linux. В то время единственным вариантом для неискушённого пользователя являлась среда KDE. Но KDE основана на инструментарии Qt фирмы Trolltech, который тогда был проприетарным продуктом. Чтобы не допустить ухудшения ситуации, была инициирована разработка GNOME — новой свободной рабочей среды на основе инструментария GTK+, созданного ранее для графического редактора The GIMP и распространяемого на условиях GNU GPL.

В 2000 году версия Qt 2.2 была выпущена на условиях GNU LGPL, в результате чего лицензионные проблемы KDE были ликвидированы. Однако проект GNOME, к тому времени уже достаточно развитый, продолжил своё существование, а к настоящему моменту снискал массовую популярность и используется по умолчанию во многих дистрибутивах UNIX [1] .

Организация

В августе 2000 года был создан GNOME Foundation (фонд GNOME) для решения административных задач, общения с прессой и как точка взаимодействия с организациями, заинтересованными в разработке приложений для GNOME [1] .

Платформы

Изначально GNOME была средой для GNU/Linux. Сейчас она может быть запущена на большинстве UNIX-подобных систем: AIX, IRIX, разновидностях BSD, HP-UX; а также частично была адаптирована фирмой Sun Microsystems для ОС Solaris вместо устаревшего CDE. Sun Microsystems также выпустила Java Desktop System — рабочую среду на базе GNOME. Существует порт GNOME для Cygwin, способный работать под управлением Microsoft Windows [1] ..

GVFS и GIO

GVFS — это виртуальная файловая система, созданная как альтернатива для GnomeVFS. GVFS позволяет по желанию подключать виртуальные файловые системы, монтируя их через FUSE (файловую систему в пользовательском пространстве).

GVFS состоит из двух частей:

Первая - это общедоступная библиотека, загружаемая приложениями, поддерживающими GIO и саму GVFS.

Вторая - это набор программ-демонов, которые взаимодействуют друг с другом и GIO модулем по D-Bus.

GVFS создаёт виртуальную файловую систему без создания пользовательского процесса, в отличие от GnomeVFS, но в чём-то похоже на KIO.

Целью GVFS/GIO является обеспечение современной, лёгкой в использовании виртуальной файловой системы. GVFS/GIO пытается предоставить API, который бы разработчики предпочитали простым вызовам ввода-вывода POSIX. Вместо того, чтобы копировать API ввода-вывода POSIX, новая система обеспечивает высокоуровневый интерфейс, ориентированный на понятие документа. Помимо чтения и записи файлов GIO также даёт возможность следить за изменениями в файлах, производить асинхронный ввод-вывод и искать дополнения имён файлов [2] .

Интерфейсы

В GVFS поддерживаются различные интерфейсы, включая HAL-интеграцию, SFTP, WebDAV, SMB, ObexFTP, а также монтирование архивов (через libarchive) [3] .

Поддерживаемые сетевые протоколы

Следующие сетевые протоколы в настоящее время поддерживаются GVFS:

Samba bzw. Windows-Freigaben (smb://)
FTP (ftp://)
SSH und SFTP (ssh:// bzw. sftp://)
WebDAV (dav:// und davs://)
OBEX-FTP (obex://[xx:xx:xx:xx:xx:x] для просмотра и обмена данными через Bluetooth)

Протокол NFS в настоящее время не поддерживается GVFS.

Подобно сетевым протоколам, которые обрабатывают GVFS включают в себя:

Диск ( computer://)
Корзина ( trash://)
Сетевое окружение ( network://)
Запись программы ( burn://)
Цифровые камеры ( gphoto2://)

Так как Ubuntu 13.10 поддерживает GVFS, также MTP (Media Transfer Protocol) могут быть подключены через USB смарт - телефонов, планшетных компьютеров и т.д. непосредственно на имя через GVFS..

Локализация

Пакет GVFS

Пакет правильно собирается и работает на платформе LFS-6.5.

Информация о пакете

Зависимости пакета:

Обязательные D-BUS-1.4.16; GLib-2.30.1; Intltool-0.50.01
Необязательные avahi-0.6.25; BlueZ; D-Bus GLib Bindings-0.98; Expat-2.0.1; FUSE; GConf-2.28.1; gnome-disk-utility-2.30.1; HAL-0.5.14; libarchive-2.8.5; libcdio; libgnome-keyring-2.30.1; libgphoto2; libsoup-2.30.2;
xml2-2.7.8; Samba-3.6.1.

Установка пакета

Установить пакет можно с помощью следующих команд:

После этого в роли пользователя root нужно выполнить: make install

Пояснение команд

--sysconfdir=/etc - этот параметр указывает, что файлы sysconf будут установлены в соответствующее место в директории /etc, а не в директории /usr/etc. --libexecdir=/usr/lib/gvfs - этот параметр указывает, что файлы libexec будут установлены в соответствующее место в директории /usr/lib/gvfs, а не в директории /usr/libexec.

Виртуальная файловая система Git (Git Virtual File System, далее GVFS) была создана для решения двух основных задач:

Скачивать только файлы необходимые пользователю
Локальные команды Git должны брать в расчет не всю рабочую директорию (working directory), а только файлы, с которыми работает пользователь

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

Предыстория

Почему монолитный репозиторий?

Разберемся сразу с самым простым вопросом: зачем вообще кому-то нужен репозиторий таких размеров? Просто ограничьте размер ваших репозиториев и все будет в порядке! Правильно?
Не все так просто. Уже написано много статей о преимуществах монолитных репозиториев. Несколько больших команд в Microsoft уже пробовали разбивать свой код на множество маленьких репозиториев и в результате склонились к тому, что монолитный репозиторий лучше.

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

VSTS (Visual Studio Team System)

Набор инструментов VSTS состоит из нескольких связанных сервисов. Поэтому мы решили что разместив каждый из них в отдельном репозитории git мы сразу избавимся от проблемы масштабирования, и одновременно создадим физические границы между различными частями кода. На практике же эти границы ни к чему хорошему не привели.

Во-первых, нам все равно приходилось изменять код в нескольких репозиториях одновременно. Много времени при этом уходило на управление зависимостями и соблюдение правильной последовательности commit-ов и pull request-ов, что в свою очередь привело к созданию огромного количества сложных и неустойчивых утилит.

Во-вторых, значительно усложнился наш процесс релиза. Параллельно с релизом новой версии VSTS каждые три недели мы выпускаем коробочную версию TeamFoundation Server каждые три месяца. Для корректной работы TFS необходима установка всех сервисов VSTS на одном компьютере, то есть все сервисы должны понимать от каких версий других сервисов они зависят. Собирать воедино сервисы, которые в течение трех последних месяцев разрабатывались совершенно независимо оказалось непростой задачей.

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

Windows

Примерно по этим же причинам команда, работающая над Windows, решила перейти на Git. Код Windows состоит из нескольких компонент, которые теоретически могли бы быть разбиты на несколько репозиториев. Однако у этого подхода были две проблемы. Во-первых, несмотря на то что большинство репозиториев были небольшие, для одного из репозиторев (OneCore), который занимал около 100 Гбайт, нам все равно пришлось бы решать проблему масштабируемости. Во-вторых, такой подход ни коим образом не облегчил бы внесение изменений в несколько репозиториев одновременно.

Философия дизайна

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

Рассмотренные альтернативные варианты

Итак за последние несколько лет мы потратили много времени пытаясь заставить Git работать работать с большими репозиториями. Перечислим некоторые из рассмотренных нами вариантов решения этой проблемы.

Подмодули Git

Сначала мы попробовали использовать подмодули. Git позволяет указать (reference) любой репозиторий как часть другого репозитория, что позволяет для каждого коммита в родительском репозитории указать коммиты в под-репозиториях от которых этот родительский коммит зависит и где именно в рабочей директории родителя эти коммиты должны быть размещены. Выглядит как идеальное решение для разбивки большого репозитория на несколько маленьких. И мы потратили несколько месяцев работая над утилитой командной строки для работы с подмодулями.

Основной сценарий применения подмодулей — это использование кода одного репозитория в другом. В каком-то роде подмодули — это те же самые пакеты npm и NuGet, т.е. библиотека или компонент, который не зависит от родителя. Любые изменения вносятся в первую очередь на уровне подмодуля (в конце концов это независимая библиотека со своим независимым процессом разработки, тестирования и релиза), а затем родительский репозиторий переключается на использование этой новой версии.

Мы решили, что могли бы воспользоваться этой идеей разбив наш большой репозиторий на несколько маленьких, а затем склеив их обратно в один супер-репозиторий. Мы даже создали утилиту, которая бы позволяла выполнять «git status» и коммитить код поверх всех репозиториев одновременно.

В конце концов мы забросили эту идею. Во-первых, стало понятно, что таким образом мы только усложняем жизнь разработчика: каждый коммит теперь стал двумя или более коммитами одновременно, так как необходимо было обновить как родительский, так и каждый из затрагиваемых подмодульных репозиториев. Во-вторых, в Git нет атомарного механизма для выполнения коммитов одновременно в нескольких репозиториях. Можно было бы конечно назначить один из серверов ответственным за транзакционность коммитов, но в итоге все опять упирается в проблему масштабируемости. И в-третьих, большинство разработчиков не хотят быть экспертами в системах контроля версий, они бы предпочли, чтобы доступные инструменты делали это за них. Для работы с git разработчику необходимо научиться работать с направленным ациклическим графом (DAG, Directed Acyclic Graph), что уже непросто, а тут мы просим его работать с несколькими слабосвязанными направленными ациклическими графами одновременно и к тому же следить за порядком выполнения checkout/commit/push в них. Это уже слишком.

Несколько репозиториев собранных воедино

Если не получилось с подмодулями, то может быть получится с несколькими репозиториями склеенными вместе? Подобный подход был применен андроидом в repo.py и мы тоже решили попробовать. Но ничего хорошего из этого не вышло. Работать в рамках одного репозитория стало проще, зато намного усложнился процесс внесения изменений в несколько репозиториев одновременно. И так как коммиты в разных репозиториях теперь совершенно не связаны друг с другом, непонятно какие коммиты из разных репозиториев должны быть выбраны для определенной версии продукта. Для этого понадобилась бы еще одна система контроля версий поверх Git.

Запасные хранилища (alternates) Git

В Git существует понятие запасных хранилищ объектов (alternate object store). Каждый раз когда git ищет коммит, дерево или блоб он начинает поиск c папки .git\objects, затем проверяет pack-файлы в папке .git\objects\pack, и наконец, если указано в настройках git-а, ищет в запасных хранилищах объектов.

Мы решили попробовать использовать сетевые папки в качестве запасных хранилищ чтобы избежать копирование огромного количества блобов с сервера при каждом clone и fetch. Такой подход более-менее решил проблему количества копируемых файлов из репозитория, но не проблему размера рабочей директории и индекса.

Еще одна неудачная попытка использования функционала Git не по назначению. Запасные хранилища были созданы в Git для избежания повторного клонирования объектов. При вторичном клонировании того же репозитория можно использовать хранилище объектов первого клона. Предполагается, что все объекты и pack-файлы находятся локально, доступ к ним моментален, нет надобности в дополнительном кэше. К сожалению, это не работает если запасное хранилище находится на другой машине в сети.

Поверхностное клонирование (shallow clones)

В Git существует возможность ограничить количество клонируемых коммитов. К сожалению, этого ограничения недостаточно для работы с огромными репозиториями вроде Windows, так как каждый коммит вместе со своими деревьями и блобами занимает до 80 Гбайт. Тем более, что в большинстве случаев для нормальной работы нам не нужно содержимое коммитов целиком.
К тому же поверхностное клонирование не решает проблемы большого количества файлов в рабочей директории.

Частичный (sparse) чекаут

При чекауте Git по умолчанию помещает все файлы из этого коммита в вашу рабочую директорию. Однако в файле .git\info\sparse-checkout можно ограничить список файлов и папок которые могут быть помещены в рабочую директорию. Мы возлагали большие надежды на этот подход поскольку большинство девелоперов работаю лишь с небольшим подмножеством файлов. Как оказалось, у частичных есть свои недостатки:

Хранилище для больших файлов (LFS, Large File Storage)

Каждый раз, когда мы изменяем файл больших размеров, в истории изменений Git создается его копия. Для экономии места Git-LFS подменяет эти большие блоб-файлы на их указатели, сами файлы при этом помещаются в отдельное хранилище. Таким образом, при клонировании вы скачиваете только указатели на файлы, а затем LFS скачивает только файлы, которые вы чекаутите.

Было непросто заставить LFS работать с репозиторием Windows. В итоге нам это удалось, что позволило существенно уменьшить общий размер репозитория. Но мы так и не решили проблему большого количества файлов и размера индекса. Пришлось отказаться и от этого подхода.

Виртуальная файловая система (Virtual file system)

Вот к каким выводам мы пришли после всех вышеперечисленных экспериментов:

Управление памятью в вопросах мониторинга ее использования – одна из самых важных областей в вашей Linux системе. В различных дистрибутивах Linux существует великое множество инструментов для мониторинга использования памяти. Работают они тоже по разному, но в этой статье мы рассмотрим установку и использования такого инструмента как smem.

Smem – это инструмент предоставления отчетов в командной строке, который выдает пользователю различные сводки по использованию памяти в системе Linux. В smem есть одна уникальная вещь, которая отличает его от традиционных инструментов мониторинга памяти. Дело в том, что smem сообщает вам PSS (Proportional Set Size), то есть он дает более полноценное представление о распределении памяти между приложениями и библиотеками в настройках виртуальной памяти.

Существующие традиционные инструменты сосредоточена главным образом на считывании RSS (Resident Set Size), т.е. на стандартной мере мониторинга использования памяти в физической схеме памяти, которая тем не менее имеет тенденцию переоценивать использование памяти приложениями.

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

Вы можете обратиться к этому руководству (о PSS и RSS памяти), чтобы понять механизм потребления памяти в системе Linux. А теперь давайте перейдем к рассмотрению некоторых особенностей smem.
Особенности Smem:

Листинг обзора системы;
Листинг и фильтрация по процессам, маппингам и пользователям;
Использование данных из файловой системы /proc;
Настраиваемые столбцы листинга для нескольких источников данных;
Конфигурируемые блоки вывода и процентные показатели;
Простота настройки заголовков и итогов в списках;
Использование моментальных снимков из зеркал каталогов или сжатых tar файлов;
Встроенный механизм генерации диаграмм;
Облегчённый инструмент захвата, используемый во встроенных системах.

Как установить Smem – инструмент мониторинга памяти в Linux

Перед тем, как приступить к установке smem, необходимо убедиться, что ваша система удовлетворяет следующим параметрам:

Современное ядро (версия от 2.6.27);
Актуальная версия Python (поддерживается от 2.4);
Опционально библиотека matplotlib для генерации диаграмм.

Большинство дистрибутивов Linux на сегодняшний день поставляются с последней версией ядра с поддержкой Python 2 или 3, поэтому единственным требованием по сути может быть только установка matplotlib для отрисовки красивых графиков.

На системах RHEL, CentOS и Fedora

Для начала включите репозиторий EPEL (Extra Packages for Enterprise Linux), затем установите следующее:

На системах Debian и Ubuntu

На Linux Mint

На Arch Linux

Как использовать Smem

Чтобы увидеть отчет по использованию памяти системой, всеми пользователями системы, введите следующую команду:

Когда стандартный пользователь запускает smem, то отображается использование памяти процессом, который инициировал этот пользователь. Процессы организованы по возрастанию PSS.
Взгляните на пример вывода для моей системы. Здесь показано использование памяти для процессов, инициированных пользователем aaronkilik:

Есть множество опций, которые вы можете вызвать во время использования smem, например, чтобы просмотреть потребление памяти в масштабах системы, выполните следующую команду:

Также вы можете просмотреть использование памяти маппингами:

У smem есть параметры фильтрации выходных данных. Сейчас мы взглянем на два примера.
Фильтрация вывода по имени пользователя (username) осуществляется вызовом опций -u или --userfilter="regex" , как в примере ниже:

Чтобы отфильтровать выходные данные по имени процесса, включите опцию -P или --processfilter="regex" :

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

Чтобы отображать в отчете только необходимые столбцы, используйте -c или –columns , как показано ниже:

Вы можете использовать параметр -p , чтобы выводить отчет об использовании памяти в процентном соотношении:

Следующая команда будет выводить итоговые показатели в конце каждого столбца выходных данных:

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

Вы можете создать гистограмму процессов и их PSS и RSS значений. В приведенном ниже примере мы создаем гистограмму процессов, принадлежащих пользователю root.

Вы имеете возможность создать круговую диаграмму, отражающую процессы и потребление памяти ими на основе PSS или RSS значений. Команда ниже выводит круговую диаграмму для процессов, принадлежащих пользователю root, отражающую ключевые значения.
- - pie означает метку по имени, а опция -s помогает сортировать по значению PSS.

Существует множество других полей помимо PSS и RSS, используемых для маркировки диаграмм.

Чтобы увидеть справку, просто введите smem -h или обратитесь к документации.

Сейчас мы остановимся в smem на этом этапе. Если вы хотите получше разобраться с этим инструментом, посетите страницу руководства.

Читайте также: