Обзор дистрибутива GoboLinux 017

Проект GoboLinux разрабатывает дистрибутив с необычной целью: реорганизовать файловую систему операционной системы. Проект представляет собой следующее:

GoboLinux - альтернативный дистрибутив Linux, который переопределяет всю иерархию файловой системы. В GoboLinux вам не нужна база данных пакетов, потому что файловая система - это база данных: каждая программа находится в своем собственном каталоге.

Другими словами, вместо того, чтобы менеджер пакетов помещал исполняемые файлы в /usr/bin, библиотеки в /usr/lib и другие ресурсы в /usr/share, все файлы программы хранятся в одном дереве, например /Programs/Firefox. или /Programs/LibreOffice. Таким образом, пользователь и служебные программы пакетов могут удалить программное обеспечение, удалив один каталог, а не отслеживать, где были установлены отдельные файлы.

GoboLinux использует оконный менеджер Awesome, который предоставляет легкий графический интерфейс. В версии 017 Gobo удаляет Python2 в пользу Python3, а также удаляет GTK2 в пользу GTK3 из ISO-образа. Управление звуком теперь осуществляется PulseAudio.

Gobo предоставляет одну редакцию дистрибутива для 64-битных (x86_64) компьютеров. Размер загружаемого образа составляет 1,9 ГБ. При загрузке с этого носителя появляется ряд текстовых меню. В этих меню предлагается выбрать один из шести языков из списка, а затем выбрать раскладку клавиатуры. После ответов на эти вопросы нам будет предоставлена текстовая консоль, в которой мы автоматически войдем в учетную запись root. Над приглашением командной строки появляется сообщение, которое сообщает нам, что мы можем запустить «startx», чтобы открыть графический интерфейс пользователя. В тексте также объясняется, как запустить установщик системы из командной строки или из оконного менеджера Awesome.

При открытии среды Awesome панель размещается в верхней части экрана. Мы можем найти меню приложений в верхнем левом углу и панель задач в верхнем правом углу. Обои в основном черные с нанесенными на них абстрактными рисунками. Фон выглядит динамически, а не фиксированным изображением. Значок громкости интересен тем, что щелчок по нему меняет цвет значка (между зеленым и красным), и это, кажется, отключает звук.

Меню приложений в live-сеансе содержит очень мало записей. Большинство из них управляют сеансом Awesome. Я считаю, необходимо отметить, что для настройки Awesome нам нужно отредактировать текстовый файл, здесь нет панели настроек «укажи и щелкни». Есть пункт меню, чтобы открыть руководство по Awesome. При попытке доступа к руководству на секунду открывалось окно, а затем сразу же происходил сбой, без отображения запрошенной документации или ошибки.

Также есть некоторые утилиты, такие как менеджер разделов GParted и терминал. Я расскажу о включенном программном обеспечении позже, но почти все, что есть в меню, предназначено либо для управления Awesome, либо для подготовки системы к установке Gobo на жесткий диск.

Установка

Установщик Gobo, запускаемый из Awesome, представляет собой графическое приложение. У него нет инструмента управления разделами, и если установщик не может найти подходящий раздел для операционной системы, то попросит нас запустить такой инструмент, как GParted или cfdisk, чтобы создать для него новый раздел.

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

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

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

Первые впечатления

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

Среда консоли по умолчанию использует оболочку zsh и включает обычные утилиты командной строки в стиле UNIX. Программа man включена, но отсутствуют справочные страницы, что затрудняет получение локальной справки из командной строки.

Программы

После запуска оконного менеджера Awesome у нас есть доступ к небольшой коллекции программного обеспечения. Под рукой есть такие программы, как браузер Firefox, медиаплеер Audacity и редактор vim. Также включены некоторые системные инструменты, такие как GParted и монитор процессов Htop. Хотя оболочкой по умолчанию является zsh, доступны и другие. Оболочка bash включена по умолчанию, а другие оболочки находятся в репозитории программного обеспечения проекта. Утилита sudo предназначена для помощи пользователям в выполнении административных задач. Gobo использует программное обеспечение SysV init и версию ядра Linux 5.6.10.

Поддержка железа

Когда Gobo запускает только текстовую консоль, он приятно нетребователен к ресурсам. Процессор в значительной степени простаивает, а система потребляет 50 МБ ОЗУ. Даже при входе в Awesome дистрибутив использует всего 150 МБ памяти и очень мало задействует процессор. Полная установка занимает около 6 ГБ дискового пространства, что кажется много, учитывая, как мало программ включено. Однако я считаю, что большая часть пространства используется инструментами сборки, поскольку Gobo собирает новое программное обеспечение из исходного кода (подробнее об установке программного обеспечения через минуту).

Я начал с запуска Gobo в среде VirtualBox, и по большей части дистрибутив работал хорошо. Загрузка была немного медленной, но после этого он работал быстро. Звук, сеть и среда рабочего стола работали. Моя единственная серьезная проблема заключалась в том, что я не мог изменить размер интерфейса Awesome. Он застрял на низком разрешении и не мог динамически изменять размер с окном виртуальной машины. Awesome также, похоже, не имеет встроенного инструмента для настройки разрешения экрана, что мешало мне использовать Gobo в виртуальной среде.

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

Управление пакетами

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

Compile, похоже, клонирует онлайн-репозиторий рецептов, как дерево портов в других дистрибутивах. Очень долго длилась попытка получить копию репозитория. Не было никаких признаков прогресса, даже когда компиляция выполнялась в подробном режиме.

Ни разу не получив копию репозитория после шести попыток, несмотря на активное (и быстрое) подключение к интернету, я обнаружил, что Compile всегда зависает при клонировании репозитория Git. После создания исходных файлов Git данные не загружались. Даже через несколько минут в мое дерево репозиториев не было добавлено никаких новых данных. Это не похоже на проблему с Compile, так как утилита командной строки git также зависала при попытке получить репозиторий Recipes и всегда останавливалась после загрузки 112 КБ из 474 МБ репозитория.

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

Затем я попытался вручную скопировать рецепты с другого моего компьютера в систему Gobo. Когда репозиторий рецептов был установлен вручную, Compile больше не пытался его загрузить. Однако Compile по-прежнему зависал, когда ему предлагалось установить программное обеспечение, и он по-прежнему не отображал никаких сообщений при запуске в подробном режиме. Кроме того, не было активности на диске или в сети. Монитор процессов не показал активности Compile. Я попытался установить несколько пакетов, все с одним и тем же результатом - ничего не происходило, и сообщения об ошибке не было.

Еще одна связанная с этим проблема, при навигации в больших каталогах моя оболочка инициировала много дисковой активности, выполняя простые вещи, такие как использование cd или запуск pwd. Это происходило только в каталогах с большим количеством элементов, таких как /Programs или /Data/Compile/Recipes. При просмотре каталогов с небольшим количеством элементов оболочка реагировала немедленно и почти не использовала ресурсы. Я обнаружил, что эта проблема возникает только при запуске оболочки zsh. Переход на bash снял проблему в больших каталогах.

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

Организация файловой системы

Претензия Gobo на известность связана не с управлением программным обеспечением, а с организацией файловой системы. Традиционные файловые системы Linux содержат такие каталоги, как etc, usr и home. Gobo называет каталоги по-другому, а корневая файловая система содержит каталоги с именами Data, Mount, Programs, System и Users. Это приятно тем, что более очевидно, что они содержат.

Технически каталоги usr и т. д. все еще существуют в системе Gobo. Эти устаревшие записи просто скрыты от пользователя. Мы все еще можем войти в них с помощью cd, но не видим их в списках каталогов. Как правило, содержимое этих местоположений представляет собой символические ссылки на пользовательские местоположения Gobo, хотя и не всегда. Например, файл /etc/passwd, содержащий информацию об учетной записи пользователя, все еще существует. Однако файл /etc/zshrc представляет собой символическую ссылку на /Programs/Scripts/Settings/zshrc. Такое сокрытие традиционных расположений означает, что файловая система выглядит чище и организована таким образом, чтобы сделать содержимое каталогов более понятным для новичков.

На мой взгляд, ирония заключается в том, что только продвинутые пользователи Linux смогут использовать Gobo, потому что для его работы требуются дополнительные технические знания и опыт. Однако люди, которым выгодна реорганизация каталогов в четко названные модули, почти исключительно новички в Linux.

Заключение

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

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

Во-первых, Compile собирает пакеты из исходного кода, и это очень медленно. Большинство пользователей не хотят ждать несколько часов, пока их веб-браузер обновится, просто чтобы их базовая файловая система могла быть организована более модульно. Я не говорю, что модульный подход непривлекателен, просто стоимость (компиляция всего с нуля) высока. Если бы у Gobo были предварительно собранные пакеты, это больше не было бы проблемой.

Во-вторых, большинство современных менеджеров пакетов (таких как DNF, APT и pacman) достаточно хорошо справляются со своей работой, и пользователи, вероятно, справятся с ними так же хорошо, как и с модульной файловой системой, которая действует как база данных пакетов. Эти инструменты делают поиск, удаление старых пакетов и проверку зависимостей относительно безболезненными и дают примерно тот же результат, что и Gobo. Есть аргумент, что менеджеры пакетов усложняют систему, и лучше удалить их в пользу нового макета файловой системы (больше в соответствии с философией KISS). Теоретически я бы согласился с этой идеей, но не уверен, что подход Gobo практически лучше, потому что ...

В-третьих, современный дистрибутив Linux имеет дело с десятками тысяч программных пакетов. Модульный подход Gobo (файловая система - это база данных пакетов) имеет смысл в небольших средах. Но я не уверен, что он работает практически в системе с 50 000 пакетов. Я не собираюсь вручную искать отдельные пакеты, независимо от их модульной организации, в современном дистрибутиве. Каталог слишком велик. В лучшем случае я буду использовать командную строку, например «find / Programs -type d | grep -i falkon», чтобы проверить, установлен ли браузер Falkon. В конце концов, это лучше или хуже, чем "dpkg -l | grep -i falkon" в системе на основе Debian? Действительно ли "find /Data/Compile/Recipes -type d | grep -i supertux" лучше, чем запуск "apt search supertux" с точки зрения пользователя? Я могу видеть технические аргументы для обеих сторон, но в конечном итоге, как пользователю, мне нужен инструмент, который облегчит мою жизнь и ускорит работу моей системы.

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

Оригинал: GoboLinux 017