Здравствуйте, Sheridan, Вы писали:

S>>>Не вижу про аппаратное ускорение, вижу несколько вариантов установки дров от нвидии и решению возможных проблем
V>>Это обязательный шаг перед тем как.
S>Установить драйвера? Конечно обязательный.

По ссылке показателен процесс борьбы со всем этим.


V>>>>http://help.ubuntu.ru/wiki/xbmc#установка_на_ubuntu_1204
S>>>12.04?
V>>5 лет назад всего.
S>Не "всего", а "целых"

Ничего существенного в Linux с тех пор не произошло.
Наоборот, наметилось еще большее отставание в плане покрытия возможностей современных GPU.


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

Угу, RHEL 6.x еще очень входу. Как раз с тех времён.
Питона две версии в ходу, руби тоже.
А когда-то хотели за пару лет перейти на новые поколения этих языков.
Не срослось.
OpenGL так и не был заменён на Vulkan и OpenGL ES.
Более того, даже OpenGL 4.x не везде поддерживается целиком.
Wayland так и не вытеснила XServer и т.д. и т.п. до бесконечности.


S>>>Чо не мандрейк 2.0?
V>>Который 22 года назад?
S>То есть ты понимаешь разницу между "всего", и "целых". Странно...

Когда-то Linux развивался очень быстро.
Но это было нормально, когда с 0-ля.
А потом наступает насыщение, упёрлись.
При нынешней кодовой базе требуется качественно другое ей управление, но сообщество Linux еще этого не осознало.
Сейчас пока отвлеклись на облака, но там как раз внутри виртуалок крутятся технологии 3-5-тилетней давности.

Более-менее заметный сдвиг произошёл только в gcc, cmake и kvm.
Но это базовые утилитные технологии, а не целевые.


V>>Когда вышли линуха, была уже 95-я винда, в которой с дровами всё было хорошо.
S>Настолько хорошо, что крашилось прямо на презентации?

Сравнил. ))
На том зоопарке оборудования Linux еще десятилетие даже запускаться толком не могла.


V>>>>Текущее состояние дел только по одной AMD:
V>>>>http://ati.cchtml.com/buglist.cgi?bug_status=__open__&no_redirect=1&order=Importance&query_format=specific
S>>>Давай сравним с текущим состоянием дел этого же самого под виндами, и после этого сделаем выводы. Сможешь показать багтрекер?
V>>Майкрософтный открыт, показывай.
S>а, то есть твои слова должен я доказывать?

Я свои показал. Есть что ответить — отвечай. Нет — нет.


V>>Тут ведь дело не столько в количестве багов, сколько в их качестве: каждый второй о крэше или попадании системы в такое состояние, что другие графические программы не могут продолжать нормально работать.
S>Еще раз: без такогоже багтрекера от тойже винды разговор ни о чом.

Ну так зайди. ))


V>>Скажем так. Еще ни разу на моей памяти с видеоускорителями под лялих не зашло всё гладко. А ситуация двойной картейки, как популярно на ноутах (встроенная интеловская + внешняя от NVidia) — она не покрывается даже сегодня. Внешнюю картейку программно отключают и всех делов.
S>Насчот ноутов не знаю, я приверженец десктопов.

Ну так посмотри статистику продаж.
Сегодня ноуты продаются лучше десктопов.


S>У меня везде мультимонитор был, иногда с несколькими картами. Всё работает, всё ожидаемо, без плясок. Что я делаю не так?

Ты всё делаешь так, как и положено в линухах. Тут поплясал с бубном, там поплясал. В итоге у тебя всё получилось и ты ощутил эдакое профессиональное удовлетворение из разряда "а я ведь могу!". Думаю, оглядываясь назад ты должен понимать, как это всё ущербно, на самом-то деле.

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

Но почему-то (и это для меня загадка!!!) наибольшие любители Linux это не те, кто любит писать код, а те, кто любит собирать чужой!!!
Вот как так, а? За что такое наказание-то?

Понятное дело, если набежали кучу самомотивированных разработчиков, которым интересно лишь конфигурировать билды, то максимум что из этого безобразия можно ожидать — это кучу конфигураций тех самых билдов.

Стыдуха натуральная, как по мне.


V>>От того и популярны до сих пор "микросборки", это когда некая контора берется поставить парк машин под линухами, но при этом оговаривает узкий диапазон железа (или вообще одну конкретную конфигурацию) и предустановленного софта на ём.
S>Ты удивишься, но ТЗ существует не только для железа, но и для кода. И подробность ТЗ зависит напрямую от стоимости контракта.

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



V>>Многие проблемы решаемы, ес-но. Только их приходится каждый божий раз решать. Если при уже правильно настроенном ssh и XServer после инсталляции оно мало где работает "изкаробки", надо зачем-то ставить xauth, который в таком сценарии НЕ используется, но поставить надо — это признак какой-то глобальной происходящей херни. А когда порой вручную этому xauth, который не используется, еще требуется досоздавать некие конфигурационные файлы, то это совсем ой.
S>Это говорите спасибы вашим возлюбленным бинарным дистрибутивам, где сборку делают с подключением всего что опакечиваемый софт умеет и включают это в зависимости. Ни разу у меня в жизни на гентушных серверах ни одного намёка на иксы не было, нопример.

С Гентой свои приколы. Описать для неё "левый" пакет (которого нет в репозитории) — это наиболее трудоёмко на сегодня. А казалось бы — в изначальной идее предполагалось ровно наоборот — отсутствие прибития гвоздями бинарных версий к друг другу, т.е. лёгкость управления версиями. А вот так после очередного обновления и rebuild all, твой левый пакет неожиданно отлетает, потому что старые зависимости тю-тю. И ты заново описываешь для этой Генты пакет. Просто ты ни разработчик, а админ, поэтому печали разработчика от тебя малость далеки. ))


S>Ну так а при чом то тут программисты то? На этом форуме тут то говорят что одмины не нужны, то настройка окружения привносит вам печаль и тоску.

Слишком много "настраивателей". Их надо уменьшить раз в 100, а кол-во разработчиков, наоборот, раз в 10 увеличить.
И тогда этот бардак постепенно сам исчезнет по принципу затухающих колебаний.
Потому что потребуется кооперация релизеров.
Сейчас же каждая кучка релизеров вообразила себя независимой Вселенной, но гадит при этом в общий котёл.


S>Пишете продукт? Пишите. А вот для развёртывания зовите уж админов

Ой, не утомляй. Ничего из того, что может админ, не вызывает трудностей у разработчика. Там отличия только в психологическом восприятии происходящего. Если админу нравится разгребать бардак, то разработчик в этот момент ощущает, что его драгоценное время тратится на борьбу с глупостью вселенского масштаба. И это раздражает, ес-но. И поэтому разработчики малость недолюбливают вас, админов лялиха, которые собственноручно весь этот бардак развели. Ведь разработчик сделал всё от него зависящее, блин! Вот тебе config.h.in, вот тебе утилиты для конфигурирования, вот тебе даже скрипты для билда и дока по зависимостям! Определитесь, уже, наконец, что и куда вы будете распихивать... Но нет. Никто не хочет определяться, все хотят играть в эти детские игры "повелителей машин". Брр-р-р...