Издание OpenSource.com предложило свою версию пяти лучших почтовых клиентов с открытым исходным кодом. Автор обзора уверен, что мобильные и веб-технологии до сих пор не сделали локальные приложения устаревшими. Значительная часть пользователей по-прежнему предпочитают применять традиционные решения.
И для этого есть серьёзные основания. Безопасность мобильных платформ продолжает вызывать серьёзные нарекания со стороны экспертов. Да и удобство смартфонов и планшетов при чтении более-менее объёмных писем вряд ли можно признать удовлетворительным. Исключение — разве что устройства с диагональю от 10 дюймов, но мобильные они весьма условно.
Что касается веб-приложений, то и они по удобству пока сильно отстают от локальных. К тому же пользователи наверняка опасаются внезапных отключений Интернета, которые пока ещё случаются значительно чаще, чем хотелось бы.
Не последнюю роль играет и обычный пользовательский консерватизм. В конце концов, пока нет внятной мотивации менять традиционные решения на неосвоенные и чреватые сюрпризами — как приятными, так и нет.
Вот как выглядит список в версии OpenSource.com:
· Thunderbird;
· Claws Mail;
· Evolution;
· Geary;
· KMail.
Наверное, с этим стоит согласиться. Действительно, перечислено всё если не самое лучшее, то уж наверняка наиболее популярное. Казалось бы, выбирай что душе угодно. Но именно в этом и заключается проблема, которую только усугубляет отечественная специфика.
Дело в том, что основной участник отечественного ИТ-рынка — не разработчик, а пользователь. Причём пользователь, уже успевший привыкнуть к отсутствию реального выбора ПО и по сути утративший интерес к этому вопросу.
Принимать какое-то решение такому пользователю не просто сложно, а практически невозможно. В том числе и поэтому тормозятся многие внедрения Linux.
Ещё во времена школьного Linux-проекта мне часто приходилось видеть тоску в глазах работников сферы образования, когда им рассказывали о разнообразии свободного ПО. Они упорно сопротивлялись любым попыткам вынудить их к принятию хоть какого-то самостоятельного решения.
Тем не менее, в выборе свободной программы нет ничего сложного. Хотя, безусловно, некоторые нюансы тут имеются. Рассмотрим их на конкретном примере, где в качестве платформы будет фигурировать отечественная система ROSA Desktop Fresh с рабочим столом KDE, а кандидатами на роль штатного почтового клиента — пять перечисленных выше почтовых клиентов.
Одна из наиболее распространённых ошибок — привязывать прикладную программу к применяемому рабочему окружению. Мол, если для KDE специально написан KMail, то и думать тут нечего — всё равно другие приложения будут работать хуже и выглядеть ужасно.
Это уже давно не так. В KDE прекрасно работают GTK-приложения. И выглядят они ничуть не хуже, чем «родные» для KDE QT-программы. Поэтому на такие вещи вообще не следует обращать никакого внимания.
Разумеется, начать выбор следует с чтения всевозможных обзоров. Не только на русском, но и на английском языке. Но этот пункт стандартен и очевиден, поэтому не стоит на нём останавливаться. На выходе у пользователя должен получиться список кандидатов. В нашем случае он уже есть и можно приступать к более серьёзным исследованиям, результаты которого могут заставить усомниться в некоторых приписываемых СПО свойствах.
Первое, что необходимо выяснить — информацию о пакете, который находится в репозитории дистрибутива. В этом, кстати, радикальное отличие Linux от Windows — пользователи СПО получают программы не непосредственно от разработчика, а от составителя дистрибутива. С одной стороны, это хорошо, поскольку приложения должны проходить какие-то дополнительные тесты. С другой — не все входящие в репозиторий приложения поддерживаются в том объёме, который достаточен для их безбоязненного применения.
В системе ROSA информацию о пакете можно получить при помощи команды urpmq -i «имя пакета» или в графическом менеджере пакетов по соответствующему запросу. В данном случае пользователя интересует версия.
Затем следует выяснить, когда составители дистрибутива обновили соответствующий пакет в репозитории. Для этого служит команда urpmq —changelog «имя пакета».
Применительно к нашей задаче информация будет такова:
· mozilla-thunderbird — 38.2.0, последнее изменение было в августе 2015 года;
· claws-mail — 3.11.1, последнее изменение было в июне 2015 года;
· evolution — 3.12.9, последнее изменение было в декабре 2014 года;
· geary — 0.6.0, последнее изменение было в июле 2014 года;
· kmail — 4.14.4; последнее изменение было в августе 2014 года.
Затем следует посетить официальные сайты всех проектов и узнать номер текущей стабильной версии и дату её выхода. В результате получится вот что:
· mozilla-thunderbird — 38.3.0, актуальная версия вышла в сентябре 2015 года;
· claws-mail — 3.13.1, актуальная версия вышла в октябре 2015 года;
· evolution — 3.16.0, актуальная версия вышла в марте 2015 года;
· geary — 0.10.0, актуальная версия вышла в марте 2015 года;
· kmail — 4.14.5, актуальная версия вышла в январе 2015 года.
Таким образом, из списка кандидатов можно смело вычёркивать, например, Geary. Составители дистрибутива давно игнорируют обновления программы и пропустили несколько версий. Может быть, у них руки до этого не доходят.
Не исключён и другой вариант — новые версии пакета не прошли внутреннего тестирования и поэтому не были включены в репозиторий. В этом случае тоже нецелесообразно применять приложение для решения своих практических задач.
А почтовый клиент Thunderbird, напротив, обновляется относительно оперативно. В дистрибутиве находится предыдущая версия этого пакета. Есть небольшая задержка с обновлением, но она может быть объяснена необходимостью внутреннего тестирования, которое требует времени.
Таким образом, сопоставляя данные о оригинальном пакете и пакете, который находится в репозиториии дистрибутива, можно исключить заведомо плохо поддерживаемые варианты. В результате список приложений, которые требуется протестировать с учётом специфики решаемых задач, сокращается основательно.
Как нетрудно заметить, для пользователей системы ROSA выбор сокращается до единственного приложения, которое поддерживается составителями дистрибутива не на словах, а на деле. И принятие решения будет на таким сложным, как это казалось с самого начала.
Отсюда следует побочный вывод о том, что в реальности свобода выбора пользователя Linux не настолько велика, как это представляется неискушённому человеку. Особенно, если оперировать не теоретическими умозаключениями, а практическими категориями. Какие-то программы не проходят внутреннего тестирования, какие-то просто не нравятся отвечающему за конкретный участок репозитория сотруднику, да и ресурсов, чтобы следить за всем, у составителей дистрибутивов часто не хватает.
Разумеется, выбор почтовых клиентов в качестве примера — это в некотором смысле радикальный вариант. С браузерами или текстовыми редакторами ситуация наверняка будет несколько иной. Однако, метод решения задачи остаётся тем же — сопоставление актуальных версий разработчика программы и составителя дистрибутива.
И, разумеется, не стоит удивляться побочным открытиям, которые будут при этом сделаны.
