> Те, кому не впадлу, делают бэкпорты и разделяют такую цену своих хотелок между собой.Если честно, в глубине души я считаю бэкпортирование почти тождеством "работа на мусорный бак". Это дурная работа на ровном месте, за это же время можно было бы сделать что-то более полезное чем борьба с искусственно созданными административно-политическими трудностями. Поэтому я не фанат такого подхода.
И лично мне с технической точки зрения удобнее выкроить полдня в предсказуемом интервале времени и там подтянуть весь софт оптом, нежели колупаться с ручным управлением пакетным менеджером.
Вообще, пакетный менеджер на мое мнение хорош прежде всего тем что позволяет спихать кучу рутины на машину (ну и майнтайнеров, каждому понемногу). И я совсем не горю желанием отыграть это назад и создать себе какие-то дополнительные сложности на ровном месте.
> Это сузешный вариант.
Меня устраивают комьюнити сборки убунтов, по типу хубунты. Сами репы как база вроде нормальные, инсталляционная болванка - без эпикфэйлов, а больше мне от них ничего особо и не надо. А зюзя имеет проблемы с качеством - заходишь браузером дефолтной зюзи на опеннет, а там жесть вместо шрифтов. Я это сам дочинивать должен? Три раза пробовал, все три раза так было. На четвертый мне даже и пробовать такую систему уже не хочется.
> Насколько понимаю, косвенной проблемой для бэкпорта на как раз двухлетнюю ветку может
> оказаться лишь старый llvm со своими сборочными зависимостями.
При том - в LLVM до этак примерно 3.5 (включительно) на GCNах были довольно кусачие баги (хотя особенно злобно в 3.4 и ниже). Кроме всего прочего, оно могло генерить код, от которого GPU встает колом. Да и сама старая MESA порой делала в древних версиях какие-то вещи, вызывающие проблемы у GPU.
Очень мило когда юзерь запускает WebGL демку в браузере .. тынц .. что значит "no signal"?! Вот вам и стабильность "проверенного" софта...
Вообще, на мое нескромное мнение, ((MESA < 10.5) || (LLVM < 3.6)) && GCN) я бы просто в блеклист внес. В браузерах. Чтобы они даже не пытались WebGL через это рендерить - чревато брутальной ремотной DoS attack на драйвер видео, требующей перезагрузки системы "вслепую" или как минимум падением браузера по assert-у в LLVM (забавно когда "посторонняя" либа грубо выносит весь процесс).
> Т.е. mesa-то да, а вот с ним не помню.
Если мы о стабильности, чисто по человечески могу дать совет обладателям GCN-ов (а это почти все APU и GPU от амд за последние пару лет): лучше всего послать всех зилотов с их "стабильностью" и "протестированностью" и просто в принципе не рассматривать LLVM старее 3.6. И MESA 10.5 будет совсем не лишней. Вот это - то что должен принести с собой реально претендующий на десктоп дистр. А в новых иксах и DDX - здорово оптимизнули glamor, так что он местами раза в 2-3 быстрее стал. Уж наверное десктопному дистру ускорение графики лишним не бывает, или чего?
> В "одном дистрибутиве" (tm) на сейчас выработалась промежуточная между "релиз плюс только
> точечные исправления" и "роллинг тестинг" модель:
Это наверное не самый плохой вариант на свете, чем-то отдаленно напоминает то что в убунте. Ну то-есть я раз в полгода не против уделить время массовой подтяжке софта, но мне нужна более-менее стабильная система между перетрясами. А какие мне точечные фиксы нужны - я выбираю путем подключения PPA (ну или самоличной пересборкой, если интересно или сильно надо, а никто не сделал).
> Критерии недостаточно формализованы (и в части ABI этим рано или поздно придётся
> заняться), но на практике результат получается неплохой.
С abi на самом деле небольшие странности бывают и у дебианщиков/убунтуев. Ну то-есть бывает так что перестраивают либу типа openssl, которую использует множество софта. При этом некоторый софт уже стреляные воробьи и честно пишут warning про то что версия фактически доступной либы и хидера - разные.
> (воздевая руки) И эти люди будут попрекать A*T видеоблобами, которые тот якобы
> везде в дистрибутивы пихает!..
Ну во первых драйвер там открытый, но вот фирмваре может требоваться для работы чипа. А кому фирмваре в сервисных сопроцессорах не нравится - должны немедленно отцепить сидюки и флешки, жесткие диски, мониторы, клавиатуры, мыши, да в общем почти любую периферию.
Единственное отличие - что фирмварь некоторых wi-fi сетевок живет не в встроенной флехе а должна догружаться снаружи. Сервисный процессор один фиг есть и большой вопрос что хуже - явно об этом знать, видя его код, или нарваться на его работу тихой сапой. Особо рьяные зилоты как-то тактично обходят этот неудобный вопрос, который однако не делает фирмваре в каком-нибудь жестком диске более безопасным чем внешнее фирмваре.
Никогда не слышали про Equation group и их модуль инфекции HDD firmware? Обеспечивающий их западлостроению весьма незаурядный persistence. Местный Каспер это дело нашел. То что фирмвару менее заметно - ни разу не делает ее безопаснее и дружественнее.
Вот я и думаю - вы лихо передергиваете, или сторонник тактики страуса?
А со своей стороны имею заметить что для меня в общем случае деблоб основного процессора - первый приоритет, а сервисные сопроцессоры - все-таки второй и далее, в зависимости от того куда и что прицеплено. Хотя есть и принципиально недеблобизируемые и проблемные архитектуры, типа Qualcomm Snapdragon какого-нибудь, у которых проц с линем и есть на правах "сервисного сопроцессора" с функцией "отрисовка гуя к нашему модему".
> Кстати, вот так видели? :) http://git.altlinux.org/people/mike/packages/?p=mkimage-prof...
Как интересно... а почему в этом файлике так мало беспроводок? Они где-то еще вписываются? Ну там ралинки - где? Юсб-девайсы всякие, им чуть ли не всем надо фирмварь: и ралинкам, и атеросам, и реалтекам всех мастей, насколько я помню (из того что более-менее массово продается). Там кстати у ath9k_htc фирмварь нынче опенсорсная, так что ее вскоре и щепетильные дебианщики должны бы подхватить. А кроме всего прочего, такая щепетильность - некий стимул остальным вендорам не жадничать. У QualcommAtheros появился такой вот небольшой козырь перед конкурентами. Жаль ath10k это пока не коснулось. Если что - я за открытие фирмварей. Но давайте без ханжества, двойных стандартов и заметания проблем под ковер? А в идеале еще и с разумной расстановкой приоритетов.
