Умудрились изговнякать клавиатуру и тачпад, которые 10 лет подряд на Precision-серии были идеальными. Молодцы, чо.
Видимо, придётся таки уходить обратно на технику Lenovo.
Они что можно опенсорсить опенсорсят. Вон, все дрова к Tegra открытые, nvidia-uvm под MIT-лицензией. А в драйверных блобах куча стороннего кода, который передавать в опенсорс лицензия не позволяет.
Петли. У них отвратительные петли. Причём если на M4X00 ломалась сама петля и её можно было спокойно заменить, то на более свежих пресижонах она при заклинивании выдирает с мясом кусок верхней крышки.
Бывает нужно как минимум при необходимости преобразовать аргументы конструктора, передать дальше И сохранить у себя. Пока такой переданный дальше аргумент один и не зависим от остального — можно нагородить статический метод с приватным конструктором. Когда начинаются кросс-зависимости — становится грустно.
Второй сценарий — когда кто-то догадался в базовом классе из конструктора дергать виртуальный метод, а нам теперь позарез надо поведение этого метода менять в зависимости от того, что нам прилетело в конструктор.
Вообще такие вещи обычно делают через самописный Fody-weaver на пару десятков строк, меняющий место вызова базового конструктора в сгенерированном MSIL.
С WPF вообще есть недоразумение — если на не полностью обновлённую систему накатить .NET 4.8, то ВСЕ приложения на WPF под полный фреймворк перестанут запускаться. Совсем.
Не, они вовнутрь линукса цельнотянутый WDDM и DirectX прокинули. Там внутри теперь есть /dev/dxg и поставляются собранная из оригинальных исходников libd3d12.so.
И, кстати, нугет тут совсем не причём, это ошибка рантайма.
Иииии, у нас ещё один не разобравшийся в вопросе.
Вышеописанная проблема возникает на этапе restore, задолго до того как приложение вообще скомпилировалось. К рантайму вообще отношения не имеет.
Притом, что если внимательно прочитать сообщение, то можно заметить, что в графе зависимостей нет необходимости ставить две версии одной dll. Все зависимости определены как >=, но нугету всё равно становится плохо.
Там проблема из-за достаточно тупой стратегии под названием nearest wins.
Т. е. имеем граф зависимостей вида:
App
- Lib1 >=1.0
- Lib2 >=1.0
- Lib1 >= 1.0
Ничего не трогаем, обновляем Lib2 до 1.1
App
- Lib1 >=1.0
- Lib2 >=1.1
- Lib1 >= 2.0
вроде бы все зависимости нормально разрешаются (тот же APT бы бровью не повёл), но с нугетом мы получаем
NU1605 Detected package downgrade: Lib1 from 2.0.0 to 1.0.0. Reference the package directly from the project to select a different version.
App -> Lib2 1.1.0 -> Lib1 (>= 2.0.0)
App -> Lib1 (>= 1.0.0)
Это проблема QEMU или проблема не умеющего в виртуализацию графики оборудования? Вроде как выходит что второе, у QEMU как раз всё хорошо.
Так-то ещё MxGPU от AMD есть, но у них с драйверами всё как обычно.
Умудрились изговнякать клавиатуру и тачпад, которые 10 лет подряд на Precision-серии были идеальными. Молодцы, чо.
Видимо, придётся таки уходить обратно на технику Lenovo.
Тех кто мог делать у нас отжали в 90-ые, когда шла массовая эмиграция.
Они что можно опенсорсить опенсорсят. Вон, все дрова к Tegra открытые, nvidia-uvm под MIT-лицензией. А в драйверных блобах куча стороннего кода, который передавать в опенсорс лицензия не позволяет.
У меня так до сих пор на балконе лежит 100 штук SATA HDD производства Hitachi, которые никуда кроме их NAS не воткнуть, да.
Навигатор тоже заставляют без неё работать, если что. "Нет доступа — покажите карту и дайте проложить маршрут между точками".
Петли. У них отвратительные петли. Причём если на M4X00 ломалась сама петля и её можно было спокойно заменить, то на более свежих пресижонах она при заклинивании выдирает с мясом кусок верхней крышки.
4.8 — это каждая пятая поездка с оценкой в 4 вместо 5, если что.
Бывает нужно как минимум при необходимости преобразовать аргументы конструктора, передать дальше И сохранить у себя. Пока такой переданный дальше аргумент один и не зависим от остального — можно нагородить статический метод с приватным конструктором. Когда начинаются кросс-зависимости — становится грустно.
Второй сценарий — когда кто-то догадался в базовом классе из конструктора дергать виртуальный метод, а нам теперь позарез надо поведение этого метода менять в зависимости от того, что нам прилетело в конструктор.
Вообще такие вещи обычно делают через самописный Fody-weaver на пару десятков строк, меняющий место вызова базового конструктора в сгенерированном MSIL.
С WPF вообще есть недоразумение — если на не полностью обновлённую систему накатить .NET 4.8, то ВСЕ приложения на WPF под полный фреймворк перестанут запускаться. Совсем.
У Apple с их нотаризацией это прокатило, если что.
SGX нужен для DRM видеоконтента в основном, а не для игр.
Не, они вовнутрь линукса цельнотянутый WDDM и DirectX прокинули. Там внутри теперь есть /dev/dxg и поставляются собранная из оригинальных исходников libd3d12.so.
Это же хорошие новости,
зондDRM не нужен.Иииии, у нас ещё один не разобравшийся в вопросе.
Вышеописанная проблема возникает на этапе restore, задолго до того как приложение вообще скомпилировалось. К рантайму вообще отношения не имеет.
Cемантическое версионирование на происходящее никак не влияет, тот же самый эффект случается при смене 1.0.0 на 1.0.1
Притом, что если внимательно прочитать сообщение, то можно заметить, что в графе зависимостей нет необходимости ставить две версии одной dll. Все зависимости определены как >=, но нугету всё равно становится плохо.
Там проблема из-за достаточно тупой стратегии под названием nearest wins.
Т. е. имеем граф зависимостей вида:
Ничего не трогаем, обновляем Lib2 до 1.1
вроде бы все зависимости нормально разрешаются (тот же APT бы бровью не повёл), но с нугетом мы получаем
Это проблема QEMU или проблема не умеющего в виртуализацию графики оборудования? Вроде как выходит что второе, у QEMU как раз всё хорошо.
Так-то ещё MxGPU от AMD есть, но у них с драйверами всё как обычно.