Есть тут те, кто были линуксоидами в 2000-е и остаются ими по сей день? Как тогда дела обстояли с нашей ОС? Надежда на вендекапец была больше чем сейчас или меньше? Я не имею в виду реальные шансы, но вроде бы, когда Ubuntu вышла, с ней связывали большие ожидания. Стереотипов о том что Линукс - это «сложна» было больше или меньше? И когда по-вашему было больше софтверной свободы, в нулевые или сейчас? Вроде бы сейчас стало больше веба, больше кроссплатформенности, но с другой стороны всякие secure boot'ы сделали.

А может тут есть даже те, кто линуксоидили в 90-е? Эти сенсеи тоже приглашаются.

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

Собственно сабж. Третий андрофон. В первый раз ставил из него судоку. Во второй: блокнот. В этот раз: «Транзистор» для прослушивания радио.

А кто чем ещё пользуется?

Ищу сабж. Когда-то пользовался ikiwiki, но надоела вся эта перловка, да и кривой он какой-то.

Сборник основных решений треда.

Привет

Достаточно часто создаются темы, где люди думают переходить на Gentoo и хотят уточнить некоторые моменты. Чтобы сэкономить время себе и другим, решил создать этот топик, в котором буду собирать ответы на частые вопросы.

TL; DR: Для тех, кто думает перейти на Gentoo (комментарий)

Преимущества
#1 Gentoo очень гибкая и всенастраиваема
Пример того что в Gentoo делается просто:
- Использовать openrc вместо systemd или наоборот; pulseaudio или без него
- Наложить кастомный патч; пример когда это нужно
- Подключить или отключить такие вещи как vaapi, vdpau, opencv и т. п.
- Иметь несколько веток софта; уточню, что это работает только для определённых пакетов; например можно одновременно установить python 2.7, 3.4, 3.5 или qt4 и qt5, но нельзя одновременно установить qt 5.7 и 5.8

#2 Очень удобный и функциональный пакетный менеджер
Примеры удобных фич:
- Прервать установку (вплоть до перегрузки компьютера), а потом ее продолжить. Можно продолжить с последнего пакета (emerge --resume), продолжить но пропустить последний пакет, например, если его установка прервалась с ошибкой (emerge --resume --skipfirst, некоторые нюансы); для больших пакетов можно продолжить саму компиляцию (ebuild <полный путь и имя файла>.ebuild merge).
- Когда при установке обновляется конфиг приложения, определяется редактировался ли предыдущий конфиг пользователем. Если да, конфиг не перезаписывается, а кладётся радом, и выводится сообщение пользователю с предложением обновить конфиг.
- Обновить всю систему, но исключить некоторые пакеты (удобно для исключения больших пакетов из ежедневного обновления)
- Почистить зависимости - удалить те пакеты, которые больше никому не нужны.
- Поскольку ebuild - текстовый файл, то можно пропарсить на предмет требований к количеству ресурсов для установки:

$ for F in $(find /usr/portage -name "*.ebuild") ; do REQ=$(grep "CHECKREQS" "$F") ; if [[ -n "$REQ" ]]; then echo -e "\n$F\n$REQ" ; fi; done

#3 Хорошая документация, по крайней мере на английском. Более того, поскольку Gentoo-специфичные утилиты являются лишь надстройкой на generic механизмами, документация от других дистрибутивов (например от Arch) в большинстве случаев тоже подходит.
Опрос 2014: У какого дистрибутива лучшая документация

#4 Достаточно свежий софт, много сторонних репозиториев.
Список сторонних репозиториев
Gentoo - rolling release, а значит как только новая версия конкретного софта появилась в репозитории, её можно установить. Но здесь не имеется ввиду, что как только новая версия зарелизилась, она моментально становится доступна в основном дереве; лаг есть, но он как правило не большой, хотя зависит от пакета. В тестинг ветке новые версии появляются раньше. Кроме того мейнтейнеры Gentoo могут маскировать некоторые версии, если в них обнаруживаются серьезные баги. Однако всегда можно размаскировать нужную версию. Кроме того для некоторых пакетов есть -live версии, когда исходники скачиваются напрямую из github или аналога.
Пример когда «у меня не самый свежий софт в Gentoo»

#5 Полный порядок в системе, ничего лишнего - эстетическое удовольствие, плюс возможно можно немного улучшить перформанс

#6 В процессе установки и эксплуатации получаешь полное понимание как работает система, а значит возникающие проблемы решаются быстро. На самом деле без должного знания Линукса (или желания его узнать в процессе) Gentoo нормально не установить.

Недостатки
#1 Сложная и долгая первичная установка. Если устанавливать в первый раз, нужно готовиться потратить несколько дней. Для опытных - несколько часов + компиляция.
Время установки (компиляции) Gentoo, еще немного цифр по большим пакетам

#2 Пакетный менеджер хоть и удобный, но очень медленный

#3 Если не обновлять систему долго (полгода и более), то сложность обновления сопоставима с установкой новой системы. Есть мнение, что emerge-webrsync --revert=yyyymmdd должен помочь (лично я не проверял).

Особенности
#1 Высокий порог входа; дистрибутив не для новичков. Если человек не комфортно чувствует себя в командной строке, никогда не компилировал ядро, не разбивал диски на разделы, не привык изучать докуменацию, вчитываться в сообщения и анализировать логи, то Gentoo покажется сложной в обслуживании, а возникающие проблемы будут списываться на дистрибутив.

#2 Обновляться нужно часто.

#3 Основные фичи - в командной строке. Для тех, кто не привык работать в командной строке, это будет минусом. А для тех, кто комфортно чувствует себя в командной строке, это будет плюсом, так как работа в командной строке более эффективна, а типовые сценарии можно обернуть в скрипты и еще больше сократить время на обслуживание системы.

#4 Есть две ветки: stable и testing. В stable меньше шансов встретить проблему, но в testing более свежий софт. Ветки можно комбинировать.

Мифы
Миф #1 Gentoo даст прирост производительности за счет того, что весь софт компилируется под конкретное железо.
Краткий ответ: В 99% случаев при смене дистрибутива X на Gentoo вы не заметите какого-либо улучшения в плане скорости работы. Если вы зададитесь целью сравнить свежеустановленный дистрибутив X с свежеустановленной Gentoo, то в 90% вы не увидите значительной разницы.

Детальный ответ.
Не следует ожидать что просто скомпилировав систему из исходников вы получите сколько-нибудь заметное улучшение перформанса.
Для большинства приложений компиляции под конкретное железо даст прирост производительности в районе 1-2%.
Ложка дегтя: в некоторых случаях даже может быть замедление. Например Firefox, можно ускорить с помощью PGO. В Gentoo по умолчанию это отключено, так как PGO увеличивает время компиляции почти в два раза. В бинарных дистрибутивах соотв. софт может быть скомпилирован с PGO.
Так как добиться улучшения производительности? Узкий круг приложений может быть значительно ускорен при компиляции под конкретную платформу - на 30%-50% и больше. В основном это приложения которые активно занимаются вычислениями. Но для этого требуется соотв. настройки. Например, активация SIMD инструкций, даст прирост производительности в мультимедиа приложениях. Некоторые процессоры имеют аппаратную поддержку шифрования AES. В бинарных дистрибутивах подобные фичи будут отключены, так как не все процессоры это поддерживают, а бинарные дистрибутивы в первую очередь заботятся о совместимости.
Небольшое улучшения перформанса возможно если убрать из системы всё лишнее (мнение 1, мнение 2).
Еще интересный случай

Миф #2 Обновления занимают много времени
Краткий ответ: 5-10 минут на фоне, не мешая основной работе.

Детальный ответ.
Обновления не занимают много времени, но опять же, при правильном подходе.
Во-первых, как было сказано выше, обновляться нужно часто. Для testing ветки это каждый день, или по крайней мере не реже чем в раз 2-3 недели. Для стабильной ветки - раз в неделю достаточно (на стабильной ветке намного реже выпускаются обновления)
Во-вторых, есть пакеты которые правда очень долго компилятся: libreoffice, firefox, chromium... Их всего 10-15. Я их исключаю из ежедневного обновления, а обновляю раз в несколько месяцев.
Еще нужно сказать, что на этом вопросе часто заостряют неоправданно много внимания. Обычно обновления происходят на фоне, и не сильно влияют на работу; так какая разница как долго они выполняются?
В итоге, у меня обновления занимают примерно 5-10 мин ежедневно (у меня тестинг-ветка).
К тому же всё происходит на фоне, в любой момент можно поставить на паузу (Ctrl+Z, fg), продолжить после прерывания (умышленного или случайного).
Мой скрипт ежедневного обновления

Миф #3 Gentoo требует много времени на обслуживание
Краткий ответ: Может быть больше, может быть меньше по сравнению с другими дистрибутивами. Очень зависит от того, насколько вы будете вчитываться в то, что пишет вам пакетный менеджер, и разбираться первопричинах.

Детальный ответ.
Обслуживание Gentoo занимает меньше времени по сравнению с другими дистрибутивами, но только при грамотном обращении, конечно. Достигается это за счет следующего:
- хороший пакетный менеджер: маскировки, глобальные и индивидуальные установки для пакетов (USE флаги, опции компиляции, каталоги), хуки, приоритеты (чтобы компиляция происходила на фоне и можно было работать), много опций для установки и анализа, подсказки после установки.
- всё происходит в CLI, а значит типовые операции можно обернуть в скрипты/алиасы.
- уже существуют много утилит для облегчения обслуживания: eselect, equery, eix, eclean, euse, genlop и др.
Грамотное обращение означает, что вы правильно и регулярно обновляете систему, исполняете предписания emerge, которые он выдает после установки, держите в порядке конфигурационные файлы, а если таки возникает проблема, которую решить вы не можете, то вы обращаетесь в форумы, а не просто жалуетесь на жизнь.
Что до проблем с обновлениями - см. следующий пункт «Миф #4 Установка, обновление постоянно падают; частые блокировки»

Миф #4 Установка, обновление постоянно падают; частые блокировки
Краткий ответ: Не чаще чем в других дистрибутивах

Детальный ответ.
Если говорить про «часто» и «постоянно», то проблемы с обновлением/установкой могут быть если:
- система давно не обновлялась
- система неправильно обслуживается (см. выше про Грамотное обращение)

В редких случаях пакет просто не компилируется. На самом деле это проблема не Gentoo, а тех, кто писал этот софт. И в подавляющим большинстве случаев это не является проблемой, и вот почему. Если это обновление, то можно продолжить процесс запустив emerge с параметрами --resume --skipfirst - он обойдет проблемный пакет, пересчитает зависимости чтобы система осталась консистентной, и продолжит обновление (а можно изначально передать параметр --keep-going, тогда это будет происходить автоматически, прерываний вообще не будет). Если пакет критичен, можно установить предыдущую версию, которая компилировалась (а проблемную замаскировать чтобы пакетный менеджер ее не видел).

Что может заблокировать обновление полностью:
- просьба пакетного менеджера поменять флаги пакета. При этом emerge предлагает сделать это автоматически, но лично я предпочитаю делать вручную. Для ручного способа, решается добавлением строчки в package.use
- просьба пакетного менеджера задать лицензию. Это валидно только для не-свободных лицензий, например EULA, Skype, Adobe Flash и т. п. Если мы говорим имено про обновление, то такое бывает только когда лицензия обновляется, что бывает очень редко (как много у вас пакетов под не-свободной лицензией, и как часто они меняют лицензию?). Решается добавлением одного слова в make.conf
- просьба пакетного менеджера размаскировать пакет. По моему опыту нужно не размаскировывать, а наоборот замаскировывать пакеты, которые тянут замаскированные зависимости. Это, да, требует минут 5-10 на разобраться. Но, если только у вас нет смешения веток и live пакетов, такой вариант случается раз в пятилетку.
- сложные блокировки. Большинство блокировок пакетный менеджер разрешает сам; по моим наблюдениям, качество данного механизма значительно улучшилось пару лет назад. Из своего опыты скажу, что (учитывая частые обновления) блокировок, которые бы совсем останавливали обновление я уже не видел года 1.5. Но если они есть, то это действительно сложный кейс.

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

Миф #5 В Gentoo нет бинарных пакетов
Краткий ответ: Есть там, где это действительно нужно.

Детальный ответ
Во-первых есть Calculate Linux - полностью бинарный форк Gentoo.
Во-вторых даже в самом Gentoo в основном репозитории есть несколько бинарных пакетов: libreoffice-bin, firefox-bin, некоторые другие. Связано это с тем, что из исходников они очень долго компилируются, и иногда проще поставить бинарник.
Бинарный пакет можно сделать самому командой quickpkg --include-config y <установленный пакет> - удобно для бекапов.

FAQ

#1 Установка на слабый компьютер
Смотря что есть слабый компьютер.
Из собственного опыта: Intel Core2 Duo 6600 @ 2.40GHz, 2Gb RAM + 4Gb swap хватало для комфортной работы в Gentoo.
Зачастую ebuld'ы содержат информацию о том, сколько нужно памяти для компиляции пакета. TOP 5:
16G - chromium
8G - ledger, isabelle
7G - ceph
6G - firefox x64 (для x32 нужно 3G), pypy x64 (для x32 нужно 3G)
5G - electron
Если компьютер и вправду слабый, то лучше выбрать не Gentoo (точнее не-source-based дистрибутив). Альтернатива - можно вынести компиляцию на другой «не-слабый» компьютер с помощью distcc.

Опрос 2021: Какую операционную систему и/или дистрибутив GNU/Linux вы используете на ПК?
Опрос 2018: Какой ОС вы пользуетесь на основном ПК?
Опрос 2017: Какую ОС вы используете на основном ПК?
Опрос 2014: Какой дистрибутив вы используете на десктопе?
W3Tech стастика дистрибутивов на серверах
Отличия дистрибутивов, время работы ноутбука
Чем удобны USE флаги
Сколько памяти нужно для РАБОТЫ Gentoo (сколько нужно для компиляции было указано выше)
Сколько места на диске нужно для Gentoo
Правильное полное обновление Gentoo, Мой скрипт ежедневного обновления, Еще вариант
Gentoo для девелоперов
Практика инсталляции Gentoo: в двух словах простым языком
Небольшой скрипт - сборка livecd

Дело было вечером, делать было нечего. Решил запилить карманный гитхаб, для случаев экстремального кодинга на соревнованиях или иных случаях. Реализация - мобилка - HD 7 Pro на android 2.3.5 и debian armel chroot, в котором работают lighttpd, php, mysql, openssh. dnsmasq'у андройда подсунут конфиг для поддержки локального dns на хотспоте. Дизайн набросал из готового темплейта от freecsstemplates, заполняю ajax'ом данными из мелких скриптов. Из веб интерфейса можно создать новый bare репозиторий, отклонить напрямую из интернетов на мобилку, добавить ssh ключи. push и pull по ссх. До кучи можно получать фотографии с front/back камеры нажатием на соответствующую кнопку (отображается через lightbox2). Из скриптов установлены sticky-notes, phpmyadmin, gitweb. На скриншоте видна веб морда, и снятая задней камерой фотография. Фотографии отдает по http самописный сервис на жабе, так как voodoo-люди из медиатека выпилили v4l/v4l2 и подцепили камеру через «нестандартное техническое решение». Для запуска/останова используется самописное приложение для дройда.

Детали реализации и еще пяток скриншотов

Код бесплатно, без смс и регистрации можно найти там же.

Общее впечатление - несмотря на то, что в телефон по современным меркам старый тормоз - 512 RAM (из которых 64 откусил 3д ускоритель, а половину оставшегося, если не больше, выжрал андройд), а частота CPU у него 650Mhz (1 ядро arm 1176), все крутится на удивление быстро. Даже phpmyadmin поставленный чисто поржать работает на удивление сносно. И только java (sic!) «не тормозит» (c) (tm).

>>> Просмотр (1920x1080, 436 Kb)

Требуется нарисовать решетку типа DO3 (Ni-Mn-Al) и более сложные.

Пакеты PSTricks и TiKz дают подобный функционал, однако в обоих пакетах новые элементы закрывают под собой старые вне зависимости от координат и проекции.

Адский полигон (a.k.a. домашний ынтырпрайз для извращенцев). Из чего «оно» состоит - 4 компьютера:

WORK.LOCAL (линукс на работе) с тремя сконнектнутыми сетями - корпоративной локалкой, приватной сетью для виртуальных машин и приватной сеткой «для личных нужд», в которую подключаются андроиды, ноутбуки и всякая прочая мобильная мелочевка (в третья сетку воткнута точка доступа). Система стоит за страшной коропоративной проксёй (на старой феоре со сквидом). А, виртуалки живут в libvirt/qemu-kvm. Вируталок там чуть-чуть - Win7, 2xWin2003, SL, Fedora-i386. Понятно что не все живут одновременно, но бывает и такое...

VPN.LOCAL (арендованая виртуалка) - её задача обслуживать мои личные нужды где бы я ни находился. Ну, например, она серез VPN соединяет все компьютеры (и ещё два компьютера на разных площадках одного заказчика, чисто чтобы можно было на них прямо делать http, ftp и ssh).

ASUS.HOME.LOCAL (мелкий домашний маршрутизатор) - он поддерживает связь с интернетом (на него заведен линк от провайдера). И ещё на нем подняты два VPN точка-точка, один с WORK.LOCAL, второй с VPN.LOCAL. Ну и ещё один VPN до второго заказчика. Ничего сложного в общем-то.

HOME.LOCAL (домашний компьютер) - вообще просто. Линукс с одним эзернетом воткнутый в LAN-порт маршрутизатора. Хотя, на самом деле не всё так просто - на нем ведь есть ещё внутренняя раутабельная сеть в которой живут виртуалбоксные виртуалки. Почему виртуалбокс? Потому что процессор E5200, и QEMU-KVM на нем не живет, скотина, а без KVM оно издевательски медленное.

BOOK.LOCAL (ноутбук, как наверное понятно) - просто ноутбук. Всё как обычно - линукс, федора, отдельная приватная виртуальная host-only сеть на которой висят виртуалки (опять же libvirt/qemu-kvm, благо процессор позволяет). Вирталок 4 штуки - Fedora-i386, SL-x86_64, SL-i386, Win2003. А, ещё на нем настроен VPN «по требованию», который через интернет цепляется к VPN.LOCAL (это если я через мобильник подключен или через публичный WiFi).

VPN-каналов пачка разной структуры: 3 точка-точка (WORK-ASUS, ASUS-VPN, WORK-VPN) + клиент-сервер на VPN.LOCAL (для нужд «ноутбук уехал далеко и хочет достучаться до дома»)

Ноутбук ездит то на работу, то домой (ну как получится), и соответственно до виртуалок в его host-only сети хрен достучишься. Ну или с них хрен выстучишься на другой конец сети. Поэтому, на WORK, BOOK, ASUS и HOME поднят OSPF - в результате эта четверка всегда друг с другом снюхиваются и сами строят маршруты так как правильней, то есть по наиболее краткому маршруту. Лень - источник прогресса. Три линукса работают DNS-серверами для зон {WORK|VPN|HOME|BOOK}.LOCAL, ну и ещё живет собственно зона LOCAL. Между серверами налажены отношения master-slave. В довершение ко всему, каждый из таких «боевых» линуксов имеет по специальному виртуальному интерфейсу на котором висят адреса с маской /32 (для однозначной идентификации хостов).

Все линуксы (кроме VPN.LOCAL) «оснащены» по типовому сценарию, включающему в себя серверы LDAP, KDC, KADMIN, Samba. Последние три (KDC, KADMIN, Samba) прикуривают от первого (от LDAP). Ну и сама самба также авторизуется через Keberos. Все три сервера LDAP в multi-master репликации «каждый с каждым». Репликация (естественно!) черз ldaps (порт 636). Для целей оного, развернуто жалкое подобие CA с собственным корневым сертификатом. Все виртуальные винды зарегистрированы в Kerberos-домене (дааа, линуксовые скрипты opendirectory и виндовый клиент работают!). Ну и еще SSSD на всех трех больших линуксах (каждый ходит в личный LDAP и личный Kerberos). Смену пароля каждый юзер делает просто командой passwd (которая через SSSD обращается к локальному KADMIN, и тот отправляет всё в LDAP, через который данные и реплицируются).

Ну а на скриншоте - smbclient на book.local (стоящий сейчас дома) обратившийся к work7.local (Win7 в виртуалке на работе), с аутентификацией через Kerberos. Ах да - тикет получен на book.local, и отлично подощел к WORK7 (который проверил его через WORK.LOCAL). На второй половинке- консольки управления LDAP-сервером, зацепленные на два разных сервера.

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

Ах да, из этого стройного ряда выпадает VPN.LOCAL - на нем есть LDAP, но он используется для обслуживания другого домена :-)

>>> Просмотр (1280x1600, 548 Kb)

Сначала я назвал эту тему «История появления 3D-ускорения в открытых драйверах видеокарт», но 95% текста посвящено закрытым драйверам. Для открытых драйверов нужно было проделать огромную работу и новости выходили редко, наверное поэтому я запомнил мало новостей. В итоге получился исторический текст о событиях, связанными с драйверами видеокарт для Linux и FreeBSD, который, я надеюсь, окажется кому-нибудь интересным. Принимаются исправления, текст можно копировать себе, перерабатывать. Я не стал писать те новости, которые меня не заинтересовали и которые я не запомнил, а также все даты открытия очередной части спецификаций чипсетов ATi/AMD, и дат добавления очередных версий OpenGL. Последнее в драйверах для Linux появляется сразу после появления новой версии OpenGL. Все эти события я узнал благодаря периодическим заходам на сайты linux.org.ru и opennet.ru с 2008 по 2012 год. Текст разбит на части, следующие части - в первых комментариях к теме.

Предыстория.

До 2008 года всё было просто (да и в мире железа тоже всё было просто, Intel/AMD, NVIDIA/ATi). Есть открытые драйверы видеокарт, которые имеют функцию 2D-ускорения, и позволяют выставлять большие разрешения экрана. Они поставляются вместе с дистрибутивом Linux. И есть закрытые драйверы видеокарт, драйверы от производителя, которые отличаются от открытых только наличием 3D-ускорения.

1). Открытый драйвер для видеокарт NVIDIA называется nv. Написан самой NVIDIA.

2). Открытый драйвер ati написан непонятно кем. Пожалуйста, скажите, кем он написан, помогала ли компания ATi написать его, и если нет, то почему он тогда называется открытый, а не свободный? Не застал Linux в то время.

1а). Официальный драйвер NVIDIA. Поддерживает ядра Linux версии 2.4 и 2.6 (а также FreeBSD и Solaris), XFree86 и Xorg. Поставляется в виде run-файла, который универсален для всех дистрибутивов Linux для архитектур процессора x86 и x86_64. Есть 3 ветки драйвера, 7x.xx, 9x.xx и текущая, 100.xx. Поддерживается только текущая (видеокарты GeForce 6-7), а для остальных иногда выпускаются обновления, добавляющие поддержку новых версий ядре Linux и X-серверов.

Очень мало ошибок. Скорость работы 2D и 3D та же, что и в Windows. Есть возможность разгона и регулирования скорости вращения кулера. Есть поддержка SLI. Единственный недостаток драйвера NVIDIA для Linux - не поддерживается 3-way SLI - в остальном полная идентичность Windows-версии (я пишу о том времени, когда GeForce 8 с рядом новых технологий ещё не вышел).

2а). Официальный драйвер ATi. Поддерживает Linux x86 и x86_64, не знаю насчёт 2.4 и XFree86. Один раз была прекращена поддержка старых серий видеокарт - драйвер версии 8.28.8 от 2006 года. Пользователям этих видеокарт оставалось пользоваться только 2D-ускорением, потому что в закрытый драйвер не добавлялась поддержка новых версий X-сервера и ядра Linux. А значит, ветки драйвера две: 8.28.8 и текущая.

Очень много ошибок. Они проявляются во всём: повседневная работа, проиггрывание видео, медленное 3D с искажениями (артефактами), отсутствие функций 2D и 3D-ускорений, полноэкранные приложения, переключение в виртуальный терминал, спящий режим, огромные задержки (рекорд - 5 месяцев) добавления в драйвер поддержки новых видеокарт, ядер Linux и X-сервера.

У меня создаётся впечатление, что создатели драйвера были программистами низкого класса, они писали раздутый код с большим количеством ошибок и неточностей, по принципам «лишь бы скомпилировалось» и «лишь бы заплатили». Хорошо что когда я попробовал Linux, у меня была NVIDIA - а если бы была ATi, остался бы я на нём? На форумах можно было увидеть такую аналитику, «в мире открытого ПО тысячи программистов высокого класса. Но они бессильны перед видеоадаптерами от ATi: реверс-инжиниринг драйверов для таких устройств, как видеокарты, очень сложен. Вот открыли бы ATi спецификации - и сообщество сразу бы написало драйвер получше, чем у них!».

Вот такая предыстория. А теперь история.

2006 год.

1). Компания AMD приобретает компанию ATi. Качество драйверов для Linux начинает расти. В среде компьютерных специалистов появляется неопределённость. Раньше были фанаты:

1. Процессоров Intel и видеокарт NVIDIA
2. Процессоров Intel и видеокарт ATi
3. Процессоров AMD и видеокарт NVIDIA
4. Процессоров AMD и видеокарт ATi

А теперь или приходилось вторым и четвёртым фанатам менять убеждения и становиться первыми и третьими, или смириться и приобретать оборудование от компании, ставшей соперником другой предпочитаемой компании.

2). Начинается разработка открытого драйвера nouveau, попытки добавить в открытый драйвер nv 3D-ускорение путём реверс-инжиниринга закрытого драйвера.

3). Поддержка видеокарты GeForce 8 появилась, по традиции, сразу после выхода этих видеокарт: 2D-ускорение, 3D-ускрнеие, разгон. Новые технологии CUDA, PureVideo и PhysX, задерживались. Также задерживалось появление поддержки 2D-ускорения для GeForce 8 в открытом драйвере nv, но тогда это ещё никого не волновало: ничего, добавят потом.

2007 год.

1). Свершилось открытие первой части спецификаций видеокарт ATi. Сообщество пользователей Linux ликует! В то, что это действительно случилось, трудно поверить! Разумеется, основная цель этого действия то, что это позволит улучшить работу ПО на видеокартах ATi, а не создание открытого видеодрайвера для Linux, но и для Linux это огромный подарок! Те, кому не терпится получить хороший драйвер для видеокарты ATi интересуются, почему открыли спецификации, а не готовый исходный код драйвера.

2). В первую же неделю после этого появляется открытый видеодрайвер RadeonHD, отличие которого от ati - начальная поддержка 3D-ускорения. После тестирования она была перенесена в ati. Разработчикам RadeonHD давали очереные части спецификаций раньше, чем сообществу, под условиями неразглашения. В RadeonHD появлялись новые функции, и ускорение старых, раньше, чем в ati. Кроме того, ati был стабильнее. Над открытым драйвером трудятся несколько сотрудников компаний AMD и Novell в режиме полного рабочего дня.

3). Появление NVIDIA CUDA одновременно для Windows и Linux. Логично: учёные вряд ли станут держать вычислительные кластеры под Windows. И сразу после появления CUDA во всех новостях о релизах драйвера NVIDIA появляются тонны исправлений CUDA, и так несколько лет. Года два как утихло, наверное. Также странным является способ распространения NVIDIA CUDA для Linux. Для Windows это два файла, 32 и 64-битная программа установки. Для Linux это 12 файлов, для 6 популярных дистрибутивов Linux! И ладно бы ещё были пакеты в родном для дистрибутива формате, RPM/DEB! Но нет: каждый установщик имеет формат run. Странно: run-файл драйвера один для всех дистрибутивов Linux, хотя сделать один файл для всех версий ядра Linux и X-сервера непросто. А здесь их 6! Впервые пользователи Linux столкнулись с таким отношением компании NVIDIA к себе. Список поддерживаемых дистрибутивов Linux. Технология NVIDIA PureVideo задерживается.

Сегодня ситуация не изменилась. Существует библиотека NVIDIA Cg, для игр, есть версия для Linux. Так даже её теперь распространяют не в tar.gz, а в RPM/DEB/tar.gz, а NVIDIA CUDA 4.2 - в 6 run-файлах.