Author: Tatyana

Установка ПО (или пакетов) в дистрибутивах Linux происходит «централизованно», что удобно, но часто вызывает вопросы у новичков. И так, максимально доходчиво я постараюсь объяснить, почему всё не так как в Windows и зачем знать базовые команды консольного менеджера пакетов, если в любом современном дистрибутиве есть графический интерфейс.Если вы интересуетесь темой Linux, то знаете о существовании множества дистрибутивов и о том, что нередко они несовместимы между собой. Точнее, готовые пакеты одного дистрибутива несовместимы с другими дистрибутивами, особенно если это не производные друг от друг дистрибутивы. Поэтому у каждого дистрибутива есть свои репозитории готовых пакетов, собранных исключительно под конкретный дистрибутив. Из этих репозиториев пакетный менеджер и берёт пакеты. Но это не единственная и далеко не основная причина того, что пакеты для Linux систем распространяются таким образом. При установке той или иной программы через пакетный менеджер видно, что вместе с пакетом самой программы, в систему устанавливается ещё куча всяких пакетов. Чем сложнее программа и чем «чище» ваша система, тем больше пакетов устанавливается в качестве «зависимостей». Зависимости – это системные библиотеки, а иногда и другие программы, необходимые для работы устанавливаемой программы. Каждый пакет в репозитории содержит файл-манифест, в котором указаны все зависимости. В Windows также, некоторые упакованные программы требуют наличия определённых компонентов в системе. Например, для игр необходимо наличие библиотек DirectX в каталоге «system32» и так далее. Это те же зависимости. Установщик программы видит их наличие и сообщит вам о их отсутствии, если не найдёт соответствующую запись в реестре. На самом деле, в Windows программы часто просто не запускаются или вылетают с ошибкой, но причина именно в отсутствии того или иного компонента. В Linux же пакет просто не будет установлен, если нет возможности соблюсти все зависимости. Разбором зависимостей и занимается пакетный менеджер. В идеале в репозиториях дистрибутива есть всё необходимое для соблюдения всех зависимостей всех пакетов. В этом заключается опасность использования сторонних репозиториев. Если информация о зависимостях в них устарела, или содержит ошибки, то использование пакетов из таких репозиториев может вызвать проблемы той или иной сложности. Имена пакетов, системных библиотек и их версии в разных дистрибутивах отличаются. Поэтому невозможно без плясок с бубном взять пакет из Ubuntu и установить его в OpenSUSE. Теоретически это можно сделать, пересобрав пакет и установив нужные зависимости, но такой пакет не будет обновляться, даже если не вызовет других проблем. Всегда нужно устанавливать пакеты именно для вашего дистрибутива и к другим способам прибегать только в случае крайней необходимости. Если ваш дистрибутив не содержит всего того, что вам нужно, то это серьёзный повод для смены дистрибутива. Существует несколько пакетных менеджеров со своими плюсами и минусами, а также сам подход к зависимостям у большинства дистрибутив отличается. Кроме пакетов с ПО, существуют так называемые «мета-пакеты», которые содержат только инструкции по зависимостям. Мета-пакеты используются для установки комплексных решений в один клик. Например, мета-пакеты рабочих столов, когда установкой одного мета-пакета можно установить окружение рабочего стола и кучу прикладного ПО. Та же ситуация и с удалением. Рано или поздно вы захотите удалить неиспользуемое ПО, входящее в состав дистрибутива. И, в зависимости от дистрибутива, можете обнаружить, что удаление почтовой программы удаляет также мета-пакет рабочего стола, что помечает половину пакетов в вашей системе как «ненужные». Пакеты, установленные как зависимости, могут быть безболезненно удалены как в процессе удаления основного пакета, так и после. Беда в том, что мета-пакет рабочего стола был указан как жёсткая зависимость почтовой программы. Имеется в виду, что без рабочего стола она работать не будет. Но не учитывается, что рабочий стол без почтовой программы может работать без каких-либо проблем. В итоге, после невнимательного удаления чего-либо действительно ненужного, можно обнаружить, что система стала легче гигабайт на 5, но при этом загружается в чёрный экран и командную строку. Такой подход к зависимостям свойственен, например, Ubuntu, тогда как пакетный менеджер в Arch Linux помечает подобные зависимости как «необязательные», что избавляет пользователя от проблем, приведённых в пример выше, но требует от него определённых знаний. То есть, если утрировать, то рабочий стол без почтовой программы работает, но кому-то может понадобиться её функционал. Таким образом, пользователь должен знать какие необязательные зависимости ему нужны, а какие нет. Большинство же дистрибутивов решают это за пользователя, имея в зависимостях того или иного пакета максимальный набор компонентов «на все случаи жизни». Другими словами, чем меньше знаний требуется для использования дистрибутива, тем больше в нём «мусора». И чем больше опыта у пользователя, тем сложнее его «настольный» дистрибутив. По той же причине в мире существует огромное количество различных дистрибутивов, ориентированных на различную аудиторию. Но не всегда широта возможностей прямо пропорциональна сложности. Исторически так сложилось, что большая часть пакетов в Linux зависит от наличия системных библиотек. По аналогии с директорией «system32» в Windows, в Linux есть директория «lib». Такой подход экономит место, когда одна и та же системная библиотека используется множеством программ, но он же делает пакеты одного дистрибутива непригодным для установки в другой. Кроме имён системных библиотек отличаются так же их версии, в зависимости от дистрибутива. Во многих пакетах в качестве зависимостей указаны не только сами библиотеки, но и их версии. По той же причине многие дистрибутивы не обновляют версии ПО в пределах жизненного цикла версии дистрибутива. Например, в Debian вы будете получать обновления безопасности, но версии практически всего ПО останутся неизменными. Таким образом ряд дистрибутивов поддерживает стабильность. Тот же подход можно видеть в корпоративных версиях Windows, когда весь функционал заморожен в пределах одной версии, и обновления содержат только исправления и патчи безопасности. Но в Windows это касается только компонентов ОС, тогда как всё остальное устанавливается и обновляется отдельно. В Linux же всё прикладное ПО распространяется централизованно, как и компоненты ОС. Теоретически новая версия определённой программы будет работать с текущей версией определённой системной библиотеки, так же, как и текущая версия программы с более новой библиотекой, но это не тестировалось на пререлизных стадиях дистрибутива. Всегда есть шанс, что что-то пойдёт не так. Поэтому в ряде дистрибутивов есть стадия так называемой «заморозки», когда перед релизом все версии ПО замораживаются и остаются неизменными на протяжении всего жизненного цикла версии дистрибутива. Такой подход даёт свои результаты. Если не использовать сомнительные сторонние репозитории в Debian, то она гораздо стабильнее даже корпоративных версий Windows. Некоторые дистрибутивы могут сочетать в себе стабильность и инновации. То есть, они устанавливают рань между новизной ПО и его стабильностью на более приемлемой для широкого круга пользователей позиции. Роллинг-дистрибутивы так же могут быть стабильными, если разработчики и тестировщики приложили к этому достаточно усилий.Понятно, что «пакетно-зависимый» подход не всегда оправдывает себя. Попытки унификации пакетов ПО для Linux были всегда. Две самые удачные и современные системы – это Snap от Canonical и Flatpak, которая разрабатывается сообществом. Обе системы не идеальны, но позволяют решить две самые основные задачи: унификация и интеграция. В отличии от более ранних реализаций, установленное таким образом ПО смотрится нативно и интегрировано в систему (ОС знает, что оно установлено, присутствуют все привычные меню, ярлыки и прочее). Основным плюсом является то, что подобный пакет содержит все необходимые зависимости и работает на любом дистрибутиве, способом работать с этой системой пакетов. Разработчикам не нужно разбирать зависимости каждого дистрибутива при создании пакета. Нужно лишь учитывать специфику самой системы Snap или Flatpak. А то, как система в целом работает в дистрибутиве – это дело разработчиков дистрибутива. Как уже было сказано, Snap и Flatpak не идеальны. По ряду причин ПО не всегда выглядит нативно и не всегда учитывается всё возможное. Это зависит как от самих этих систем, так и от интеграции системы на стороне дистрибутива. Но обе системы развиваются и, на мой взгляд, это шаг в правильном направлении, хотя обе системы часто критикуются. В основном критика относится к проприетарной природе серверной части Snap и тому факту, что в Ubuntu, при установке ПО через графический интерфейс, приоритет отдаётся пакетам Snap. Так же критикуется «Windows-подход» при распространении ПО подобным способом. Последнее относится, в основном, к размеру и нагрузке. Размер этих пакетов значительно выше традиционных пакетов, так как каждый пакет содержит все необходимые зависимости локально, и их наличие или отсутствие в системе во внимание не берётся. Но при объёмах современных носителей информации лишний десяток гигабайт менее важен, чем унификация пакетов в Linux.Для управления пакетами Snap и Flatpak используются их собственные пакетные менеджеры, но многие «традиционные» пакетные менеджеры имеют плагины для работы с этими пакетами. И так, если с зависимостями и различиями в дистрибутивах всё более или менее ясно, то при чём тут командная строка? Дело всё в той же централизованной системе. При обновлении пакетов, в системе часто обновляются и компоненты рабочего стола, и сам пакетный менеджер. Чем меньше компонентов задействовано в процессе обновления, тем меньше шансов на то, что что-то пойдёт не так. Графический интерфейс для всех пакетных менеджеров – это всего лишь «надстройка». Если установка и удаление пакетов обычно проходит гладко, то при использовании консоли у вас больше возможностей решить ту, или иную проблему, возникшую во время обновления. Особенно это актуально в роллинг-дистрибутивах, где со временем обновляется не только само ПО, но и список его зависимостей. Графический интерфейс может повиснуть при обновлении его компонентов, консоль же менее зависит от окружения рабочего стола, даже если является его частью. Не важно как вы обновляете Snap-пакеты или Flatpak-пакеты, так как они не затрагивают систему, но в остальных случаях обновляться через консоль безопаснее. В Сети часто можно найти инструкции по сборке того или иного из исходного кода и последующей установке (команда make install), но это плохая идея в пакетных дистрибутивах, где пакетный менеджер – основной и часто единственный инструмент контроля и управления программным обеспечением. Даже в Gentoo, где всё собирается из исходников, есть свои инструменты контроля. В пакетных же дистрибутивах правильным будет собрать пакет и установить его с помощью пакетного менеджера. Исключение можно сделать для чего-то локального, установленного в один отдельный каталог с правами пользователя. Ручное «размазывание» библиотек по системным разделам – плохая идея, так как рано или поздно возникнут проблемы.И так, резюмируя всё вышесказанное… Пакетные менеджеры в Linux существуют не только для удобства. Они ведут учёт ПО и обеспечивают правильность его установки, от чего зависит стабильность работы как самого ПО, так и операционной системы в целом. Установка ПО другими способами возможна, но с рядом оговорок. На самом деле, подобный подход кажется странным только тем, кто много лет просидел на Windows. В Windows так же есть эксперименты с пакетными менеджерами, но проприетарная модель как самой ОС, так и большей части программ под неё, не позволяет добиться той же слаженности, что мы видим в операционных системах на ядре Linux.

Go to Source
Author: Tatyana

Данный материал ориентирован на тех, кто ничего не знает о Linux, но заинтересовался этой темой. Я постараюсь максимально доходчиво объяснить некоторые нюансы, ответить на самые распространённые вопросы и развенчать некоторые мифы, связанные с Linux. Первое, что нужно знать любому, кто заинтересовался этой темой: Linux – это не операционная система. Это ядро. Операционная система – это готовая платформа, набор компонентов, позволяющий включить компьютер и тут же начать им пользоваться. Windows – операционная система. Для определённых задач вам понадобится определённое ПО, но ОС уже знает как его установить, как интерпретировать запросы, в ней уже есть всё необходимое. Ядро же – это что-то вроде основы. Все основные компоненты ОС взаимодействуют с ядром. Драйверы, интерпретаторы и всё то, о чём обычный пользователь мог и не слышать – всё это взаимодействует с ядром любой операционной системы. Скорее всего вы уже пользовались Linux и делали это чаще, чем вам кажется. Большинство периферийных устройств давно работают на Linux. Навигатор в вашей машине, роутер у вас дома, смартфон на Android у вас в кармане – всё это Linux, в подавляющем большинстве случаев. То, что Linux можно обнаружить на самых различных устройствах, связано, в первую очередь с тем, что Linux распространяется под свободной лицензией. У меня уже был материал, посвящённый разнице между «свободным» и «несвободным» ПО, поэтому сейчас мы эту тему развивать не будем. Первую версию Linux в 1991-ом году опубликовал финский разработчик Линус Торвальдс. Возникновение Linux в том или ином виде, было продиктовано временем. Компьютерные технологии развивались стремительно, но существующие проприетарные решения не могли удовлетворить все потребности. Рынком владели корпорации. По словам самого автора, он хотел написать свободную альтернативу Unix для личного использования. Но идея создания свободной операционной системы, которую каждый бы мог использовать без каких-либо значимых ограничений и финансовых затрат, со временем взяла верх. В то время, если разработчик хотел написать программу под определённую ОС, ему нужно было купить лицензию и/или оплатить доступ к API, что было проблемой. Не каждая программа способна окупить себя в будущем, да и цели такие перед собой ставят не все разработчики. В случае с проприетарным ПО и по сей день ситуация изменилась не сильно. Например, если некто хочет написать простенькое приложение под Xbox, то в самой консоли необходимо активировать «режим разработчика», что обойдётся в двадцать баксов. Не заоблачно, но, видимо, в Microsoft рассудили, что при жёсткой конкуренции и «с паршивой овцы хоть шерсти клок». Написание полноценной операционной системы – задача, мягко говоря, амбициозная. Особенно для одиночки. Но Линус Торвальдс был не одинок в своём стремлении создать открытую ОС. Поколение хиппи дало миру не только Стива Джобса с его ненавистью к IBM. На заре эры ПК были и более бородатые дяди, с более радикальными взглядами. Одного из них звали Ричард Столман. На момент выхода первой версии Linux, анархисты из проекта GNU уже имели множество прикладного ПО, но у них не было ядра. GNU и Linux дополнили друг друга. В том же 1991-ом году стали появляться первые дистрибутивы «GNU/Linux», включающие в себя ядро Linux и прикладное ПО из проекта GNU. «Дистрибутив» в данном случае – это ОС. Не все программы в современных дистрибутивах относятся к проекту GNU, но когда речь идёт именно о десктопной операционной системе, то правильно называть её «GNU/Linux». Операционные системы на ядре Linux (или дистрибутивы Linux) разрабатываются как компаниями (Ubuntu, Red Hat Enterprise Linux и так далее), так и сообществом энтузиастов (Debian, Arch Linux и прочие), но все они публикуют исходный код. Любой может внести свои изменения и если они будут приняты лидирующими разработчиками, то появятся в последующих релизах. Нередко от одних дистрибутивов ответвляются другие. Такие «форки» часто привносят что-то своё и ориентированы несколько на другую аудиторию, нежели их прародители. На сегодня существует множество различных дистрибутивов, нацеленных на разную аудиторию и придерживающихся определённых принципов. Часть из них продвигает свободное ПО как идею, другие же стремятся предоставить пользователю максимально широкий перечень возможностей. Есть также дистрибутивы для определённых целей, делающие упор на что-то одно. Например, дистрибутивы для работы с мультимедиа, дистрибутивы для диагностики, или дистрибутивы, ставящие во главу угла анонимность. При выборе дистрибутива, в первую очередь нужно руководствоваться причиной. Самая распространённая ошибка, это когда пользователь сам не знает, что он хочет. Просидел некто 20 лет на Windows и ищет тот же Windows, но чтобы это был Linux. Некоторые дистрибутивы позиционируют себя как «дружественные для новичков», переходящих с Windows. На самом деле, это плохая идея. Они с первого же момента знакомства пользователя с Linux, вводят его в заблуждение. Если пользователю нужен Windows, то идеальным для него вариантом будет Windows, а не Linux, внешне очень похожий на Windows. Чтобы быть дружественным к пользователю, не нужно что-то копировать. Достаточно просто иметь широкие возможности, хорошую документацию и дружелюбное сообщество. Когда пользователь, не знакомый с Linux, получает нечто, выглядящее как Windows, то он и ждёт от этого дистрибутива того же, к чему привык в Windows. Кроме внешнего вида, в такие дистрибутивы обычно вшит Wine (свободная реализация Win32 API) и они даже умеют запускать простенькие Windows-приложения «из коробки». Но Wine – это не Windows. Из-за проприетарной природы Win32 API, в Wine реализовано только то, что задокументировано Microsoft и то, что можно было воспроизвести путём обратного инжиниринга, не нарушая патентов и законов об авторском праве. Если программа использует не задокументированные свойства Win32 API, то она либо вообще не будет работать под Wine, либо будет работать с серьёзными ошибками. Другими словами, Linux – это не Windows. И ждать от ОС на ядре Linux полной совместимости с программами под Windows не следует. Это то же самое, что жаловаться в Microsoft на то, что в Windows не работают программы, написанные под Mac. Хотя, если последнее невозможно в принципе, то при определённых навыках можно играть во многие современные Windows игры на компьютерах с GNU/Linux. Но всё же, это абсолютно разные операционные системы. У Linux гораздо больше общего с MacOS, чем с Windows, так как и Linux и MacOS – это «юниксоподобные» операционные системы. Но даже при похожей структуре, нельзя запустить программу из Linux на Mac и наоборот. Мало того, не всегда просто запустить приложение для одного дистрибутива на другом. Но в Linux можно добиться внешнего вида как Windows, так и MacOS (на скриншотах в этом абзаце дистрибутивы Linux, а не другие операционные системы). На что и ведутся те, кто ждут от Linux чудес. В Википедии есть забавная картинка, иллюстрирующая «генеалогическое древо» всех дистрибутивов, и она оставляет неизгладимое впечатление на тех, кто пытается выбрать свой первый дистрибутив. Но на самом деле, кардинально друг от друга отличаются лишь узко направленные дистрибутивы или дистрибутивы для различных устройств. Например, нельзя без эмуляции на Ubuntu запустить приложение из Google Play, хотя и в Android и в Ubuntu используется ядро Linux. Так же стоит понимать, что львиная доля дистрибутивов – форки от общего предка. Например, Ubuntu – форк от Debian, Linux Mint – форк от Ubuntu и так далее. «Корневых», ныне живущих дистрибутивов не так много. Это Slackware, Red Hat Enterprise Linux, S.U.S.E, Debian, Arch Linux, Gentoo. Это дистрибутивы, от которых произошли все настольные дистрибутивы широкого профиля, и разобравшись в предке, вы сможете разобраться в производных. Также, если вы освоите качественный форк, то разобраться в материнском дистрибутиве тоже будет легко, за редкими исключениями. Например, знания в Android вам вряд ли помогут при работе с Gentoo, но умение обращаться с Linux Mint сильно облегчит работу с серверной Debian. Теперь о самых распространённых мифах. «Linux нестабилен и часто глючит». Это не так. Более 90% всего Интернета работает на Linux. От серверов гигантов типа Google, до домашних роутеров. Интернет был бы невозможен без стабильности решений на Linux. Интернет многим был бы не по карману без свободного ПО в целом, львиная доля из которого – решения на Linux. Но действительно, существует много косых дистрибутив. Глючит, как правило, плохо отлаженное прикладное ПО в таких дистрибутивах. Это всевозможные «как Windows» дистрибутивы и дистрибутивы «одного разработчика», которые «глюк в глюк» повторяют родительский дистрибутив, но при этом нагружены неотлаженным прикладным ПО. Если правильно подобрать дистрибутив, то стабильность будет выше, чем в любой существующей проприетарной ОС. Глюки в проприетарной ОС исправляют годами (Windows 10 вам в пример). Если вы пользуетесь хорошо поддерживаемым дистрибутивом, то исправления придут практически сразу, как наличие проблемы будет подтверждено, что происходит быстро из-за большого числа вовлеченных в разработку людей. «Под Linux мало программ». Это тоже не так. Их не меньше, чем под Windows, но они часто доступнее. Нередко бывает так, что аналог в Windows стоит несколько сотен долларов, а в Linux такая программа бесплатна. Хотя абсолютной халявы нет нигде. Например, Google Chrome под Linux и под Windows выпускает одна компания. Естественно, что пользователь этого браузера одинаково комфортно будет себя чувствовать как в Windows, так и в Linux. Но Adobe не выпускает Photoshop под Linux, и пользователю придётся искать аналог. Ближайший аналог, в данном случае – Gimp. И он попьёт немало крови, если подойти к нему с уверенностью, что он должен быть клоном Photoshop. Это две разные программы, предназначенные для решения схожих задач. Для Linux существует множество как бесплатных, так и платных программ, но немалая их часть не знакома пользователям других ОС. «В Linux всё нужно делать с командной строкой». Это было актуально 30 лет назад, когда в Linux не было графического интерфейса. После появления X.Org, в 2004-ом году, программы стали обрастать графическими интерфейсами, и Linux дистрибутивы стали выглядеть как любая другая настольная ОС. Вы можете выучить пару базовых команд и обходиться ими, а можете обойтись вообще без консоли. Во всех современных дистрибутивах широкого профиля консоль – инструмент опциональный. Но умение пользоваться консолью значительно облегчает жизнь при отладке и решении рутинных задач, таких как обновление, редактирование системных файлов и так далее. Тоже самое касается любой другой ОС. В Windows тоже командная строка – мощный и быстрый инструмент с более широкими возможностями, чем любой графический интерфейс, если грамотно ею пользоваться. «В Linux почти нет игр, а те, что есть, выглядят как из прошлого века». На сегодня это утверждение близко к истине, но не в том плане, в каком многие привыкли считать. Игры – сугубо развлекательное ПО. Производство качественной игры стоит больших денег, а аудитория Linux достаточно мала. Абсолютное большинство коммерческих игр на Linux – это порты с других платформ. Качественное портирование игры также требует большой работы и финансовых затрат. Это окупается при портировании игр с консолей на Windows, но не оправдывает себя в случае с Linux. Даже самый качественный порт под один дистрибутив, может странно вести себя на другом. Эту проблему пытается решить компания Valve, но с переменным успехом. На сегодня в Steam доступно огромное количество игр под Linux. Несоизмеримо больше, чем лет десять назад, но часть из них не работает на Linux нативно. Связано это с тем, что традиционно пакеты ПО в Linux не содержат всё необходимое для работы. Часть библиотек находится в системе. К ним и обращаются программы. Если игра старая, то версии системных библиотек, прописанных в игре как зависимости, давно устарели. Либо вообще заменены на другие на стороне дистрибутива. И речь не идёт о десятках лет. ПО в Linux безнадёжно устаревает за пару лет. В Steam под Linux есть набор универсальных библиотек (Steam Runtime), но из-за серьёзных различий в некоторых дистрибутивах, работает это не всегда. Система Proton (пропатченный Wine) позволяет запускать достаточно много игр в Linux, написанных под Windows, но большая их часть поддерживается неофициально, а значит никто не даст вам гарантию, что завтра оно не перестанет работать. То есть, проблема не в Linux ( под Android существует великое множество игр), проблема в разнообразии дистрибутивов. А так же в замкнутом круге, где корпорации не вкладывают деньги в нативные игры под Linux, объясняя это низким спросом. От этого спрос ещё ниже, так как многих именно игры держат на Windows. Нередко на ПК используется двойная загрузка, когда Windows используется исключительно для игр, а для всего остального пользователь перезагружается в Linux. Такая ситуация устраивает всех, кроме пользователей. Другими словами, если вам нужна игровая ОС, то это Windows. Либо можно использовать двойную загрузку. Либо приготовьтесь к тесному знакомству с Wine, что требует терпения и ментальной стабильности в стрессовых ситуациях, но не гарантирует вам запуск всей вашей библиотеки игр. Другими словами, игр в Linux великое множество, но мало качественных нативных игр. Эмуляция в Linux потребляет меньше ресурсов и при правильной настройке работает быстрее, чем в Windows. То есть, старые игры под DOS и консоли поколений 8 – 128 bit будут работать лучше, чем в Windows. Wine же поможет запустить многие игры, написанные под Windows. Нередко с более высокой производительностью. Например, на моём старом ПК с AMD FX8350 ремейк Resident Evil 2 работает идеально под Linux, но периодически сваливается в 20-30 fps под Windows. И так, чем нужно руководствоваться при выборе дистрибутива в первую очередь? Если вам нужна настольная ОС «на каждый день», то многие советуют начать с чего-нибудь «попроще» и с того, где вам проще получить помощь. Есть Ubuntu – один из самых популярных дистрибутивов. Он имеет огромную базу совместимого ПО, и большая часть инструкций в Интернете посвящена именно Ubuntu, или её производным. Я же рискну с этим поспорить. Популярность в мире Linux – понятие относительное. Никто не скажет вам сколько именно пользователей того или иного дистрибутива в мире, так как почти никто не продаёт на них лицензии. Относительно точное количество пользователей Windows можно посчитать по количеству активации, в Linux же даже user-agent браузера очень редко показывает имя дистрибутива. Никто не спорит с тем, что Ubuntu и производные занимают значительную часть всех Linux дистрибутив, но стабильность – это более сложная тема. Пакеты в Ubuntu попадают из нестабильного репозитория Debian. И называется он «нестабильным» не просто так. Отладка и тестирование пакетов требует огромной работы. К сожалению, в Ubuntu вся отладка часто происходит после релиза. Видимо это проклятие всех корпораций, независимо от продукта. И текущий дистрибутив Ubuntu становится стабильным ближе к сроку выхода следующего. Именно поэтому у Ubuntu так много форков. Каждый позиционирует себя более стабильным, чем родитель. Однако нередко они баг в баг повторяют Ubuntu, когда это касается внутренних процессов. Не всё так плохо с Ubuntu и часто дистрибутив стабилен, но до тех пор, пока вы не попытались что-либо в нем переделать. Для решения определённых задач нередко приходится подключать сторонние репозитории, что-то удалять и что-то устанавливать. И нередко после манипуляций с ядром, его модулями, или с рабочим столом, Ubuntu перестаёт загружаться. И такое можно сказать о многих дистрибутивах. Вместо того, чтобы навязывать тот или иной дистрибутив, я попробую объяснить нюансы работы некоторых. Я буду брать в пример «материнские» дистрибутивы, перечисленные выше, так как все их производные работают по тому же принципу. Все популярные дистрибутивы – пакетные, кроме Gentoo. Что это значит? ПО в них устанавливается в виде готовых пакетов. Пакет – это, по сути, zip-архив со скомпилированной именно под ваш дистрибутив программой. Пакеты хранятся в так называемых репозиториях. То есть для установки того или иного пакета вам нужно либо ввести специальную команду в терминал, либо воспользоваться графическим интерфейсом. Выглядит это как установка приложений в Android. Вы ищите нужную программу, кликаете кнопку «установить», и она устанавливается со всеми другими, необходимыми для её работы пакетами. Этим занимается «пакетный менеджер», который в современных дистрибутивах имеет графический интерфейс, работающий поверх консольной программы. С его же помощью происходит и удаление программ. Кроме основных репозиториев, существуют также «сторонние». Их часто создают разработчики того, или иного ПО. Например, для установки Google Chrome в Ubuntu нужно добавить отдельный репозиторий, так как в основных репозиториях практически всех дистрибутив нет проприетарных программ. Звучит сложно, но происходит всё в один клик. Так же, с помощью пакетного менеджера происходит обновление установленного ПО. Централизованно, в один клик, или одну команду в терминале. Упомянутый выше Gentoo – худший вариант для новичка. Даже если у вас получится его установить, то работа с ним покажется адом не только пользователям Windows, но даже адептам Ubuntu. Установка ПО в нём происходит путём сборки каждого компонента из исходного кода. Вам нужно не только уметь собирать бинарники из исходного кода, но и знать, что от чего зависит. Это тоже не так ужасно, как звучит, так как в Gentoo есть инструменты для облегчения и частичной автоматизации процесса, но для новичка в Linux, задача непосильная. Плюсом подхода Gentoo является низкое потребление ресурсов. Программы собираются не только под ваш дистрибутив, но непосредственно под ваш ПК и под ваши нужды. Например, если у вас CPU и GPU от Intel, то поддержки nVidia и AMD не будет даже на уровне ядра, что значительно сократит размер установленного ПО и увеличит скорость его работы, путём удаления бесполезного для вашей машины кода. Что в свою очередь выльется в целую эпопею, если вы решите модифицировать или обновить свой ПК. Так же есть мнение, что если вы освоили Gentoo, то, не краснея, можете называть себя специалистом в Linux. Справедливости ради надо заметить, что пакетные дистрибутивы просто удобнее, а сборку персонального ядра и прикладного ПО можно освоить и в них. Кроме того, можно освоить сборку пакетов под ваш дистрибутив и стать участником проекта по его поддержке, если процесс вас зацепит. Кроме «странной», для пользователей Windows, системы управления пакетами, в дистрибутивах отличается цикл их разработки. Например, новая версия Debian выходит каждые два года. С тем же циклом Canonical выпускает «стабильные» версии Ubuntu. Так называемые «версии с долгосрочной поддержкой» или TLS. Такие версии поддерживаются на протяжении пяти лет и в конце своего срока становятся действительно стабильными, в полном смысле этого слова. «Стандартные» версии Ubuntu выходят каждые 6 месяцев и тоже позиционируются как стабильные, но по сути, это пререлизные бета-версии того, что потом станет TLS-релизом. Срок жизни таких версий 9 месяцев. По истечении этого срока дистрибутив перестаёт получать обновления, даже критические. Стоит иметь ввиду, что обновление старой версии дистрибутива на новую – это всегда геморрой. Разница лишь в степени, что зависит от дистрибутива и того, на сколько и как вы изменили его состав за время использования. Возможно вам удастся обновить одну TLS-версию Ubuntu на следующую (но не через одну), если вы вообще никак не трогали его системные компоненты в процессе использования, и только устанавливали критические обновления. Но чаще всего предпринятые усилия не стоят конечного результата. Самым простым способом обновления является переустановка дистрибутива. Если вы установили его правильно (систему в один раздел накопителя, а пользовательскую часть «home» в другой), то сможете даже сохранить все данные и настройки программ. Это займёт меньше времени, чем обновление с одной версии дистрибутива на другую и последующие попытки победить глюки, которые неизбежно появятся в большинстве дистрибутивов. Также при выборе дистрибутива стоит учесть, что во многих «цикличных» дистрибутивах версия пакетов замораживается ещё на пререлизной стадии. Особенно это заметно в Debian. Исключение делается только для некоторых пакетов. То есть, в большинстве случаев вы не просто не получите новый функционал в рамках одной версии дистрибутива, но и минорные версии прикладного ПО будут те же, что были во время релиза. В Debian приходят только критические исправления. Вы можете ожидать исправления багов и закрытия дыр безопасности, но не новых возможностей, доступных в более поздних версиях ПО. В той или иной степени такой подход практикуется во всех дистрибутивах с подобным циклом разработки. Это часто можно обойти путём использования сторонних репозиториев. Чем популярнее дистрибутив, тем больше у вас будет возможностей касательно прикладного ПО. Но использование сторонних репозиториев критического для системы ПО влечёт за собой ряд рисков. Риски безопасности и стабильности в первую очередь. Нужно доверять владельцам репозитория. Однако, в мире свободного ПО, если кто-то попытается вшить вам в пакет какую-нибудь бяку, об этом быстро станет известно. Но это не повод подключать первые, попавшиеся на глаза репозитории, так как криворукость является не меньшей бедой, чем злой умысел. Также некоторые дистрибутивы придерживаются «rolling» цикла разработки. Такой цикл подразумевает «бесконечное» обновление дистрибутива по мере выхода новых версий ПО. Роллинг-версии могут быть и у «цикличных» дистрибутивов. Например, S.U.S.E имеет две версии дистрибутива, среди которых одна версия – роллинг. Недавно Red Hat объявила о том, что CentOS отныне будет придерживаться роллинг-модели. Когда дистрибутив имеет роллинг-версию, это как правило говорит о том, что это тестовая версия их основного дистрибутива. Как бы они его не называли, но часто за модным именем скрывается публичная альфа-версия. Но есть дистрибутивы, для которых роллинг-модель является основной и единственной. Например, Arch Linux. У него вообще нет версий. Она всегда последняя и всегда называется Arch Linux. И это не значит, что Arch – мешок неотлаженного ПО, упаковано в дистрибутив. Как и у любого другого дистрибутива, у Arch Linux есть нестабильные репозитории для разработчиков, тестовые для тестировщиков и стабильные репозитории для обычных пользователей. Чистый Arch Linux сложен для новичка, но у него много форков, которые позиционируют себя как «дружественные для новичков». Например, Manjaro для новичка не сложнее Ubuntu, но вы получите всегда свежее ПО и всю мощь Arch Linux. Дистрибутивы как Manjaro, являются «semi-rolling» дистрибутивами. Они не обновляются постепенно и бесконечно, но периодически выпускаю «пачку» обновлений практически на всё. В случае с Manjaro, обновления выходят пару раз в месяц. Разработчики Manjaro берут стабильные версии пакетов из Arch Linux и помещают их в «нестабильную» ветку своих репозиториев. И далее всё так же, как у всех: отладка, тестирование и стабильный релиз. Таким образом пакеты в Manjaro выходят, примерно, с двухнедельной задержкой, по сравнению с Arch Linux, но позиционируются как более стабильные. Это как если бы полугодичные версии Ubuntu выходили пару раз в месяц, обновлялись без переустановок и по стабильности не уступали TLS-версиям на третьем году жизни. Каждый тип цикла разработки имеет свои плюсы и минусы, но всё зависит от разработчиков. И роллинг релизы могут быть стабильными, если цель разработчиков именно стабильность, а не тестирование новых возможностей для своего основного дистрибутива. Из личного опыта скажу, что предпочитаю semi-rolling модель. Но всё зависит от потребностей и интенсивности использования. Следующее, на что следует обратить внимание при выборе дистрибутива – на сколько он популярен, и на сколько вменяемое у него сообщество. Популярность – показатель того, как быстро вы получите помощь в случае проблем. От сообщества же зависит, на сколько качественной будет эта помощь, и на сколько само сообщество толерантно к новичкам. Например, когда читаешь форумы Arch Linux, складывается впечатление, что абсолютное большинство отвечающих свято верит в непролазную тупость обратившегося с вопросом, равно как в свою врождённую гениальность. Даже официальная Wiki подразумевает, что читатель далеко не новичок не просто в Linux, но именно в Arch Linux. Темы же по Ubuntu часто изобилуют слабоумием «экспертов». И если слепо следовать их советам, то система рухнет быстрее, чем при самостоятельных экспериментах в неизвестных областях. При этом официальная документация похожа на Wiki Arch Linux, хотя и содержит больше законченных практических примеров. Так же при выборе дистрибутива стоит знать, что в отличии от Windows и Mac, в мире Linux несколько рабочих столов. Имеется ввиду не набор ярлыков с обоями, а сама среда. Это файловый менеджер, всевозможные настройки и прикладное ПО. На пример, в Windows, если не брать во внимание весь мусор, поставляемый с Десяткой, рабочий стол – это всё окружение, которое вы получаете при первом запуске. Текстовой редактор для открытия текстовых файлов, медиа плеер для воспроизведения аудио и видео, программы для открытия изображений, архивов и так далее. Весь графический интерфейс, позволяющий вам взаимодействовать с операционной системой. Без рабочего стола это будет чёрный экран и командная строка. Учитывая тот факт, что многие программы в Linux (особенно программы из проекта GNU) содержат графический интерфейс как компонент (могут работать и без него), то система без рабочего стола будет вполне функциональна. Но для новичка, даже видевшего голый DOS, функциональность будет чисто теоретической. В Linux существует множество рабочих столов, но, как и в случае с дистрибутивами, большинство из них являются форками или написаны на основе более ранних. Два основных и самых распространённых – Gnome и KDE. Для новичка основным показателем является внешний вид, а об удобстве использования впечатления складывается позже. Если утрировать, то Gnome больше похож на Mac, KDE на Windows, и не только внешне. Если подойти к вопросу более детально, то Gnome, к сожалению, с каждым новым крупным релизом всё ближе к философии «мы лучше знаем, что вам нужно». Ситуация может измениться в четвёртой версии, но я не питаю по этому поводу излишних иллюзий. При этом Gnome достаточно элегантен и функционален, особенно в тех дистрибутивах, где не оставили всё по умолчанию, как в Debian. KDE даёт гораздо больше возможностей в персонализации. Практически любой каприз можно исполнить через командную строку и правку конфигурационных файлов, но многое доступно и через настройки в графическом интерфейсе. KDE потребляет немного больше ресурсов в сравнении с Gnome, но это заметно лишь на реально слабых или очень старых машинах. KDE так же легко уронить, если бездумно лезть во все настройки. Оба рабочих стола полнофункциональны и современны. Форки часто возникали из-за неприятия курса развития рабочего стола. Так рабочий стол Mate изначально являлся форком Gnome. Третья линейка Gnome так сильно отличалась от второй почти во всём, что это вызвало бунт среди пользователей и в кратчайшие сроки возник форк. Теперь же, это полнофункциональный, современный рабочий стол, но внешне похожий на Gnome 2. Производные от KDE или Gnome рабочие столы, часто преследуют конкретные цели. Есть минималистические рабочие столы, потребляющие минимальное количество ресурсов. Есть рабочие столы, где главное – это элегантность, даже если это идёт в ущерб производительности или функциональности. И так далее… Рабочий стол является одной из главных составляющих при выборе дистрибутива. Если вам неудобно в окружении вашего рабочего стола, или его внешний вид вводит в уныние, то удовольствия от работы в нём вы не получите. А удобный и красивый рабочий стол иногда позволяет закрыть глаза на минорные баги самого дистрибутива. И так, резюмируя всё вышесказанное, на что нужно опираться при выборе дистрибутива? На наличие в нём возможностей удовлетворить все ваши требования к нему, а уже потом на его популярность и прочее. Если вы много лет просидели на Windows, то нужно понимать, что его клонов не существует. Любая другая ОС – это всегда новый опыт и неизбежные вопросы. Рассмотрите возможность двойной загрузки, пока не поймёте, что освоили всё, что вам нужно и вас всё устраивает. Если единственное, для чего вы используете компьютер – это игры, то даже «игровые» дистрибутивы не заменят вам Windows, по крайней мере на сегодня. Если же вы вообще новичок в компьютерах, то правильно подобранный, современный дистрибутив, окажется не сложнее любой другой ОС, существующей сегодня на рынке. Также стоит иметь ввиду, что какой бы дистрибутив вы не выбрали, он вряд ли станет последним. Рано или поздно вам станет тесно в его возможностях, либо просто захочется нового опыта. Дистрибутивы появляются и исчезают. Даже самый лучший на сегодня дистрибутив, через пару лет может перестать отвечать как вашим личным требованиям, так и требованиям времени. Но в мире Open Source любую опустевшую нишу всегда заменит кто-то другой. Вы всегда сможете найти что-то, что будет отвечать вашим требованиям.

Go to Source
Author: Tatyana

Недавно мне на глаза попалась статья о разнице между проприетарным и открытым ПО. Статья была опубликована на BBC, от чего читать её было особенно тошно. Там было много букв, но смысл сводился к следующему: свободно ПО – ПО с открытым исходным кодом, и любой может его использовать. По той же причине качество такого ПО гарантировать никто не обязан. А также на него не распространяется авторское право. Проприетарное же ПО является объектом интеллектуальной собственности, и получить его можно только путём покупки лицензии. Основные тезисы даже выделены в рамочки. И оно не бросилось бы в глаза, если бы это был блог Васи Пупкина из начальной школы. Но тут пройти мимо было нельзя. Статья выглядит как сочинение первоклассника, который не выучил тему, по которой вынужден писать. “Трава зелёная, небо синее, а в Китае живут китайцы”. Но статья не просто не о чём. Она вводит в заблуждение рассуждениями автора, который не в зуб ногой ни в юридической части, ни в практической. И так, чем же отличается проприетарное ПО от свободного? Исходным кодом. В проприетарном он закрыт, в свободном он открыт. Других различий в нём нет. Всё остальное – нюансы, зависящие от разных факторов. И вообще, сам термин “свободное ПО” не совсем корректен. Red Hat Enterprise Linux – операционная система с открытым исходным кодом, лицензия на которую, в большинстве случаев, стоит дороже, чем лицензия на Microsoft Windows 10 Pro. При этом последняя – стопроцентный проприетарный продукт. Проприетарное и ПО с открытым исходным кодом может распространяться как бесплатно, так и за деньги. Например, Skype распространяется бесплатно, но это проприетарное ПО. Упомянутая же выше ОС от Red Hat стоит денег несмотря на открытый исходный код. Здесь уже в силу вступают различные лицензии, коих множество, и перечисление их особенностей заняло бы слишком много времени. Понятие “Свободное ПО” – это больше философия, нежели чёткая модель. Для обывателя “свободное” – часто синоним “бесплатного”, что в корне неверно. Так называемая ShareWare модель подразумевает бесплатное распространение проприетарного ПО, защищённого копирайтом. Его нельзя использовать каким-либо другим способом, не оговоренным в лицензионном соглашении. Тогда как понятие “свободное ПО” подразумевает отсутствие вообще каких-либо ограничений, что так же закреплено в лицензии на это ПО (так называемый copyleft). Яркий пример – лицензия BSD, под которой выходит операционная система FreeBSD. Код FreeBSD открыт и его использование не накладывает практически никаких обязательств. Лицензия всего лишь обязывает к упоминанию первоисточника в производных продуктах. Свободное ПО – не синоним понятия “Open Source” (открытый исходный код). Варианты лицензии GPL, под которой выходит Linux и большая часть компонентов операционных систем на его основе, обязывает к публикации любого производного ПО под той же лицензией. Другими словами, нельзя взять код Linux и на его основе выпустить проприетарный продукт. То есть это не совсем “свободное ПО”. Существует ряд лицензионных ограничений.Microsoft в своё время вела настоящую войну против Open Source продуктов, что сводилось, в основном, к дискредитации. Их бывший генеральный директор, Стив Балмер, при каждом удобном случае, как мантры повторял пророчества о неминуемой скорой смерти подобного ПО и невозможности его широкого применения. На самом деле открытый исходный код просто угрожает их моделе распространения собственного ПО. На момент выхода Windows XP на серверах Microsoft использовалась ОС FreeBSD. И по сей день львиная доля серверного ПО по всему миру – это Open Source. Связано это с тем, что в мире Open Source невозможно возникновение монополий, а Microsoft – первое, что приходит на ум в связке со словом “монополия”. Потребитель не зависит от отдельно взятой корпорации. Если кто-то начинает выпускать некачественный продукт и просить за него несоизмеримые деньги в мире открытого кода, на его место тут же придёт другой и предложит тот же инструмент, но надёжнее и дешевле. Отсюда же следует, что качество готового решения – одна из основных определяющих при выборе. Как бы выглядел Интернет сегодня, если бы какая-нибудь корпорация владела правами на всё серверное ПО? Для конечного потребителя контента доступ в Интернет был бы событием. Стоило бы это не дёшево. С точки зрения развития технологий, Open Source так же является двигателем. Проприетарное ПО – это всегда сложные лицензии и патенты. Проще написать что-то с нуля, чем исправить чужой продукт. Да и сами владельцы прав не очень-то спешат, когда дело касается новшеств и исправления некритических багов. Особенно если прямых конкурентов на рынке нет. Никто не ждал бы несколько лет, пока Microsoft исправит систему обновлений Windows, будь исходный код открыт. Тут же бы возникло несколько форков, да и сама Microsoft всё бы исправила в кратчайшие сроки, дабы остаться на рынке. С коммерческой точки зрения открытый код тоже работает, но не приносит миллиардов с продаж копий. Деньги зарабатываются в основном на сопровождении продукта, а не на выпуске. Если сравнивать модели, то тут не всё однозначно. Для конечного потребителя высокий уровень конкуренции всегда на пользу, так как больше выбор и ниже цены. Большинству не важно, открыт исходный код продукта, или закрыт, так как разобраться в нём неспециалисту практически невозможно. Но при открытом коде всегда возможен независимый аудит. Если готовый продукт делает что-то, согласно заверениям разработчиков, делать не должен, то об этом сразу станет известно. Тогда как в случае использования проприетарного ПО, отношения разработчика и потребителя строятся исключительно на доверии, так как никто, кроме самого разработчика, не скажет, что именно содержится в коде. Что именно делает программа в ваше системе, куда и какие данные она передаёт – всё на совести производителя. Если разработчик продукта выпускает что-то инновационное, но не знает как на нём заработать, кроме как брать деньги за копии, то проприетарная модель для него предпочтительнее. В случае открытого исходного кода продукт тут же уйдёт “в народ” и зарабатывать на нём будет тот, кто первый придумает как. Факт разработки будет красиво смотреться в резюме, но денег не принесёт. Если разработчик знает как заработать на продукте, у продукта большие перспективы развития, но хромает реализация, то модель “Open Source” поможет добиться большего. Например, Линус Торвальдс в 2020-ом году внёс вклад в код текущего ядра Linux на 3,19 процента. То есть, это его правки, а всё остальное – частные сторонние разработчики и корпорации. Я не хочу сказать, что его реализация изначально хромала, но он был один. И где был бы Linux сейчас, если бы Линус изначально выбрал проприетарную модель? Однако и в мире открытого исходного кода развитие тоже не всегда стремительное. На сегодня из мира Open Source именно Linux со своей “ShareAlike-подобной” лицензией доминирует на настольных ПК, а не FreeBSD с практически “копилефтной”. Как уже было сказано выше, BSD не обязывает публиковать исходный код производных продуктов. Имеется в виду, что без лишней пляски вокруг лицензий, разработчики будут брать код и в равной степени вкладывать в него свои наработки, которые так же будут доступны всем. На практике же мало кто знает, что в MacOS используется кодовая база BSD (предок FreeBSD), а операционная система в Playstation от Sony основана на FreeBSD, тогда как в самой FreeBSD дела с играми, мягко говоря, не безоблачны. Лицензия же Linux обязывает публиковать исходный код, от чего развивается всё это очень стремительно. Ядро Linux писалось как свободная альтернатива Unix, и первый релиз состоялся в 1991-ом году. Тогда же и состоялся первый релиз ОС на этом ядре. Старейший из ныне живущих дистрибутивов – Slackware, вышел в 1993-ем. BSD же увидела свет аж в 1977-ом и была ответвлением уже существовавшей на тот момент, Unix. FreeBSD вышла тогда же, когда и Slackware – в 1993-ем. И на сегодня разница между FreeBSD и Linux для домашнего, повседневного использования очевидна. И она не в пользу FreeBSD. И так, как видно из всего вышесказанного, существует два основных типа программного обеспечения: проприетарное и ПО с открытым исходным кодом. В этом и их принципиальная разница. Речь не о том, что лучше или хуже. Оба типа имеют как свои плюсы, так и свои минусы, что в свою очередь зависит от множества факторов. Оба типа имеют право на существование и совсем не очевидно, что какой-то тип рано или поздно победит. На мой сугубо личный взгляд, Open Source будет доминировать в будущем, но в конечных продуктах будут применяться гибридные решения. Проприетарное ПО может занять какие-то определённые ниши, но всегда будет на рынке в том или ином виде, если не произойдет какого-то революционного изменения в мире ПО в целом. Например, Skynet вряд ли будет руководствоваться различиями между этими двумя типами ПО при конвейерной штамповке терминаторов. Но пока этого не произошло, речь будет идти только о процентах, а не победе одного над другим.

Go to Source
Author: Tatyana

Кроме того, что компания Google – поисковый гигант и крупнейшая транснациональная корпорация, она так же знаменита спорыми решениями по поводу своих продуктов и сервисов. Одно из таких решений было озвучено совсем недавно. Google объявила об удалении ряда API из проекта Chromium и ChromiumOS. Список API, доступ к которым будет прекращён с 15-го марта 2021-го года: Google account sync, Geolocation, Click to Call, Chrome spelling API, Contacts API, Chrome translate element, Safe browsing. Для тех, кто не знает, Chromium – кодовая база, из которой впоследствии собирается браузер Google Chrome. Конечный продукт выпускается под собственной лицензией, тогда как Chromium — это Open Source. Несмотря на то, что львиная доля финансирования Chromium поступает от Google, открытый исходный код проекта позволяет сторонним компаниям использовать его для сборки собственных браузеров. Таких браузеров множество. Кто-то берёт код Chromium за основу, добавляя ряд собственных наработок и сервисов, кто-то просто переписывает логотипы. На текущий момент Chromium – основа для всех крупных игроков на рынке. Это и Microsoft со своим Edge, Mozilla со своим Firefox, Opera с одноимённым браузером и так далее. В России так же есть множество примеров “отечественных” браузеров с разной степенью жизнеспособности. В разное время пересборкой Chromium занимались Rambler, Mail Ru, Ростелеком и список можно продолжить. Один из самых удачных и жизнеспособных примеров — это Яндекс Браузер, так же основанный на Chromium, но использующий инфраструктуру Яндекс (перевод страниц, интеграция аккаунтов, синхронизация с серверами Яндекса и так далее). В Google своё решение объяснили соображениями безопасности. Но всем понятно, что дело не только в этом, так как около семи лет проблемы в этом никто не видел. Дело в том, что ряд браузеров на основе Chromium используют инфраструктуру Google. Это и синхронизация данных (таких как закладки, пароли и прочее) и ряд других функций, связанных с вышеперечисленными API. Крупные компании заменяли всё это своими сервисами, тогда как “на коленке писанные” решения от игроков поменьше, выходили с собственным логотипом, но в связке с аккаунтом Google. В Google решили положить этому конец. Как это решение повлияет на обычного пользователя? На пользователей Mac и Windows почти никак, если пользователь не использует малоизвестный браузер со вшитой авторизацией в Google. Имеется ввиду авторизация в настройках самого браузера. Если там используется Google аккаунт, то с 15-го марта у таких пользователей начнутся проблемы. Для пользователей же десктопных операционных систем на ядре Linux дела обстоят сложнее. Несмотря на то, что официально Chromium не имеет готовых сборок для повседневного использования, репозитории всех крупных дистрибутивов содержат таковые. Это опять же связано с тем, что Chromium — это Open Source. Для большинства дистрибутивов это тот же Chrome со всеми его возможностями, но с другим логотипом. Отследить аудиторию Chromium практически невозможно, так как user-agent у Chrome и Chromium один и тот же, но подавляющее большинство пользователей Linux используют именно Chromium. И это проблема. Те, кто не следит за новостями в мире ПО, столкнутся с невозможностью авторизации в Google. Выглядеть это будет как сбой на стороне Google, или баг на стороне дистрибутива. При этом “шатдаун” затронет не только новые версии браузера, но и старые. То есть даунгрейд не поможет, даже если абстрагироваться от всех других очевидных негативных последствий подобного решения. Очевидно, что Google таким образом пытается убить двух зайцев одним выстрелом: перевести всех пользователей Chromium на официальный Google Chrome и избавится от паразитирующих на их инфраструктуре сторонних производителей браузеров. Но на самом деле дальнейшее предсказать трудно. Скорее всего аудитория Google Chrome сократится. По крайней мере в мире Linux. Для большинства дистрибутивов установка Google Chrome – не проблема. Но закрытый код не даёт возможности произвести более тонкую оптимизацию на стороне отдельно взятого дистрибутива, кроме простой переупаковки пакета. Так же политика многих дистрибутивов не позволяет им иметь проприетарное ПО в основных репозиториях. Google же не может гарантировать стабильность на всех дистрибутивах из-за их множества. Официально в Google поддерживают только Debian, Ubuntu, Fedora и openSUSE. Пользователям других дистрибутивов предлагается Chromium. Таким образом, для большинства пользователей Linux пришла пора либо менять браузер, либо искать сторонние сервисы по синхронизации закладок и паролей, если закладки и пароли — это единственное, что будет проблемой после отключения API. Также хочу заметить, что отключение API не повлечёт за собой удаление всей информации. Все данные по-прежнему будут храниться в Google, и доступ к ним будет возможен через Google Chrome.

Go to Source
Author: Tatyana