Приватный узел TOR

На этом сайте уже есть несколько заметок, посвящённых сети TOR. Написаны они около семи лет назад, и многое изменилось. В этом материале мы сосредоточимся на «мостах». Судя по всему, это наиболее актуальная тема в русскоязычном сегменте Интернета на данный момент. Нам понадобится следующее: • Знание Linux на уровне чуть выше поверхностного. • Английский язык (поднятие моста на хостинге в России не имеет смысла). • Понимание основных принципов работы TOR. • Около пяти долларов ежемесячно. • Желание.Если вы периодически пользуетесь TOR браузером и он у вас перестал соединяться с Сетью, то в поисках решения проблемы вы могли видеть посты в Рунете относительно версий браузера и прочих костылей, посты «ботов» в стиле «мне нечего скрывать» и тому подобное. Даунгрэйд версии браузера — плохая идея по многим причинам. Если это баг, то он будет исправлен. Троллей обсуждать мы не будем вовсе… TOR трафик, как и любой другой специфический трафик имеет ряд «маркеров», по которым его можно идентифицировать. Да, трафик шифрованный, но DPI и прочие игрушки вполне себе способны положить по определённому признаку весь TOR поток и (в случае с Роскомнадзором) всё, что на него похоже. Да и сам браузер находиться у вас на локальном компьютере, использует стандартные порты и передаёт трафик через вашего провайдера. Все узлы сети TOR публикуются в открытом доступе, включая мосты. Другими словами, сеть TOR спроектирована как инструмент обхода «заглушек» и анонимизации передаваемых данных. Она не способна стать невидимой по причине того, что она публична по умолчанию. Большинство людей без каких-либо регуляторов способно отличить хорошее от плохого и законное от противозаконного. К сожалению непринятие пользователем сетевого эксгибиционизма воспринимается регулятором как преступление. Усовершенствование кошки всегда ведёт к эволюции мышки. Рассмотрим вариант «анонимного» моста. Слово взято в кавычки потому что вы арендуете сервер у легитимного провайдера, платите ему не криптой и в процессе оставляете столько следов, что умысел на что-либо злое и аморальное говорит больше о пользователе, нежели о самой технологии. На этом сайте всегда рекомендовали Digital Ocean в качестве провайдера. Хочу добавить к нему Linode, как альтернативу. Цены и условия у обоих провайдеров практически идентичны (за исключением региональной политики взимания НДС). Linode более старый провайдер, вышедший на рынок в начале нулевых. Digital Ocean на рынке около десяти лет, но по технической части по некоторым показателям опережает Linode. Однако оптимизация в ряде датацентров выше у Linode. В любом случае, это два достойных игрока, качество услуг которых всегда на высоте, если опираться на мой личный опыт. Обе ссылки реферальные. Регистрируя аккаунт вы поддержите этот сайт и получите 100 долларов на счёт у провайдера, которые сможете потратить на его услуги. Через два месяца остаток сгорает, но двух месяцев более чем достаточно для оценки качества сервиса. Для моста вполне достаточно конфигурации с одним гигабайтом памяти и одним ядром. Это минимальная конфигурация, доступная у обоих провайдеров за пять долларов в месяц. Обратите внимание, что регистрировать аккаунт лучше без использования каких-либо средств анонимизации (VPN, Proxy и т. п.). Вас обязательно попросят подтвердить личность, что может затянуться надолго, так как потребуется предоставить официальный документ на английском языке, подтверждающий личность (водительское удостоверение, паспорт и так далее). Если не использовать средства анонимизации и IP адрес совпадает со страной, к которой привязано выше платёжное средство, то обычно всё сводится к подтверждению электронной почты.Из контрольной панели провайдера создайте виртуальный сервер. У Digital Ocean это «Droplets», у Linode «Linodes». При создании выберите ближайший к вам датацентр. Чем ближе к вам мост, тем быстрее будет отклик при его использовании. Не знаю, «особенность» ли это настроек, или «недоработка», но по умолчанию Tor Browser подбирает ближайшие к вам узлы без учёта прокси-серверов и мостов. «Ближайшими» считаются те, которые ближе к реальному местоположению точки входа. Не моста, а самого браузера. Если вы в Москве, а ваш мост а Калифорнии, то следующим узлом при построении цепи скорее всего будет Киев и так далее по цепи. Из-за такого «зигзага» пинг будет таким, что более старшее поколение вспомнит о 64К модемах. В качестве операционной системы выберите, то что вам ближе. У Linode более широкий выбор. Доступны даже Arch Linux и Gentoo. У Digital Ocean доступна FreeBSD. Если вам без разницы, то выберите Debian, так как в нижеприведённом примере используется именно она. Хорошей идеей будет использование SSH ключа, вместо пароля для доступа к серверу. После получения доступа нужно будет вручную запретить доступ по паролю в настройках SSH сервера. У обоих провайдеров создание виртуального сервера займёт не более минуты, после чего вы получите данные для доступа по SSH. После подключения по SSH создайте пользователя и дайте ему sudo права. В Debian это следующие команды:adduser username
/sbin/usermod -aG sudo userrnameВ Arch Linuxuseradd username
usermod -aG wheel userrnameГде «username» имя пользователя, а «sudo» или «wheel» – группа, в зависимости от дистрибутива. Переключитесь на вашего пользователя и обновите систему, если есть что обновлять. sudo apt update
sudo apt uprgadeДля Debiansudo pacman -SyyuДля Arch Linux. И так далее, в зависимости от вашего дистрибутива. В качестве фаервола меня устраивает UFW, работающий поверх Iptables. У вас могут быть свои предпочтения. У Digital Ocean бесплатно доступен внешний фаервол, который вы можете настроить через панель управления. У Linode эта возможность является «новинкой» и доступна не во всех датацентрах. Перекройте весь входящий трафик, кроме 22-го порта, дабы не заблокировать доступ себе. Выделенный IP на стороне вашего провайдера поможет закрыть 22-й порт для всех, кроме себя. Если вы всё же заблокировали себя, то на стороне Digital Ocean ничего страшного, если используется внешний фаервол. У Linode есть Lish Console в панели управления, позволяющая обойти фаервол. Подключаем репозитории TOR.sudo apt install apt-transport-httpsС помощью любимого текстового редактора создайте файл «tor.list» в /etc/apt/sources.list.d/ следующего содержания: deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] https://deb.torproject.org/torproject.org DISTRIBUTION main
deb-src [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] https://deb.torproject.org/torproject.org DISTRIBUTION mainГде строки «[signed-by=/usr/share/keyrings/tor-archive-keyring.gpg]» актуальны для 11-й версии Debian и (скорее всего) более поздних, а «DISTRIBUTION» – кодовое имя вашей версии дистрибутива. Для Debian 11 это «bullseye». Добавьте «arch=amd64» в строку, чтобы некоторые «apt-дистрибутивы» не ругались по поводу 32-х битной архитектуры. То есть строка будет выглядеть следующим образом в случае с Debian 11:deb [arch=amd64 signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] https://deb.torproject.org/torproject.org bullseye mainЧто указывает на то, что у нас архитектура x86-64 и на наличие или отсутствие в репозитории прочих нам начхать. Подключите ключ (из под root)wget -O- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg –dearmor | tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/nullДля более ранних версий можно использовать следующее:sudo apt-key adv –fetch-keys ‘https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc’Сработает и в Bullseye, но система ругнётся, так как способ считается «устаревшим» и более не каноническим. Обновляем список репозиториев и устанавливаем TOR.sudo apt update
sudo apt install tor deb.torproject.org-keyring nyx obfs4proxyГде «obfs4proxy» – прокси для TOR, к которому мы вернёмся чуть позже, а «nyx» – утилита для мониторинга узла (опционально). Для других дистрибутивов обратитесь к следующей странице на сайте проекта. Возможно для доступа к ней понадобится «средство обхода», поэтому я и рекомендую использовать тот же дистрибутив, что в этом примере. Если сайт проекта заблокирован и нет средств обойти блокировку, то придётся погуглить для поиска настроек репозиториев. Для CentOS и Red Hat /etc/yum.repos.d/Tor.repo должен выглядеть так:[tor]
name=Tor for Enterprise Linux $releasever – $basearch
baseurl=https://rpm.torproject.org/centos/$releasever/$basearch
enabled=1
gpgcheck=1
gpgkey=https://rpm.torproject.org/centos/public_gpg.key
cost=100Для Fedora:[tor]
name=Tor for Fedora $releasever – $basearch
baseurl=https://rpm.torproject.org/fedora/$releasever/$basearch
enabled=1
gpgcheck=1
gpgkey=https://rpm.torproject.org/fedora/public_gpg.key
cost=100Для Arch Linux TOR есть в официальных репозиториях. У OpenSuse, похоже, тоже. Для Arch Linux «obfs4proxy» есть в AUR. В случае с OpenSuse скорее всего придётся собирать из исходников. Так или иначе, после установки «tor» и «obfs4proxy» приступаем к настройке. Правим файл «torrc». В Debian он в /etc/tor/. В других дистрибутивах должен быть там же.BridgeRelay 1
PublishServerDescriptor 0
SocksPort 9050
SocksPort IP:PORT
#SocksPolicy accept 192.168.1.0/24
#SocksPolicy reject *
Log notice syslog
Log debug stderr
RunAsDaemon 1
DataDirectory /var/lib/tor
ControlPort 9051
HashedControlPassword 16:872860B76453A77D60CA2BB8C1A7042072093276A3D701AD684053EC4C
ORPort [IPv6]:PORT
ORPort IP:PORT
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 [::]:PORT
ServerTransportListenAddr obfs4 0.0.0.0:PORT
ExtORPort auto
#Address ip_or_domain
Nickname MyTORNetwork
RelayBandwidthRate 5000 KB
RelayBandwidthBurst 10000 KB
AccountingMax 400 GB
AccountingStart month 1 00:00
ContactInfo OWNER user@example.com
ExitPolicy reject *:* У Linode и Digital Ocean (по крайней мере в датацентрах юрисдикции Штатов) нет запрета на установку узлов TOR, но оба заставят вас его удалить после первого же инцидента. Поэтому не стоит даже пытаться разместить у них выходной узел. Но речь в этом материале о приватном мосте. BridgeRelay 1PublishServerDescriptor 0Первая строчка конфигурации указывает на то, что наш узел — это мост. Вторая на то, что данные о нём нигде не должны публиковаться. По умолчанию проект TOR публикует адреса всех промежуточных и выходных узлов в публичном доступе. Адреса мостов так же собираются и предоставляются пользователю по запросу, когда в браузере вы запрашиваете адреса мостов. То есть вторая строка конфигурации указывает на то, что вы сами даёте эти данные (друзьям и т. д.), но автоматически TOR Browser никому их не предлагает (не факт, что при этом не собирает). То есть в этом и есть «скрытность». Если обычные мосты можно положить путём перебора адресов используя тот же браузер, или сам сайт проекта, то приватный мост будет скрыт, пока вы сами его не засветите в публичном месте. SocksPort 9050 SocksPort IP:PORTПервая строка указывает на локальный порт. Он используется для локальных SOCKS соединений в пределах localhost. Вторая используется для внешних. Порты должны быть разными и второй открыт на стороне фаервола для внешних соединений, если вы планируете подключаться к своему узлу через обычный браузер или что-либо ещё, помимо TOR браузера. IP — внешний IP-адрес вашего сервера.#SocksPolicy accept 192.168.1.0/24#SocksPolicy reject *В данном примере строки закомментированы. Первая — политика принятия внешних соединений. То есть, если сам узел в локальной сети (что не проблема в странах, в которых TOR не блокируется или блокируется косоруко), то 192.168.1.0/24 указывал бы на то, что реле будет принимать все запросы на SOCKS порт из вашей локальной сети в диапазоне адресов с 192.168.1.1 до 192.168.1.255. Вторая строка указывает на то, что все остальные запросы отклоняются. В моём случае закомментировано, так как SOCKS порт всё равно заблокирован фаерволом за пределами локальной сети. Раскомментируйте обе строки и укажите своё значение. Если у вас выделенный IP-адрес, то укажите его. Если разрешить всем соединение на этом порте, то ваш узел захлебнётся и точно не будет «скрытым». По хорошему, порт должен быть заблокирован и единственным способом соединения должен оставаться TOR браузер на узлах подобного типа. Имейте ввиду, что у обоих рекомендованных провайдеров трафик ограничен. На минимальном тарифе — терабайт в большую сторону. Если вы напутаете в конфигурации и порт станет публичным, то терабайт уйдёт за пару дней при хорошем раскладе.Log notice syslogLog debug stderrЭти строки отвечают за логирование. В моём случае это системные логи. Если хотите отдельные логи, то строки должны выглядеть следующим образом: Log notice file /var/log/tor/notices.logLog debug file /var/log/tor/debug.logRunAsDaemon 1 указывает на то, что узел работает в качестве системного демона в фоновом режиме.DataDirectory /var/lib/tor указывает на рабочую директорию узла. Там будут храниться ключи и прочее.ControlPort 9051 — локальный порт, к которому будет подключаться утилита мониторинга (nyx), установленная ранее. HashedControlPassword — хэшированный пароль для доступа к утилите мониторинга. Вы можете сгенерировать его командой «tor –hash-password pass», где «pass» – пароль. Придумайте свой. Можно использовать куки, заменив строку «HashedControlPassword» на «CookieAuthentication 1», но для доступа к мониторингу понадобится root, что излишне. ORPort [IPv6]:PORTORPort IP:PORTПервая строка относится к IPv6, вторая к IPv4. Это внешний IP вашего сервера. Порт должен быть доступен извне на стороне фаервола. Через этот порт ваш узел TOR будет связываться с другими. ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxyServerTransportListenAddr obfs4 [::]:PORTServerTransportListenAddr obfs4 0.0.0.0:PORTExtORPort autoПервая строка указывает на бинарник obfs4proxy. Вторая и третья на порт, который будет слушаться на предмет внешних SOCKS запросов. IPv6 и IPv4 соответственно. Не путать с SocksPort. В данной конфигурации TOR браузер будет соединяться именно с obfs4proxy, который в свою очередь «прячет» TOR трафик, маскируя его под обычный. То есть, при желании и технической возможности ваш провайдер увидит SOCKS прокси (хотя бы тому, что порт не связан со стандартными портами того или иного популярного ПО), но ничего не говорит ему о том, что это TOR. Если между клиентом и SocksPort идёт «чистый» трафик со всеми признаками TOR, то здесь всё выглядит как стандартная активность. Порт должен быть открыт для внешних соединений и не совпадать с ORPort. Четвёртая строка отвечает за локальное взаимодействие TOR и obfs4proxy. Всегда «auto». Не пытайтесь указать своё значение.Address ip_or_domain, где «ip_or_domain» указывает на IP вашего сервера, или его доменное имя. Строка не имеет значения в данной конфигурации. Если убрать из публичной конфигурации, TOR подберёт значение. Отображается в публичных списках известных узлов. Nickname — имя вашего узла. Используется в паре с «Address». Будет отображаться в логах TOR браузера. RelayBandwidthRate 5000 KBRelayBandwidthBurst 10000 KBAccountingMax 400 GBAccountingStart month 1 00:00Первая строка указывает на ширину канала, который доступен для узла. Вторая указывает на максимально возможную ширину на пиках. Это не ширина вашего реального канала, это разрешённая скорость для TOR в килобайтах. Третья строка указывает на максимальный объём трафика за учётный период. Четвёртая строка указывает, что учётный период начинается в 12 ночи, первого числа каждого месяца. Стоит учесть, что «AccountingMax» указывает на трафик в каждую из сторон, а не на общий объём. То есть в данной конфигурации возможно 800 GB ежемесячно, со скоростью 39 мегабит в секунду, при скачках в 2 раза больше. Учитывая, что это скрытый мост, то значения вполне приемлемые. На публичном узле при таких скоростях весь лимит был бы выработан меньше чем за сутки. ContactInfo — ваше имя или никнейм и адрес электронной почты. Используется для связи по техническим вопросам. Публикуется в открытом доступе в случае публичных узлов. ExitPolicy reject *:* указывает на то, что узел не является точкой выхода. Мост не может быть точкой выхода, иначе теряется весь смысл. Проверяем всё ещё раз и сохраняем изменения. Далее правим файл «torsocks.conf» в той же директории, что и «torrc». TorAddress 127.0.0.1
TorPort PORT
OnionAddrRange 127.42.42.0/24Первая строка — адрес узла. В нашем случае локальный, так как всё на одном сервере. Технически может быть и на разных. TorPort — тоже, что и локальный SocksPort в «torrc». Прокси будет обращаться к нему для выхода в TOR. OnionAddrRange относится к «скрытым сервисам». В нашем случае бесполезная строка, так как у нас нет подобных сервисов. Технически, это незадействованный диапазон локальных адресов для, например, .onion сайтов на вашем сервере. Сохраняем. Перезагружаем TOR.sudo systemctl restart tor@defaultДля автозапуска при старте системы используйте следующее:sudo systemctl enable tor@defaultК сожалению в Debian я не могу победить глюк, который не даёт узлу запуститься автоматически. Видимо это глобально затрагивает большинство машин на Debian. Возможно и на Ubuntu тоже. То есть, после перезагрузки сервера придётся использовать «sudo systemctl start tor@default» для запуска TOR. Проблема, возможно, связана с ранним выполнением скрипта, до поднятия сетевых интерфейсов. Далее нам нужно получить данные для TOR браузера. Пример хранится в /var/lib/tor/pt_state/obfs4_bridgeline.txt. Откройте файл и там будет строка подобного типа:Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=67X/L181CbNew1FyZ7gw/YJLJYT6fuB/tm8VtOlJ/r1gxNFq1NY5lJ+TlHOH2AuO+6myTg iat-mode=0Где «cert» – сертификат для идентификации. IP и Port — это данные из настроек «torrc», указанные для «ServerTransportListenAddr». Соответственно, если на стороне браузера нет поддержки IPv6, то используйте IPv4. FINGERPRINT можно получить следующей командой: sudo cat /var/lib/tor/fingerprintТо есть, скопируйте строку из /var/lib/tor/pt_state/obfs4_bridgeline.txt, замените IP:Port и FINGERPRINT на свои значения и вставьте её в соответствующее поле в настройках TOR браузера. Соединение будет поднято.Таким образом мы настроили приватный мост TOR и с помощью obfs4proxy подключили к нему TOR браузер. Используйте команду «nyx» на запуска утилиты мониторинга.

Go to Source
Author:

VirtualBox VM на физическом диске

Физический накопитель (HDD, SSD и так далее) значительно увеличивает производительность виртуальной машины. Это полезная опция, если VM нужна для дела. Несмотря на отсутствие признаков этой опции в графическом интерфейсе, VirtualBox всё же умеет работать с физическими накопителями. VirtualBox VM — кроссплатформенный продукт. ОС хоста может иметь свои нюансы при работе с VirtualBox, но общие принципы практически идентичны. Данный материал основан на работе с Linux, но я так же приведу примеры для Windows и MAC. Нам понадобится свободный диск, который хостом воспринимается как физический накопитель. Это может быть флэшка USB 3 (при более медленных решениях теряется смысл), не слишком медленный HDD, или полноценный SSD. Теоретически, ничто не мешает использовать свободный раздел, а не весь диск. Но во избежании лишних проблем не стоит пытаться использовать раздел, используемый хостом. Даже если он пустой, но при этом монтируется при старте ОС хоста. В моём случае это старый SSD на SATA, хост под Arch Linux и Windows 10 на стороне VM. Далее нужно создать VM штатным способом чрез графический интерфейс, но следует пропустить шаг создания виртуального диска. После настройки VM следует определиться с разметкой диска. Я использую EFI, так что это будет GPT. Любой удобной программой разметьте диск, или оставьте эту задачу гостевой ОС. Практически любая современная ОС сделает это при установке. Уточните расположение и номер диска. В Linux это можно сделать командой «sudo fdisk -l». Пример выдачи:Disk /dev/sdb: 111.79 GiB, 120034123776 bytes, 234441648 sectors
Disk model: SPCC Solid State
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 09A1074D-98C3-BC43-88B9-BAF6DB909A54Это часть выдачи, которая относится к диску, который я хочу использовать. Путь до sdb будет «/dev/sdb». В MAC следует использовать команду «diskutil list». Пути до дисков выглядят как «/dev/disk0», «/dev/disk1»… В Windows штатная программа называется «Disk Management». Диски обозначаются «PhysicalDrive0», «PhysicalDrive1» и так далее. Далее откройте терминал (или Power Shell в Windows). Если на хосте используется Windows, то нужно перейти в корень VirtualBox. Обычно это в «Program Files». Пример:cd “C:Program FilesOracleVirtualBox”В Linux следует учесть права на управление дисками. Запускать VirtualBox с правами root – плохая идея. Будем исходить из того, что пользователь и VirtualBox находятся в одной группе. Для управления дисками обычно требуется root-доступ. Проверяем пользователя и группу. В моём примере:ls -l /dev/sdbВыдача:brw-rw—- 1 root disk 8, 16 Nov 14 07:00 /dev/sdbГде root — пользователь, disk — группа. Добавляем себя в группу «disk».sudo usermod -a -G disk usernameГде «username» – имя пользователя, под которым вы работаете. Таким образом мы исключаем необходимость запуска VirtualBox с правами root для доступа к физическим дискам. На случай, если для запуска самой VirtualBox всё же требуется root-доступ, убедитесь, что добавили себя в группу «vboxusers», в которой обычно работает VirtualBox. Для принятия изменений следует перезапустить сессию. И так, в консоли создаём «диск» для нашей VM:VBoxManage internalcommands createrawvmdk -filename “/путь_до_файла/диск.vmdk” -rawdisk /dev/sdbГде путь — произвольное значение. Для удобства диск можно создать там же, где и другие файла нашей новой VM; «sdb» – диск. Используйте своё значение. Использовать кириллицу в путях – тоже не очень светлая идея. Используется в примере только для наглядности. Если хост под Windows:VBoxManage internalcommands createrawvmdk -filename “C:UsersUserNameпуть_до_файладиск.vmdk.vmdk” -rawdisk .PhysicalDrive#Где # – номер диска. Если хост под MAC:VBoxManage internalcommands createrawvmdk -filename “/путь_до_файла/диск.vmdk” -rawdisk /dev/disk#Про кириллицу и номер диска всё то же самое, что и выше.Таким образом мы создали виртуальный диск, по сути являющийся ссылкой на физический диск. Далее через графический интерфейс зайдите в настройки своей VM и добавьте к ней диск, указав в качестве диска только что созданный «raw-диск». Таким образом наша VM будет использовать физический диск, что значительно повысит производительность.

Go to Source
Author:

Wine Crossroads

Сборки Wine, объединяющие все предыдущие сборки, опубликованные на этом сайте.Не смотря на название сборок, они не содержат ничего эксклюзивного, так как я не программист. К сожалению свободного времени тоже не так много как хотелось бы, так что я не могу больше компилировать сборки “на все случаи жизни” и уже давно не успеваю делать это регулярно. Предоставленные здесь сборки по прежнему опираются на разумную комбинацию патчей TK-Glitch, Proton и других разработчиков. Немного о нумерации версий: Первые 2 цифры указывают на текущую версию Wine, используемую при сборке. Третья цифра указывает на мою собственную реверсию, буква в конце указывает на акцент сборки. M – версия, основанная на ванильной версии Wine, S – версия с набором патчсетов Staging, P – версия, собранная из исходников, предоставленных Valve. То есть P – это практически Proton, но собран в виде обычной сборки Wine и не будет работать с нативным клиентом Steam (ровно как и со Steam.exe). Практически тоже самое вы можете получить при распаковке Протона, полученного через Steam. Но сборка неплохо работает с играми других платформ, таких как GOG и так далее. Пример: версия 6.10.5-m – это пропатченная ванильная (mainline) 6.10 версия Wine, где 5 – моя реверсия, означающая, что 6.10.3-m была более глюкавая, а 6.10.6-m будет ещё лучше, если в 6.10.5-m что-то не работает по моей вине. Все версии (включая M) содержат патчи Fsync + Fsync-Futex2, а также Esync, на случае если Fsync не поддерживается ядром. Напомню, что для работы Fsync по прежнему нужно пропатченное ядро. Все версии ориентированы на работу в связке с DXVK, поэтому готовые сборки скомпилированы без поддержки VKD3D. Если вам нужна сборка с поддержкой VKD3D, то её можно скомпилировать из исходников, или воспользоваться готовыми сборками из других источников. Во всех готовых сборках вырезан функционал построения меню (мусор в меню нативных программ) и перестроения ассоциации файлов (нативные txt файлы больше не будут ассоциироваться с notepad.exe). При сборке готовых бинарников используется Arch Linux и Debian 10. В бинарниках, собранных в Arch (на сегодня) поддерживается более широкий спектр 32-х битных библиотек. То есть чистые 32-х битные префиксы работают лучше. Это не имеет значения при создании гибридных префиксов. Сборки, скомпилированные в Arch будут работать только в его производных из-за новейшей версии GlibC. Я стараюсь отдавать приоритет бинарникам, собранным в Debian 10 (версия glibc 2.28) для более широкой поддержки дистрибутивов. Но и эти сборки не будут работать в дистрибутивах, где версия glibc старше. В таком случае следует скомпилировать бинарники из исходников.О крупных изменениях в сборках я буду сообщать ниже.

Go to Source
Author:

Менеджеры пакетов в Linux

Установка ПО (или пакетов) в дистрибутивах 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. Первое, что нужно знать любому, кто заинтересовался этой темой: 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