В состав Mesa принят патч (https://cgit.freedesktop.org/mesa/mesa/commit/?id=6dc96de303...), устраняющий ошибку, которую находилась в кодовой базе девять лет и приводила (https://bugs.freedesktop.org/show_bug.cgi?id=93649) к неприятным зависаниям (https://github.com/ValveSoftware/Source-1-Games/issues/1943) графической подсистемы после запуска некоторых игровых приложений, в том числе через Wine. Например, с проблемой были связаны многие жалобы о зависании игр "Team Fortress 2" и "Batman Arkham: Origins". Проблема проявлялась не сразу, а в непредсказуемые моменты, после 10-30 минут игры, что усложняло диагностику.URL: https://www.gamingonlinux.com/articles/marek-sent-in-a-patch...
Новость: http://www.opennet.dev/opennews/art.shtml?num=45659
3 строчки кода!? Фаак, вот так и проявляется глобальность малейшей ошибки.
Добро пожаловать в реальный мир
В принципе да, что уж говорить о целых 3 строках, когда одна маленькая запятая может привести к критической уязвимости.
> 3 строчки кода!?А если приглядеться: одна. :)
> 3 строчки кода!? Фаак, вот так и проявляется глобальность малейшей ошибки.Поинтересуйся самой дорогой ошибкой. Там где целая ракета продолбалась. Тоже ошибка была небольшой. Да еще на "типа безопасной" Ada. Которая однако ж не спасла от целочисленного переполнения и софта управления который "gone bananas".
> Because of that, radeonsi uploaded garbage sampler states and the hardwarewent bananas.
9 лет наслаждались бананами
Сушеными.
Только не радуйтесь сильно, там таких ошибок еще полно. Сам вчера обновился, играл 2 часа в TF2 и все было ОК, а попозже решил в CS:GO погонять, и система намертво повисла минуты через 4, даже по ssh было не зайти.
> там таких ошибок еще полноНу, не удивительно. Работая над проектом парсера одного проприетарного формата (проект тоже проприетарен, типа паразитизма :) ), приходится писать просто дохренища тестов, и над этим работают, наверно, два десятка разрабов (не считая простых тестеров), уже пяток лет точно. Вот так вот, пишешь тесты, натыкаешься на подобные сабжу ошибки, исправляешь (или добавляешь функциональность какого-нибудь частного случая). И это довольно скучно, но зато методично.
А здесь проект намного больший, чем у меня. Так что ничего удивительного, что в сложном проекте ошибки. Только для улучшаения качества ресурсы нужны немеряные.
> Ну, не удивительно. Работая над проектом парсера одного проприетарного форматаА что за формат, если не секрет? Или из какой области?
Да один из мс. В частности, мс-прожект. Оказывается, 3рд-пати либы востребованы в ынтерпрайзе, для каких-то бизнес-костылей
>даже по ssh было не зайтиТогда это ошибка в ядре. Может, в KMS.
Сабжевая ошибка тоже ядро вешала.
У меня есть карточка r7 250x, тоже использует radeonsi, так вот она наглухо вешает систему при обычной офисной работе (браузер, файл менеджер, офис).
Отключи "Весь вывод через OpenGL" в настройках Либры.
> решил в CS:GO погонять, и система намертво повисла минуты через 4,
> даже по ssh было не зайти.А лог прое...ся? Хотя если даже ssh не работал - это уже не GPU lockup. Уверен что у тебя железо стабильное и не сбоит под нагрузкой? Все-таки выносить весь кернел для radeon не характерно.
Под виндой ничего не сбоит, разогнана только система охлаждения.
> Под виндой ничего не сбоит,Как все это проверялось? У сэра память с ECC в видяхе и системе, для начала? А то видяхи с ECC - дорогие, падлы. Что у амд что у нвидии.
> разогнана только система охлаждения.
Не очень понимаю как это. Ты не поднимал частоты памяти и ядра и только быстрее крутишь вентилятор? А это нафига? В vbios прописаны кривые таблицы управления вентилятором?
>У сэра память с ECC в видяхе и системе, для начала?Ты либо крестик сними, либо трусы надень. Если отсутствие каких-либо проблем вообще в длительных игровых сессиях под шин (овер 10h + стримчик на твич) нельзя объяснить исправностью железа, то и рандомные зависания под линуксом нельзя на него же списывать.
>Ты не поднимал частоты памяти и ядра и только быстрее крутишь вентилятор? А это нафига?
Да. Потому что мне не нравятся дефолтные целевые температуры, заложенные производителем. +78 градусов, в то время как при легком увеличении скорости воздушного потока СО может легко тянуть +65, это, я считаю, из области запланированных отказов оборудования.
> Ты либо крестик сними, либо трусы надень.А у меня в системе память с ECC. На всякий случай :)
> Если отсутствие каких-либо проблем вообще в длительных игровых сессиях
> под шин (овер 10h + стримчик на твич) нельзя объяснить исправностью железа,Наверное можно. Хоть и не всегда. Каталист - забавная штука. За годы и годы в него добавили множество костылей и воркэраундов заскоков железок. И никто это особо не документировал. Люди увольнялись. Железки релизились. И теперь даже в команде каталиста зачастую никто не знает почему тут этот код и какой баг железа он затыкает. Очень много багов железа прокостылены софтом, с разной степенью успешности и последствиями.
> то и рандомные зависания под линуксом нельзя на него же списывать.
Когда как. У ряда видеокарт есть какой-то закидон когда они некорректно работают с наивысшей частотой памяти, например. И вообще немало забавных багов железа самой разной степени крутизны.
>>Ты не поднимал частоты памяти и ядра и только быстрее крутишь вентилятор? А это нафига?
> Да. Потому что мне не нравятся дефолтные целевые температуры, заложенные производителем.Прикольно, прошаренный чувак, знаешь чего хотеть :)
> +78 градусов, в то время как при легком увеличении скорости воздушного
> потока СО может легко тянуть +65, это, я считаю, из области
> запланированных отказов оборудования.На самом деле critical обычно считают нечто типа 90-120C, поэтому 78 дает некий запас. Хоть на мой вкус и многовато. Видимо производитель хотел чтобы их фигня меньше выла вентиляторами при прочих равных.
Если у тебя открытый драйвер - можешь в sysfs перехватить управление вентилем, через стандартный интерфейс hwmon. Идешь в /sys/class/hwmon и находишь там видяху. Ну а дальше pwm можно переключить в ручное управление (записью в pwm_enable другого варианта) и дальше что запишешь в файл pwmX то и получишь от PWM в вентиль. Можешь хоть свою приблуду с кастомной логикой написать, если уж такие замашки. Только имей в виду что если ты решил сам рулить PWM то баги сажать в таком коде не полагается :). По дефолту там значение когда вентилем рулит SMU (сервисный процессор видяхи) в меру своей дури и он таблицу из vbios берет как раз IIRC.
Ну а чего вы хотели? Обратите внимание на расширение файла:> src/gallium/auxiliary/cso_cache/cso_cache.c
То ли дело *.js или .jar, да?
думаю, это толстый намек на .rs
> думаю, это толстый намек на .rsТак пусть он напишет свою операционку и драйверы для нее на чем там ему удобнее. Заодно посмотрим сколько на расово верных ЯП занимает написать GL 4.5 со всеми потрохами и отладить его.
Вероятно, он имел ввиду намёк на совпадение имени файла с CS :)
у кого что болит
> csoвот так и палится всякое фанатье
Если бы там было .java она просто не работало?
Хватит бздеть. Ошибка эта, как раз, чисто логическая, ничего присущего Си в ней нет.Скорее, указать надо на отсутствие покрытия тестами
> causing use-after-free in driversuse-after-free -- ошибка, специфичная как раз для си.
бла? http://www.securityfocus.com/bid/93621
> бла? http://www.securityfocus.com/bid/93621Что именно "бла"?
> java.awt.Menu objects. By performing actions in code an attacker can cause a pointer to be reused after it has been freed.AWT, внезапно, платформозависимая часть. И опять же, похоже совершенно внезапно для фанатов -- ВМ жабы написана отнюдь не на самой жабе ;)
http://openjdk.java.net/groups/awt/
> AWT has a very old code base, and has a complicated structure. Parts of the code are
> ...
> The native parts of the code base are written in C and C++. Most of the code is platform-specific and resides in the corresponding directories: src/solaris/ or src/windows/
% find /tmp/jdk-687fd7c7986d |grep -i "awt.*menu"|tail
./src/windows/native/sun/windows/awt_Menu.cpp
./src/windows/native/sun/windows/awt_MenuItem.cpp
use-after-free в самой жабе был бы багом GC.
А покажи мне драйвер на java.
> А покажи мне драйвер на java.смотреть где-то тут
http://www.javapos.com/
https://code.google.com/archive/p/poskioskконешно наверно чаще всего это дрова для ком/юсб устройств
Открыть порт и послать в него практически plain text... это такой же драйвер как echo "trash" > /dev/any_dev
или как fopen()
вы обманываете сами себя
Судя по этому https://scan.coverity.com/projects/mesa в mesa полно ещё не исправленных ошибок.
Это все ерунда, там еще целая гора чисто железячных ошибок, которые ни одним анализатором не отловишь. Если следите за кодом мезы, то наверняка не один раз видели коммиты "отключить фичу N для чипа Y, потому что потому".
Может стоило проверку
if (type != CSO_SAMPLER)
засунуть в
sanitize_hash(sc, hash, type, sc->max_size);
?
Если организовывать код правильно, широко используя абстракции и грамотно разруливая ответственности (а именно такой подход практикуется в Java), багов больше не будет, и программистам на си перестанут платить за вечное исправление вечных багов.
Эльф?
Конечно не будет - потому в результате драйвер вообще не взлетит. Ответственности и абстракции отнюдь не бесплатны, и там, где производительность важна, приходится писать на том и так, чтоюы эта самая производительность всё же была.А там, где главное - написать сложный софт в разумные сроки, а эффективность - дело второе (те же банки, угу) - там да, красивое ООП во все поля - в самый раз. Ну и, как водится, куча компромиссных ситуаций между.
Красивого ООП там к сожалению не так много как могло-бы быть ;) там скорее благодаря живучести кода на определённых платформах костыли ещё не привели к обвалу конструкции :)
Это да. Красивый ООП - явление чрезвычайно редкое. Наверное, это потому, что есть платформы, которые его возвели прямо-таки в религию, и заставляют программистов пихать его повсюду, к месту и не к месту.Единственный раз, когда я видел качественную объектную модель, это был ocaml-cryptokit от Xavier Leroy. Больше оправданного ООП не наблюдал в жизни.
В моем посте #27 про ООП вообще ни слова не было. Говорил лишь о том, чтобы четко разграничивать ответственности. Так, например, проверку действительно можно было бы засунуть в функцию, а не помнить об этом требовании (type != CSO_SAMPLER) везде и всюду при ее вызове.
Если ты готов дать гарантии, что она там вообще всегда нужна - тогда да. А если иногда она там лишняя - то в критичном к проиводительности коде это паршивая идея.
Не о тех масштабах речь. Берёте любой большой софт - банковский, ERP и подобное - там без ООП вообще не выжить. И речь уже не о производительности, а о том, как эту гору логики хоть как-то организовать.
> Не о тех масштабах речь. Берёте любой большой софт - банковский, ERP
> и подобное - там без ООП вообще не выжить.Я склонен считать, что Вы всё-таки заблуждаетесь.
Вот думаете, почему многие явисты вместо того, чтобы наследоваться, занимаются инкапсуляцией суперклассов в порождаемый в качестве полей? Можно, конечно, ссылаться на то, что JVM не поддерживает множественного наследования, однако имхо всё проще: не всё хорошо ложится на иерархические структуры - раз, в попытках впихнуть всё в иерархию делается множество оверрайдов, что ведёт к проблемам при обновлении классов, от которых вы относледовались - два.
> И речь уже не о производительности, а о том, как эту гору логики
> хоть как-то организовать.Ну дык, организация логики продукта - та ещё зубодробильная задачка для архитектора. И она легко не решится ни с ООП, ни без него.
Большинство задач подобного рода я лично решаю посредством модулей, а также посредством генерации модулей на лету на основе других модулей. Модули удобней в большинстве случаев хотя бы тем, что помимо методов и полей позволяют также определять и абстрагировать новые типы внутри модуля.
Вообще, чтобы хорошенько прочувствовать, почему лучше оперировать модулями вместо классов - достаточно посмотреть как Jane Street переделали (а лучше сказать - дополнили) стандартную библиотеку OCaml, то бишь на Core. Я надеюсь, это достаточно масштабный проект, особливо с учётом того, что Jane Street как раз разрабатывает ПО для бирж.
Хм, разница в понимании "красивого" ООП, наверное.
Хорошая архитектура - это не значит ущерб производительности. Надеюсь, ты не это имел ввиду.К сожалению, фанатичные апологеты всяких методик (ООП, паттерны, всякие XP) (часто, у них еще и академический бекграунд превалирует над промышленным опытом работы), дискредитируют понятие архитектуры, привнося в код необоснованные усложнения под видом "зато соответствует методике!". Тогда как ни одна методика не является серебряной пулей, и слепо впихивать в её рамки текущую задачу не требуется.
"Соответствует методике" для больших систем - важнейший аргумент. Потому что их вообще никто не знает и знать не может в силу объёма. Поэтому код должен быть максимально предсказуемым - иначе его поддежка - на маштабах-то - выйдет золотой.И чем больше масштаб системы - тем больший процент затрат - хоть человеческих, хоть машинных - уходит на бюрократию, от документирования до слоёв абстракций. Другими словами, ущерб производительности здесь не от хорошей архитектуры, а хорошая архитектура в данном случае требует разменять производительность на управляемость - что иначе гораздо больший ущерб был бы где-то в другом месте - в расширяемости, или стоимости поддержки, или в рисках, связанных с багами, вызванными связностью, или ещё где.
Поэтому - GC, фабрики фабрик, DI и тому подобное, чтобы всё работало максимально униформно и не требовало рефакторинга миллионов строк.
клоун: Линукс, Libre Office - это большие системы? Много времени уходит на документирование? Где посмотреть столько качественно составленную документацию и слои абстракции?Вот работа из-под 1С с Экселем:
Excel = Новый COMОбъект("Excel.application");
Excel.WorkBooks.Open(ПолноеИмяФайла);
Лист = Excel.Sheets(1); // Первый лист по индексуИ с LibreOffice (найди 5 отличий):
OpenOffice = Новый ComОбъект("com.sun.star.ServiceManager"); // Создаем СОМ-объект
scr = Новый ComОбъект("MSScriptControl.ScriptControl");
scr.language = "javascript";
scr.eval("MassivParametrov = new Array()");
MassivParametrov = scr.eval("MassivParametrov");
scr.AddObject("OpenOffice", OpenOffice);
scr.eval("MassivParametrov[0]=OpenOffice.Bridge_GetStruct('com.sun.star.beans.PropertyValue')");
scr.eval("MassivParametrov[0].Name='Hidden'");
scr.eval("MassivParametrov[0].Value=true");
Desktop = OpenOffice.CreateInstance("com.sun.star.frame.Desktop"); // Создаем Desktop
URL = ConvertToURL(ПолноеИмяФайла); // Правильно формируем имя файла
Doc = Desktop.LoadComponentFromURL(URL, "_blank", 0, MassivParametrov);
Doc.lockControllers();
Doc.addActionLock();
Sheets = Doc.GetSheets();
Лист = Sheets.GetByIndex(0); // Открываем первый лист по индексуВ одной из этих программ явно проблемы с уровнями абстракции и удобством использования, не находите?
>Создаем СОМ-объектПроблема именно вот в этом, а не в чем-то другом.
клоун: Думаешь? А я вот вижу другую картину.Вот почитай, в глаза ярко бросается бесполезная избыточность LO по сравнению с MSO.
http://beginwithsoftware.com/LibreOffice/Sravnenie_Excel_Cal...
MSO: Макросы - Безопасность макросов
LO: Сервис - Параметры - Параметры - LibreOffice - Безопасность - Безопасность макросов - Уровень безопасности
Аналогичную избыточность мы видим на программном уровне (на примере чтения из ячейки):
MSO.Sheets(1).Cells(Строка, Колонка).Value
LO.GetSheets().GetByIndex(0).getCellByPosition(Колонка,Строка).getText().String()
> клоун: Думаешь? А я вот вижу другую картину.Еще раз, вы используете com объеты, это как минимум оффтоп на этом сайте. А во-вторых это неправильный, вантузячий подход.
Ха, тролль прилез... до перового появления модератора, полагаю.Не нахожу. Я вообще не понимаю, зачем они это COM-уродство поддержали. На редкость ублюдочная реализация отличной идеи компонентов. Тем более, что ODF, в отличие от OOXML, довольно логичен и поддерживается массой софта и в 99% случаев для работы с ним дёргать либру вместо подходящих библиотек - глупость. Это чтобы сэмулировать косяки МС офиса проще всего его и взять.
А что до линукс-ядра - ну да, это одно их тех исключений, где абстракции и дешевизну поддержки приходится приносить в жертву эффективности. Всем миром - вполне выходит справиться. Документация там, кстати, хорошая.
> В одной из этих программ явно проблемы с уровнями абстракции и удобством
> использования, не находите?Здатый получился графический драйвер. Наймите этого assclown'а в MS, дрова видеокарт улучшать.
> в MS, дрова видеокарт улучшать.инкремент в количество клоунов
> (а именно такой подход практикуется в Java), багов больше не будет,Ты вообще представляешь себе что будет если графические вещи на яве писать? Она не тормозит же. И скорость провалится раза в три. А потом окажется что GC лаги на пару секунд вызывает - и станет совсем хорошо. Здорово же когда играл ты в шутер, прицелился - ОПА - спуск не жмется! Извольте сборку мусора подождать. А вот соперник ждать не будет...
Зачем люди используют линукс для игр типа "Team Fortress 2" и "Batman Arkham: Origins" - есть же винда, в ней все работает хорошо, причем еще и быстрее, там всякие DirectX и прочее. Вообще нет пролбемм.
Линукс - это станция рабочая для интернетов, скайпа, либры, музычки и видео.
Но играть в игры, нарываться на зависания, терпеть это все... - это реально проявление мазохизма.PS. Ну еще в "ежиков" и "tee worlds" можно поиграть, и прочее.
Играют большую часть времени за компом далеко не все из тех кто вообще играет за компом. Может банально не быть мотивации для приобретения еще одной машины, заморочек с пробросом видеокарт в виртуалки или тем более вырыванием себя из привычного контекста в дуалбут ради убить пару часов с большим фпс.
> Зачем люди используют линукс для игр типа "Team Fortress 2" и "Batman
> Arkham: Origins" - есть же винда, в ней все работает хорошо,
> причем еще и быстрее, там всякие DirectX и прочее. Вообще нет
> пролбемм.
> Линукс - это станция рабочая для интернетов, скайпа, либры, музычки и видео.
> Но играть в игры, нарываться на зависания, терпеть это все... - это
> реально проявление мазохизма.
> PS. Ну еще в "ежиков" и "tee worlds" можно поиграть, и прочее.Потому-что не все хотят ради игры ставить вторую систему, не все готовы платить за win либо пользоваться нелегально, да и просто может быть нет желания перегружаться :)
Ребутить лень
У меня NVIDIA, и FPS в играх равен виндовому. В нативных, конечно :-) В играх, работающих через трансляторы, на 30-35% ниже. Первая на toGL, вторая на eON. Отстой, поэтому я такие порты бойкотиирую
> Линукс - это станция рабочая для интернетов, скайпа, либры, музычки и видео.А ты не слишком ли обнаглел за всех решать что и для чего? Иди вон Gabe Newell'у расскажи какой он там лох по сравнению с тобой, таким умным.
> Но играть в игры, нарываться на зависания, терпеть это все... - это
> реально проявление мазохизма.Ну конечно, в винде драйверы пишут эльфы из индии и они то уж точно никогда не ошибаются. А если все-таки что-то зависло или сглючило - попробуйте нажать на ресет, да? А тебя не смущает что у интеля например драйвер под винду настолько отборный крап что даже WebGL не работает по умолчанию? Хоть он и урезанный весьма, но браузеры боятся использовать даже это. Что намекает на какчество реализации, так сказать.
> , да? А тебя не смущает что у интеля например драйвер под винду настолько отборный крап что даже WebGL не работает по умолчанию? Хоть он и урезанный весьма, но браузеры боятся использовать даже это.Врешь же
> Врешь же
> https://www.khronos.org/webgl/wiki/BlacklistsAndWhitelistsА при чем тут Khronos? У хрома и лиса есть свой собственный блэклист заведомо кривых видеодров, по pci ID железок и версиям дров.
И вот в них довольно много каких железок с дровами по разным поводам с разными ограничениями, вплоть до отсутствия ускорения совсем. И таки большинство интела с стоковыми дровами из системы вообще WebGL не может. Khronos'а тут вообще никто не спрашивал - какие конфигурации создавали проблемы и баги, такие и порубали. Не комильфо когда вебпага может уронить систему в BSOD, знаешь ли. А такое бывает. Кста можешь поискать на хабре заметку - кто-то допер пофуззить шейдеры и нашел over 9000 багов. Дада, опять webgl может винду в бсод отправить :)
> А ты не слишком ли обнаглел за всех решать что и для
> чего? Иди вон Gabe Newell'у расскажи какой он там лох по
> сравнению с тобой, таким умным.пфф, не нужно таких тупых аргументов, они только снижают уровень оценки Вашей адекватности
> пфф, не нужно таких тупых аргументов, они только снижают уровень оценки Вашей адекватностиПфф, еще один за всех решатель тут выперся, аекватность он оценивать видите ли полез. Вы там с адекватом как-нибудь свою адекватность и оценивайте.
Где они были месяц назад? Я уже карточку от Nvidia успел купить.
Дайте ссылку на бинарники для Trusty 14.04
> Дайте ссылку на бинарники для Trusty 14.04Oibaf PPA
там только для 16.04 и 16.10