TL:DR; Новичок попробовал Haiku в первый раз и решил, что она потрясная. Особенно по сравнению с рабочими окружениями, доступными на Linux Я уже делился своими идеями (а также разочарованиями) по поводу #LinuxUsability (part 1, part 2, part 3, part 4, part 5, part 6). В этом обзоре я опишу первые впечатления от Haiku, операционной системы с открытым исходным кодом для персональных компьютеров. Иногда первые впечатления бывают полезными, но так как первые впечатления получаешь только раз — я свои сохранил здесь. 
Система, на которой я пишу этот обзор Возможно, они будут полезными для разработчиков Haiku и\или других заинтересованных сторон.
Где-то я могу ошибаться, поскольку всего-лишь описываю личный (читай: на голубом глазу) первый опыт. Также дружелюбные люди на канале #haiku в сети irc.freenode.net помогали мне подсказками — их я также опубликую. Благодарю вас, разработчики Haiku! Что хотел сказать: Haiku еще не на 100% идеальна, но в ней уже есть крепко сбитое рабочее окружение. Проект Haiku предоставляет образы для загрузки с CD или DVD, формируемые ежедневно. Я использовал флешку USB-3. Мне говорили, что загрузка с USB-3 может не пойти, но на моих двух тестовых системах на базе Intel все работает безупречно. Сам процесс установки я начал с загрузки образа для 64bit, который затем записал на флешку с помощью программы Etcher. Загрузка работает как с EFI, так и без него — мои аплодисменты за предоставление подобного образа. Haiku использует собственную файловую систему BeFS для загрузочного раздела, хотя, в принципе, заявлена поддержка FAT32 и NTFS. Вообще, для системы достаточно 600мб, но для дополнительных приложений надо больше места. По-умолчанию создается раздел на 600мб с BeFS и раздел с FAT32 размером 3Гб. На FAT32 есть файл /EFI/BOOT/BOOTx64.EFI, что подразумевает возможность загрузки на системах с поддержкой EFI. К сожалению я не нашел программ по увеличению размера BeFS, и надеюсь, в будущем сделают другую схему разбивки диска, потому что размер образа раздела зафиксирован небольшим и может не хватить свободного места для дополнительного ПО. Было бы неплохо, если бы дополнительные пакеты с ПО сохранялись на втором разделе FAT32. Это же решение стало бы преимуществом для тех, кто желает получить доступ к файлам напрямую с других систем. Под Linux уже есть поддержка чтения BeFS, есть реализации на чтение-запись BeFS под FUSE. 
Установщик Haiku Мне дали совет: хочешь использовать более емкий раздел — установи Haiku на другую флешку.
Для меня этот этап, в принципе, лишний, поскольку установщик Haiku не умеет разбивать диски, а просто запускает программу DriveSetup, в которой надо вручную разбить диск, добавить раздел, который потом форматировать в BeFS, после чего управление возвращается к установщику. Также надо будет установить вручную и загрузчик, используя отдельную программу. К сожалению, у меня не получилось загрузиться с EFI при такой разбивке, поскольку при этом отсутствует FAT32 раздел с загрузочными файлами для EFI. Не помешал бы установщик, умеющий автоматическую разбивку включая особенности EFI. 
BootManager устанавливает загрузчик на диск Сам процесс установки занимает чуть менее трех минут, что весьма быстро. При этом копируется вся система, состоящая "всего-лишь" из 4751 файла. Причиной этому — тот факт, что большинство ПО опакечено в виде hpkg файлов (чем-то похожих на пакеты Snap в Linux системах), которые никогда не устанавливаются, а просто монтируются. Что интересно — есть достаточно много "свободных" файлов, например, png. Почему они не опакечены? Как я уже говорил, даже ядро операционной системы поставляется в виде hpkg файла. (я говорил о 4751 файле, поскольку запустил перед установкой HaikuDepot, который накачал кучу всего. Чистая установка, по всей видимости, не содержит их все, и может быть установлена быстрее примерно с 200 пакетов. Круто! Как мне сказали, то, что загруженные файлы не игнорируются при установке — это программная ошибка. Ого, а вот, похоже, и первый отчет об ошибке, написанный с моей подачи). Система загружается, показывая симпатичную заставку, а потом останавливается: после загрузки моя видеокарта (Radeon) показывает черный экран. Мне посоветовали загрузку в безопасном режиме экрана с разрешением 1024х768 на FullHD мониторе. В принципе можно было заморочиться с загрузчиком для получения работы с FullHD, но на другом компьютере с видеокартой от Intel все заработало безотказно. Сама система работает отзывчиво с флешки, по всей видимости, из-за того, что на флешку при работе не пишется ничего, так что я надеюсь использовать флешку в качестве основной рабочей системы. Вы получите реальную систему при загрузке с USB, в отличие от тормозных "живых" Linux образов. Во время загрузки не мигает экран, не видно сообщений ядра, нет ощущения, что Xorg прикручен к ядру синей изолентой. В отличие от типичных дистрибутивов Linux, ядро и GUI здесь созданы и подогнаны друг для друга! Нет приглашения для входа в систему, поскольку система сделана для одного пользователя. Все просто, точно то, что требуется для личного компьютера. Нужна поддержка нескольких пользователей — раздайте им по флешке, каждая из которых стоит не дороже $5. Если сравнивать первое ощущение — больше похоже на Mac, чем, к примеру, на Linux с Gnome. Клавиша "command" работает точно так же как и в Mac. Хорошо! 
Ничто не сравнится с пространственным файловым менеджером, по ощущениям — старый добрый Mac! Файловый менеджер по-умолчанию пространственный (как Macintosh System 1.0), к сожалению каждое окно не запоминает свои настройки (например просмотр в виде списка или в виде иконок). Как мне сказали — это ошибка, исправить которую, я полагаю, будет несложно. (К сожалению, писать отчеты "мимокрокодилу" в bugtracker для Haiku сложно — используется оригинальная система, не основанная на GitLab или GitHub, в которую также невозможно и войти с их помощью). Файлы получают свои иконки, нет проблем с отдельными файлами на рабочем столе и иконками.
Хорошо! Куда лучше, чем рабочие окружения для Linux, чувствуется простота. Операционная система работает шустро даже на маломощном оборудовании типа нетбука на Atom. Не чувствуется раздутых слоев ПО. Хорошо! Lunduke сказал, что LibreOffice, по ощущениям, работает быстрее, чем на других операционках, но я это еще не проверял. Bryan Lunduke. Haiku OS Beta — обзор и впечатления В составе имеется терминал. В целом, несмотря на небольшие различия с Linux я сразу освоился с ним, на самом деле — обычный bash, что весьма порадовало. Ух ты! "." в $PATH! Это означает, что можно запускать команды прямо из текущего каталога (Линуксоиды однажды сказали мне, что мир взорвется, если я попробую так сделать). Отлично! 
bash, запущенный в терминале Haiku Что еще крутого в терминале — можно нажать ctrl + c для копирования, так же как и в прочих приложениях, в отличие от рабочих окружений Linux, где нужно жать ctrl + shift + c в терминале.
Мелочи, которые показывают целостность всей системы. Раздел, откуда идет загрузка, смонтирован в /boot. Как просто!
Никакой кучи /etc, /usr, /bin… Просто /home и /system. Чисто, просто, понятно. Хорошо! (Не совсем: они есть, но скрыты. Зачем? Потому что /bin это /system/bin, нет необходимости отображать это в Tracker, но скрипты все еще используют его. Я думаю, разработчики должны избавиться от устаревших вещей, сделанных для совместимости, поскольку это только усложняет понимание.) Я уже упоминал ранее о файлах hpkg, которые чем-то напоминают пакеты на Linux, но они не устанавливаются, а просто монтируются (подобно пакетам snap). Файловая система, которая делает эту магию, зовется packagefs. Она монтирует hpkg файлы поверх других, в результате таким путем создается весь каталог /system. Команда mount, к сожалению, не показывает, что смонтировано. Мне рекомендовали попробовать mountvolume, которая покажет смонтированные разделы, но, к сожалению, она тоже не показывает точки монтирования с packagefs (покажет только те, что связаны с разделами или дисковыми образами). [К счастью, если запустить mount или df где-то на хосте с docker, можно пару экранов мотать! — прим. переводчика] Но можно провернуть трюк с df : Как видно, /system и /home/config внутри /boot это как раз packagefs.
Знающие меня люди в курсе, что я фанат поддержки drag-and-drop в файловых менеджерах: например, использую комплекты приложений NeXT-style, или AppImages.
В любом случае, есть недостатки и в таком формате распространения ПО. Сможет ли packagefs совместить лучшее? Как видно, в моем случае (системный раздел заполнен, но я хочу поставить приложения) изящнее было бы качать куда-нибудь приложения, используя браузер, прямо как я это делаю с файлами .dmg для Mac или AppImage. packagefs живет в ядре, так что это не файловая система для FUSE (хотя мне известно, что FUSE тоже есть в Haiku). Также мне сказали, что, возможно, в будущем будут сделаны дополнительные "зоны packagefs", а это, вероятнее всего, означает, что я смогу указать packagefs сохранять пакеты, например, на отдельных дисковых разделах. Такое мне по вкусу — ведь если дисковый раздел будет на съемном носителе, я смогу сесть за другой компьютер и получить там работающие приложения. Еще сказали, что методом drag-and-drop также работает и установка пакетов: достаточно перетянуть файл в /system/packages или в /home/config/packages для установки, а если вытянуть файл оттуда — он удалится. Если перетягивать пакет с неудовлетворенными зависимостями — система запросит их предварительную установку. Сперва мне было непонятно, как packagefs обрабатывает множественные версии одного и того же пакета, что будет, если я захочу поставить, к примеру, разные версии gcc, или других GUI программ? (Один из разработчиков сказал, цитата: "сама packagefs не содержит чего-либо, мешающего установке нескольких пакетов с одним и тем же именем, но поскольку применяется libsolv из OpenSuse для разрешения зависимостей, которая не позволяет так делать, — было запрещено так делать и самому HaikuDepot в настройках". Я могу пояснить, почему мне нравится идея с пакетами .app, AppDir и AppImages). Есть ли технология динамических библиотек? Да, это видно, например, если вы запускаете приложение с отсутствующими библиотеками двойным кликом: 
Можете представить такое в gnome, kde или xfce? В Linux подобный запуск ничего бы не показал. Давайте посмотрим, как долго оно будет делаться в разных окружениях: А что насчет проверок? Надо использовать замену: В принципе ldd был бы лучше, поскольку он дополнительно показывает пути, откуда библиотеки будут загружаться.
А откуда они реально загружаются? Так что можно поместить библиотеки рядом с исполняемым файлом, и он будет "просто работать". Как же круто! Можно просто подключить отдельные библиотеки к приложению без возни с rpath или установки переменной LD_LIBRARY_PATH как на Linux. Хорошо! Есть библиотека (ужасная на Linux) /boot/system/lib/libstdc++.so.6.0.24.
Что если приложению требуется версия новее, чем имеющаяся в /boot/system/lib?
Обычный пользователь, наверное, обновится до последней версии, потому что в этой системе нет пользователя "Administrator" с паролем root [автор намекает на простоту — прим. переводчика].
Ну по крайней мере так это выглядит. (На самом деле "пользователь" является аналогом root. Можно установить пароль с помощью команды passwd, после чего указать PermitRootLogin=yes в sshd_config, а далее можно будет подключиться снаружи по ssh. Разработчики сказали мне, что по-умолчанию все приложения запускаются от root. В конечном итоге, они, может, и доработают это… Но не уверен, понравится ли мне.) В связи с тем, что нет дистрибутивов Haiku — разработчики приложений также не имеют доступ к версиям новее тех, которые доступны для загрузки в вашей системе. Результат: меньше разочарований, вещи "просто работают". Отличное упрощение! Мне по вкусу. Как уже было сказано выше, приложения получают тип и иконку, так что вам не надо возиться с файлами на рабочем столе и тому подобными вещами. Мне подсказали, что есть особый сервис-регистратор, который знает о приложениях, типах файлов, иконках. Он всегда уведомляется при установке пакета или пометке файла для исполнения (используя программу chmod или mimeset).
Чем-то напоминает Launch Services на Mac. А ведь это то, что отсутствует в рабочих окружениях на Linux. Отлично! Двоичные файлы получают встроенные иконки в виде ресурсов, так что вам не нужна отдельная иконка в дополнение к файлам на рабочем столе. Почти так же, как было на Macintosh System 1. Круто! 
Типы приложений, поддерживаемые типы документов, встроенные ресурсы и информация о версии Tracker (файловый менеджер) автоматически помечает двоичные файлы исполняемыми. Это то, что я ждал от рабочих окружений на Linux уже более 10 лет.
Все это весьма доставляет. Ведь круто же! Жизнь становится такой простой. Это утонченнее и более похоже на Mac, чем XDG на Linux. Или вот это... 
Приложение на Linux без установленного бита исполняемости В Gnome убрали возможность запуска исполняемых файлов из файлового менеджера, но сообщество подняло шумиху — и все вернули.
Также мне рассказали, что приложения используют функцию find_paths() вместо жестко указанных /usr/bin и /usr/share (общая черта рабочих окружений на Linux), что означает возможность перемещения их по файловой системе. Аплодирую стоя! На Linux это как обычно "сложно". Прежде всего меня поразил уровень поддержки оборудования. На моем нетбуке на основе Atom заработало все, включая WLAN. Но есть некоторые особенности в работе. Основное предназначение операционной системы — запуск приложений. Я боялся, что под Haiku не будет приложений для реальной работы. К счастью, ошибался, поскольку есть надежда на улучшение — когда Haiku станут чаще использовать.
Scribus (приложение для визуальной вёрстки) есть, а это весьма сложное приложение на основе Qt. Также есть и QtCreator (IDE). Мне стало интересно, пишут ли сегодня нативные приложения Be для Haiku, используя нативные инструменты (если они существуют), или достаточно использовать QtCreator (что облегчит портирование кроссплатформенных приложений). Позиция разработчиков Haiku — "явное" предпочтение нативных приложений для Haiku. Правда? Я вот сомневаюсь, что приложения для реальной работы бывают не кроссплатформенные (все применяемые в моей работе приложения — кроссплатформенны). Заявлена поддержка WxWindows приложений. Отсутствие поддержки Gtk+ расстраивает. Это значит, что на Haiku в ближайшее время не будет Gimp (ну, я так думаю), но есть замена в виде Krita! Также, я думаю, нужен простой и понятный способ создания приложений для Haiku, вроде этого — используя Travis CI и GitLab CI. Застрянет ли Haiku в концепции BeOS UX? Мне кажется, для привлекательности ей надо тщательно выверять новые схемы UX при их принятии, оставаясь при этом верной своим основам.
К примеру: Это тонкие нюансы, учитывая которые, система не должна потерять свою уникальную индивидуальность. Haiku реально открыла мне глаза, показала, как рабочее окружение "просто работает".
Более 10 лет назад я перешел с Mac на Linux и с тех пор искал тот же уровень утонченности и красоты, и Haiku во многом ему соответствует. Честно говоря, есть огрехи, но на удивление многие вещи, включая аппаратную начинку, к примеру WLAN или принтеры, "просто работают". Однако, в первую очередь, система имеет концепцию рабочего окружения, отсутствующего в рабочих окружениях на Linux. Наличие цельной системы (а не ядра и различных конкурирующих пользовательских окружений) делает все простым и последовательным. Отсутствие различных сборок (дистрибутивов) делает все еще проще. Расчет на работу только одного пользователя в системе еще более снижает сложность. Результат: очень простая, утонченная, минималистичная в многих отношениях система, созданная для "простых смертных", а не для системных администраторов UNIX. Есть надежда, что когда эта система станет более популярной (а это неизбежно), ее сложность не увеличится. Я уже писал о #LinuxUsability в прошлом цикле статей. Приятно знать, что Haiku решает многие затронутые проблемы, включая родовые, которыми страдают рабочие окружения на Linux. Одного дня мне хватило, чтобы убедиться: я хочу использовать это рабочее окружение для ежедневной работы, а также ищу варианты для моего вклада в развитие системы. Попробуйте сами! Ведь проект Haiku предоставляет образы для загрузки с DVD или USB, формируемые ежедневно. Для установки достаточно скачать образ и записать его на флешку с помощью Etcher. От автора перевода: это первая статья из цикла про Haiku. Список статей: Первая Вторая Третья Четвертая Пятая Шестая Седьмая Восьмая Девятая Подниматель пингвинов