LINUX.ORG.RU

В коде xz версий 5.6.0 и 5.6.1 обнаружен бэкдор

 ,


4

9

Разработчик Debian и исследователь в сфере информационной безопасности Andres Freund сообщает об обнаружении вероятного бэкдора в исходном коде xz версий 5.6.0 и 5.6.1.

Бэкдор представляет собой строчку в одном из m4-скриптов, которая дописывает обфусцированный код в конец скрипта configure. Этот код затем модифицирует один из сгенерированных Makefile проекта, что в конечном итоге приводит к попаданию вредоносной нагрузки (замаскированной под тестовый архив bad-3-corrupt_lzma2.xz) непосредственно в исполняемый файл библиотеки liblzma.

Особенность инцидента состоит в том, что вредоносные скрипты сборки, служащие «триггером» для бэкдора, содержатся только в распространяемых tar-архивах с исходным кодом и не присутствуют в git-репозитории проекта.

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

По ссылке исследователь отмечает, что в конечном итоге целью бэкдора, по-видимому, является инъекция кода в процесс sshd и подмена кода проверки RSA-ключей, и приводит несколько способов косвенно проверить, исполняется ли вредоносный код на вашей системе в данный момент.

Рекомендации по безопасности были выпущены проектами Arch Linux, Debian, Red Hat и openSUSE.

Разработчики Arch Linux отдельно отмечают, что хотя заражённые версии xz и попали в репозитории дистрибутива, дистрибутив остаётся в относительной «безопасности», т. к. sshd в Arch не линкуется с liblzma.


Проект openSUSE отмечает, что ввиду запутанности кода бэкдора и предполагаемого механизма его эксплуатации сложно установить «сработал» ли он хотя бы раз на данной машине, и рекомендует полную переустановку ОС с ротацией всех релевантных ключей на всех машинах, на которых хотя бы раз оказывались заражённые версии xz.

>>> Подробности

★★★★★

Проверено: maxcom ()
Последнее исправление: ilinsky (всего исправлений: 2)

Ответ на: комментарий от tm4ig

Он сами себя дискредитировали внезапно забанив репозиторий. Вероятно прячут улики.

Skullnet ★★★★★
()
Ответ на: комментарий от Skullnet

Окстись. Вирусня в опенсорц встраивается не так и работает иначе. Главный опенсорц-вирус называется chromium, и его ты установил себе сам, в полном соответствии со старинной шуточкой про «линукс-вирус нужно скачать и запустить самому АХАХАХА».

А мобилки работают на целых вирусных операционных системах, в т.ч. опенсорцных, и всем нормально.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от firkax

А на тебя всем насрать. Это во-первых.

А во-вторых, человек, который будет говорить, что никогда не пользовался браузером на хромых компонентах - трепло и не существует.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от thesis

Не отмазывайся, ты заявил что все пользуются, и вот тебе пример то не все. И что им пользуется Skullnet - ты не обосновал.

что никогда не пользовался браузером на хромых компонентах - трепло и не существует.

Опять враньё. Если у тебя гуглозависимость развилась и ты не представляешь как жить без его зондов - не значит что все такие.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Ну, огнелис уже давненько как заменил один критический компонент отрисовки графики cairo на гугловскую skia. (А в GTK вообще перешли напрямую на OpenGL/Vulkan.)

gag ★★★★★
()
Ответ на: комментарий от dimgel

Компонент GtkGLArea стал доступен из-коробки в GTK 3.16. Это если надо кое-что с максимальной производительностью отображать. А для менюшек, текста, кнопочек, списков и т.п. никакой особой необходимости их ускорять я не вижу. А это было сделано для реализации эффектов, анимации повсюду. Это забавно выглядит, да, но, по-моему, мешает продуктивной работе.

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

gag ★★★★★
()
Ответ на: комментарий от cvs-255

На малинке GTK 2 не тормозит (GTK 3 в принципе тормознее). И речь только о рендеренге содержимого виджетов в окошках. (Да и cairo была оптимизирована до дальше уже некуда). А сам вывод картинки через иксы всё равно ускоряется.

gag ★★★★★
()
Ответ на: комментарий от gag

Не знаю насчет geode, но всякие чипы для телеков, например, могут быть невероятно тормозными во всей графике, которая не аппаратно ускорена. Потому что их изначально проектировали так что подразумевалось аппаратное ускорение

cvs-255 ★★★★★
()
Ответ на: комментарий от cvs-255

Geode как раз для встраиваемых систем. Но учитывая цену явно не для телеков.

Да, в итоге получается, что есть какая-то слабая железка но с OpenGL ES, на которой будет и вэйлэнд, и GTK 4. А есть вполне себе достаточные для работы ноуты и ПК, но в которых нет достаточно свежей OpenGL ES / 3+, не говоря уже о вулканах - и всё, приехали.

gag ★★★★★
()
Ответ на: комментарий от gag

В итоге, раньше программы на GTK быстро запускались, а теперь пока все эти шейдеры прокомпилируются.

Не, ну это косяк. Надо кешировать.

Я радовался про сам принцип: надо быть поближе к железу, убирая прослойки. OpenGL/Vulkan – ближе некуда, т.е. идеально.

А если cairo/skia/хз-кто-ещё полезен потому что умеет не только в примитивы, но и что-то такое, чего не умеет собственно вулкан, то это надо оформлять неинтрузивными хелперами, ни в коем случае не прогоняя через его фасад все вызовы вообще.

dimgel ★★★★★
()
Ответ на: комментарий от dimgel

Не, ну это косяк. Надо кешировать.

Да, но не в GTK:

А, значит, после того, как они сообщили это в mesa, их это больше не интересует, и баг закрыт. А в mesa совсем никуда не торопятся:

Вот так тривиальное кеширование оказывается сложной задачей.

gag ★★★★★
()
Ответ на: комментарий от gag

Да, но не в GTK

А с точки зрения спецов по графическому стеку, кто на самом деле должен кешировать – mesa или gtk? На моё сугубо общефилософское ИМХО, с более низкоуровневыми инструментами и возни бывает поболее (типа как ручное управление памятью vs сборка мусора), а тут звучит так, что кто-то хочет и рыбку съесть, и жопу не ободрать.

(Хотя по твоей первой ссылке, где про show window performance, в одном из каментов речь идёт даже про компиляцию шейдеров, а тупо про их медленную загрузку. Забавно.)

dimgel ★★★★★
()
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от dimgel

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

cvs-255 ★★★★★
()
Ответ на: комментарий от dimgel

Когда в Debian открывают баг, что с такой-то либой/программой что-то не так. То даже если дело не в опакечивании, а в апрстриме, то баг помечается, что перенаправлен по такому-то upstream URL. Но его нельзя закрыть, пока первопричина не будет исправлена. Так как пользователи Debian используют этот пакет и, в первую очередь, будут искать баг там (ну, хорошо, это немного идеализировано).

Т.е. сказать что баг в mesa, это просто, но, ведь, тормозят просто все GTK 4 программы. И приходить с рапортом будут именно к тебе в GTK, а ты такой, у нас всё в порядке, бага нет, это «ему не слышно». И, ведь, существует же механизм «blocked by».

И, вот, оказывается, что OpenGL это всё ещё для более менее крупного спец. графического софта, который ты запускаешь (а там столько потрохов, что и кеширование шейдеров особо не замента), а потом часами используешь. А не для калькуляторов, блокнотов, просмотрщиков, плееров и прочей мелочи.

gag ★★★★★
()
Ответ на: комментарий от gag

Я тут процитирую товарища @shimon в очередной раз, который очень хорошо описал ситуацию с багами в Debian:

Хотя, вообще, у дебианщиков (да и многих других) несколько своеобразное представление о стабильности.

Когда дебианщики видят грабельное поле, то они тщательно утыкивают его понятными только им флажками, но сами грабли не трогают. Потому что стабильность. Убираются грабли, на поверку оказавшиеся обоюдоострыми, но только после того, как они убьют кого-то из пользователей насмерть, только после двухнедельного совещания в рассылках, и только после того, как кто-то недовольно хлопнет дверью.

Иногда в порядке окучивания граблей грабли заменяют на противопехотные мины (кто помнит эпичнейший фейл с OpenSSL?). Конечно, конечно, хотели как лучше, чтоб от наступания не было больно...

Ну и что, что в других дистрибутивах грабли собрали комбайном? Что с того, что в других дистрибутивах уборка граблей стала процессом постоянным? Это ни черта не значит, ведь это нарушает стабильность. А тут поле с флажками, такое теплое, такое свое, прям как е#учий ЗиЛ «буханка», прости господи, мать твою через коромысло.

Тыц: XScreensaver может быть удалён из Debian (комментарий)

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

только после двухнедельного совещания в рассылках

Не, ну по-разному бывает. Вот с xz мгновенно пересобрали в sid, и ещё не прошло и 11 часов, как уже пошло в testing.

кто помнит эпичнейший фейл с OpenSSL

Примечательно, что тут как раз просматриваются параллели со случаем с xz. Разве что тут «добрый» ко-разработчик хотел поскорее заткнуть valgrind.

gag ★★★★★
()
Ответ на: комментарий от gag

На всевозможных телеках opengl es используется для почти всего. (Кроме броадкомоских чипов, там своё апи)

cvs-255 ★★★★★
()
Ответ на: комментарий от gag

И, вот, оказывается, что OpenGL это всё ещё для более менее крупного спец. графического софта, который ты запускаешь (а там столько потрохов, что и кеширование шейдеров особо не замента), а потом часами используешь. А не для калькуляторов, блокнотов, просмотрщиков, плееров и прочей мелочи.

Когда-нибудь я доберусь проверить этот тезис, написав десктопную софтину на ImGUI/Vulkan…

…Кстати! Проблема тормозов компиляции и/или загрузки шейдеров решается тривиально: отказом от оных. Или может cairo тоже шейдеры компилирует? А может тут просто горе от ума: шейдеры – это круто, надо заюзать:

Подошел я тут к тимлиду:
Надо нам внедрить блокчейн
Он, дурак, засомневался
говорит «А нам зачем?»
Как зачем, ведь это модно!

dimgel ★★★★★
()
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от dimgel

В шейдерах как раз и реализован код для графических ускорителей - не откажешься. В cairo его, соответственно нет. Точнее был экспериментальный бэкэнд для OpenGL, но его не допилили, а недавно GTK-шник и выкинул.

gag ★★★★★
()
Ответ на: комментарий от gag

В смысле «не откажешься»? Нынче что, уже нельзя использовать древнее до-шейдерное API рисования примитивов? Только в шейдеры его запихивать и потом их вызывать? Не верю. Qt, опять же, юзает EGL бакенд – и вполне себе шустро работает.

dimgel ★★★★★
()
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от dimgel

Нынче что, уже нельзя использовать древнее до-шейдерное API рисования примитивов?

Да, нельзя. Fixed pipeline уже не поддерживается на аппаратном уровне, а старые API без шейдеров всё равно работают через шейдеры, но внутри реализации Mesa и прочих драйверов.

X512 ★★★★★
()
Ответ на: комментарий от X512

А я вот читаю эту обсуждения и не понимаю, какие такие тонны шейдеров необходимо компилировать?

Речь же идет о выводе элементарной двумерной графики? Или нет?

Там и шейдеры будут простейшие.

wandrien ★★
()
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от X512

Ну на нынешнем моем проекте используется skia на телеках, стартует довольно быстро

cvs-255 ★★★★★
()
Ответ на: комментарий от wandrien

какие такие тонны шейдеров необходимо компилировать?

Ещё и по несколько раз, якобы.

gag ★★★★★
()
Ответ на: комментарий от X512

Моя старая видеокарта поддерживает только старую версию шейдеров. Я правильно понимаю, что новые версии шейдеров эмулируются, поэтому у меня и тормоза в gtk-3 приложениях, или это никак не связано?

baobab
()
Ответ на: комментарий от dimgel

Дошейдерное уже давным-давно объявлено устаревшим. Если используешь GLUT, GLFW или ImGUI (которое использует одну из этих обёрток), то ты волен всё ещё использовать fixed pipeline.

Вот то Qt на qml, что использует EGL? И тут тонкость в том, чтобы шустро запускалось.

gag ★★★★★
()
Ответ на: комментарий от gag

Кшмар. Хочу в детство. Велосипед, воздушные змеи, а не вот это всё.

dimgel ★★★★★
()
Ответ на: комментарий от dimgel

древнее до-шейдерное API рисования примитивов?

А ты думаешь, почему в винде запилили AERO? Чтобы красиво? Нет, чтобы композитор вместо примитивов. На переходе с XP на Windows 7 на слабык компах но с OpenGL карточкой было очень заметно: на XP окна мигают-лагают, на 7 прям целые двигаются. Естественно, на старых Matrox и Ati Mach64 под XP окошки были плавными, чёткими и быстрыми.

Shadow ★★★★★
()
Последнее исправление: Shadow (всего исправлений: 1)
Ответ на: комментарий от Shadow

древнее до-шейдерное API рисования примитивов?

А ты думаешь, почему в винде запилили AERO? Чтобы красиво? Нет, чтобы композитор вместо примитивов. На переходе с XP на Windows 7 на слабык компах но с OpenGL карточкой было очень заметно: на XP окна мигают-лагают, на 7 прям целые двигаются. Естественно, на старых Matrox и Ati Mach64 под XP окошки были плавными, чёткими и быстрыми.

Я не понимаю, а зачем всё это? Чтобы что? Окошки со времён Windows 95 стали чем-то сильно отличаться? Ну да, кнопочки стали круглыми и больше размером, но как это на скорость или сложность отрисовки-то должно влиять? И как это делает интерфейсы лучше?

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Нет, во времена windows 95 один нестандартный специализированный компьютер их рисовал («windows accelerator»), а в новое время - совершенно другой относительно стандартный 3D accelerator

Shadow ★★★★★
()
Ответ на: комментарий от Shadow

Нет, во времена windows 95 один нестандартный специализированный компьютер их рисовал («windows accelerator»), а в новое время - совершенно другой относительно стандартный 3D accelerator

Окей, замени Windows 95 на Motif/Athena. Они рисовали на CPU 100% и при этом были быстрее чем GTK4.

hateyoufeel ★★★★★
()
Ответ на: комментарий от cumvillain

Они рисовали экран 1024x768 с dpi 96.

Ииии в чём проблема так же рисовать на экран 5120x2880? Я почему-то уверен, что даже в таком варианте целиком софтварный рендеринг интерфейса будет быстрее чем то что в GTK4.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Ииии в чём проблема так же рисовать на экран 5120x2880? Я почему-то уверен, что даже в таком варианте целиком софтварный рендеринг интерфейса будет быстрее чем то что в GTK4.

Рендеринг pdf почему-то софтварно получается очень не очень. Хотя хз, мб виноват конечно cairo иил что-то из этих.

cumvillain
()
Ответ на: комментарий от cumvillain

Ииии в чём проблема так же рисовать на экран 5120x2880? Я почему-то уверен, что даже в таком варианте целиком софтварный рендеринг интерфейса будет быстрее чем то что в GTK4.

Рендеринг pdf почему-то софтварно получается очень не очень. Хотя хз, мб виноват конечно cairo иил что-то из этих.

Знаешь, это безумие какое-то. Я тут ради лулзов Quake2 на 5к экране запустил с целиком софтварным рендерингом. Без vsync оно выдаёт сотни FPS, не особо нагружая мой проц при этом. Какого ж хрена буковки-то рисовать так сложно стало?

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Окей, замени Windows 95 на Motif/Athena. Они рисовали на CPU 100% и при этом были быстрее чем GTK4.

Нет, конечно.

Простое перетаскивание окна тогда делалось через рамку превью, и только когда пользователь отпускал кнопку окно перерисовывалось в новом месте.

khrundel ★★★★
()
Ответ на: комментарий от khrundel

Простое перетаскивание окна тогда делалось через рамку превью, и только когда пользователь отпускал кнопку окно перерисовывалось в новом месте.

В смысле? Делался скриншот окна и его таскали по экрану? Или рисовало пустую рамку и пользователь таскал её? Последнее — для Windows 95 неверно.

question4 ★★★★★
()
Последнее исправление: question4 (всего исправлений: 1)
Ответ на: комментарий от question4

В смысле? Делался скриншот окна и его таскали по экрану? Или рисовало пустую рамку и пользователь таскал её? Последнее — для Windows 95 неверно.

В смысле таскалась рамка. Просто границы прямоугольника. Таскать изображение, хотя бы даже скриншот - это было слишком дорого.

khrundel ★★★★
()
Ответ на: комментарий от question4

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

Reset ★★★★★
()
Ответ на: комментарий от Reset

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

Возможно, это зависело от сборки. Потому что я начинал видеть пустую рамку только после ковыряния в настройках.

question4 ★★★★★
()
Ответ на: комментарий от khrundel

Простое перетаскивание окна тогда делалось через рамку превью, и только когда пользователь отпускал кнопку окно перерисовывалось в новом месте.

При этом даже простых карт с поддержкой 2D-ускорения (не 3D!) хватало уже, чтобы с нормальной скоростью перетаскивать окно целиком без превью. А таких карт в 1995-м году уже полно было, наверное, любая PCI-карта уже была с 2D ускорением.

Сейчас блин без OpenGL с шейдерами уже не могут.

praseodim ★★★★★
()
Ответ на: комментарий от praseodim

При этом даже простых карт с поддержкой 2D-ускорения (не 3D!) хватало уже

Ну как бы так же можно сказать, что 486+VGA хватало для игры дум, а теперь вот киберпанк тормозит.

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

Когда появилось примитивное ускорение, мегабайты памяти и можно было через bitblt скопировать мгновенно таскаемое окно. Но перекрываемое окно при этом должно было перерисовываться, и если не успевало, за ним был шлейф. Теперь вот композитинг, ничего не портится, всё быстро и плавно летает и всяко красиво искажается, но требует видеокарту и рисует лишнее.

khrundel ★★★★
()
Ответ на: комментарий от khrundel

Ну как бы так же можно сказать, что 486+VGA хватало для игры дум, а теперь вот киберпанк тормозит.

Да если бы только киберпанк тормозил. Сраный калькулятор на GTK4 тормозит, причём независимо от железа. Без дёрганий окошко отрезайсить тоже нельзя.

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

Это всё круто, но была куча довольно сложных в плане графики игр, которые без проблем делали софтварный рендеринг. Ну я не знаю, Unreal/UT и прочие игры на их движке типа Deus Ex. Ты сейчас реально хочешь сказать, что интерфейсы на GTK4 сложнее и потому требуют больше ресурсов чем рендеринг жопы Дентона в DX?

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от hateyoufeel

Да если бы только киберпанк тормозил. Сраный калькулятор на GTK4 тормозит, причём независимо от железа. Без дёрганий окошко отрезайсить тоже нельзя.

Это никогда не работало ни в какой системе и никогда работать не будет. Если перетаскивание окна ещё можно реализовать без тормозов, то ресайз в рантайме будет дёргаться, скажи спасибо что не зависает вся система.

Вот, посмотри как это делалось в твоих хвалёных старых системах. Спойлер: никак. Если не делать ресайз и перетаскивание в рантайме то и дёргаться ничего не будет.

khrundel ★★★★
()
Ответ на: комментарий от khrundel

Что значит «дёргаться»?

При корректной логике кода приложения ничего не дёргается. Совсем куку что ли?

Это в говнокоде зачастую навалено костылей, когда при ресайзе размеры отдельных элементов окна пересчитываются в несколько приёмов с рендерингом между ними, что приводит к видимому дёрганию layout-а.

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

На старых железках (кто в МС Офис работал во времена 1-х Пентиумов и Win95, тот помнит) перерисовка окна при ресайзе или при появлении окна из-под другого окна вообще могла быть видима вся как в слоумо, особенно если в системе мало ОЗУ.

wandrien ★★
()
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от wandrien

Что значит «дёргаться»?

Спроси у @hateyoufeel, я цитировал его.

При корректной логике кода приложения ничего не дёргается. Совсем куку что ли?

Не груби людям на 2 головы умнее тебя. Запомни: ты - местный деревенский дурачок, будь благодарен тем, кто тратит время объясняя тебе простые вещи.

Если говорить конкретно о причинах, не зависящих от говнокода приложения, то видеть мы будем не дёргание, а мерцание окна,

Садись, 2.

Никакого мерцания быть не должно, а именно «дёргание».

Если UI-поток приложения не успевает отрисовывать растягиваемое окно с желаемым фпсом, то будет отображаться старый контент, изменение будет неплавным и выглядеть как дёрганная анимация. Сделать с этим ничего нельзя, так как DE понятия не имеет как корректно отресайзить картинку внутри окна. Можно, как в старых системах, отказаться от плавного ресайза, как в CDE, это будет гуманно к железу, либо показать как есть. В принципе, вариант из CDE был вполне приемлемым, но по мере развития железа предпочитали давать возможность видеть окно при перетаскивании, а потом и при ресайзе.

А вот «мерцание», т.е. когда окно успело нарисовать белую заливку, но не успело поверх вывести текст - это как раз косяк, который кстати, никак не связан с ресайзом, ничто не мешает окну мерцать и при простом обновлении содержимого, если недорисованное окно отображается пользователю - это проблемы графического сервера.

khrundel ★★★★
()
Ответ на: комментарий от Werenter

Безусловно. Чтоб ты понимал что тут происходит: 3 идиота (включая тебя) рассказывают сказки про «трава зеленее была», а умный человек им объясняет им что, во-первых, не была (с видеопруфами), а во вторых, что в принципе не могла быть зеленее, просто потому что задача принципиально неразрешима.

Забавно что ваши фантазии противоречат друг другу. Вон, один жалуется, что окошко, неспособное рисовать свой контент со скоростью 60 к/с, почему-то «дёргается», и что при Гейтсе такого не было, а второй надрачивает на «отрисовку в сломо», что ещё больший косяк рендеринга. В нормальной ситуации эти 2е должны сцепиться в клинче, ведь один клевещет на золотой век. Но так как обоим в принципе насрать на то как реально осуществлялся рендеринг окон и это для них просто повод показать седину своих яиц, никакого противоречия между собой они не видят и дружно жалуются на современные технологии.

khrundel ★★★★
()
Ответ на: комментарий от Werenter

Не хами. khrundel тебе все по-делу написал, а ты извиваешься, как малолетка. Учись работать над своими ошибками.

–седайко стюмчик

sedajko_stjumchik
()
Ответ на: комментарий от khrundel

Это никогда не работало ни в какой системе и никогда работать не будет. Если перетаскивание окна ещё можно реализовать без тормозов, то ресайз в рантайме будет дёргаться, скажи спасибо что не зависает вся система.

Отлично. 2024 год, программисты не могут окно без тормозов хотя бы в 60fps отресайзить.

Эту индустрию пора закапывать, ничего хорошего в ней нет.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

Я недавно хотел приложение на Java AWT сделать, я не знаю как они этого добились, но любые операции с окном тормозят, окно мерцает, ресайз работает с какой то задержкой. Если добавить контролы, то вообще начинается ад.

MOPKOBKA ★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 3)
Ответ на: комментарий от khrundel

https://youtu.be/U0GG5rHOP8g?t=136

Да вроде всегда работал ресайз, или на видео дерганье какое то присутствует?

На современном железе уж точно проблем не должно быть.

MOPKOBKA ★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

или на видео дерганье какое то присутствует

Присутствует, присмотрись.

quantum-troll ★★★★★
()
Ответ на: комментарий от Shadow

чтобы композитор вместо примитивов

Так поборники rdp считают что именно примитивы позволяют rdp быстро работать.

einhander ★★★★★
()
Ответ на: комментарий от einhander

Это немного разное, одно дело rdp, другое - хардверная буферизация и отрисовка примитивов, чтоб небыло тиринга и т.п.

Shadow ★★★★★
()
Ответ на: комментарий от Shadow

Да вот как бы оно связано, из гнома выкинули примитивы и теперь даже файловый менеджер тормозит если использовать сетевую прозрачность иксов, которая эти примитивы использует. В отличие от pcmanfm, который работает очень быстро, на том же не сильно быстром канале.

einhander ★★★★★
()
Ответ на: комментарий от Shadow

Попробуйте 8bit цвет использовать.

Внезапно, как?

einhander ★★★★★
()
Ответ на: комментарий от cumvillain

h264. Проверено на игрушках 4k@60.

Посчитай битрейт и сравни с типичным каналом интернет.

В какую реализацию vnc завезли h264? Год назад тестировал, jpeg-turbo из turbovnc оказался быстрее всех, кроме наверное kasm, но он не совместим с другими реализациями vnc.

einhander ★★★★★
()
Ответ на: комментарий от einhander

Я лично занес в IANA кодировку Open H.264, мы с товарищем описали формат и сделали эталонную реализацию сервера и клиентские патчи для TigerVNC (уже приняты).

Правда, есть проблемы с поддержкой.

  • Из клиентов это поддерживает только TigerVNC и еще пара клиентов для вяленого.
  • Из серверов - только PiKVM и опять же несколько вяленых.

Мейнстрим не очень спешит с внедрением, хотя по сравнению с JPEG буст по производительности и экономии трафика просто гигантский.

У TigerVNC есть небольшие проблемы с включением клиентской части H.264 по умолчанию, потому что они боятся лицензионных проблем. Оно включено в сборках для винды, например, потому что на винде используется встроенный в ОС декодер, а на маке надо линковаться с ffmpeg, чего разрабы не хотят (можно включить, но много ли маководов собирают сами софт?) На маке надо использовать MediaKit или как там его, но писать это некому сейчас.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от liksys

и клиентские патчи для TigerVNC

Большое спасибо!

Shadow ★★★★★
()
Ответ на: комментарий от einhander

Видимо, тоже из-за лицензионных вопросов. Я потом попробую аналогичную штуку сделать для VP8 или VP9, они полностью свободные.

liksys ★★★★
()
Ответ на: комментарий от liksys

Для vnc не хватает нормального менеджера сессий как сделано в xrdp, наколенные скрипты достали. А так будет огонь.

einhander ★★★★★
()
Ответ на: комментарий от liksys

я не понимаю почему вы обсуждаете эту саму-по-себе интересную тему в треде про xz, но раз уж вы всё равно обсуждаете…

а планов по AV1 нету? аппаратная поддержка как энкода, так и декода становится +- попсовой в железе, поэтому было бы клёво её иметь.

ещё вопрос в воздух: как у RFB с инпутом вне клавомыши (гейм контроллеры, джостики, вот это вот всё)

Stil ★★★★★
()
Ответ на: комментарий от Stil

AV1 в железе есть только у относительно новых устройств, в отличие от h264, поддержка которого в железе появилась лет 15 назад.

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

einhander ★★★★★
()
Последнее исправление: einhander (всего исправлений: 1)
Ответ на: комментарий от einhander

AV1 в железе есть только у относительно новых устройств

Я бы сказал не относительно новых, а очень новых.

Werenter ★★★
()
Ответ на: комментарий от Werenter

Я бы сказал не относительно новых, а очень новых.

«очень новые» это релиз 3 года назад (rdna2, series30, xe), если что. и я бы не ожидал, что вся бюрократия и реализация займут меньше ещё пары лет.

Stil ★★★★★
()
Ответ на: комментарий от liksys

Turbovnc видел на видео, сам не пробовал, и kasm пробовал сам. Вибрацию не помню, не проверял. Для игорь я переключился на sunshine, там и звук и вибрация присутствует, нет только мультипользователя, по сути аналог rustdesk.

einhander ★★★★★
()
Ответ на: комментарий от Stil

а планов по AV1 нету? аппаратная поддержка как энкода, так и декода становится +- попсовой в железе, поэтому было бы клёво её иметь.

Не, нету. Я вообще все это делаю в рамках PiKVM, поэтому работаю в том направлении, где есть подходящие для малины кодеки.

как у RFB с инпутом вне клавомыши (гейм контроллеры, джостики, вот это вот всё)

Вот тут есть какое-то расширение, но не факт, что найдутся клиенты, которые это поддерживают.

На самом деле, RFB это натуральный мезозойский ужоснах и набор костылей, стоящих друг на друге. Это я заявляю, как человек, написавший с нуля свой собственный RFB-сервер :D Базовая работа с инпутами устроена очень примитивно - в виде X11-сканкеев, что исключает возможность работы с клавиатурой напрямую, для этого есть QEMU-расширения для передачи физических кнопок. Чтобы качественно поддерживать именно геймпады со всеми их фичами, нужно по-хорошему делать специальное расширение для них. Я бы сделал что-нибудь типа generic usb hid messages, чтобы прокидывать все хиды в общим виде.

liksys ★★★★
()
Ответ на: комментарий от liksys

Учитывая что даже ляптоп у меня может 90, это все пора на свалку. Достаточный gpu есть даже на rpi. Единственное где все эти жопеги действительно нужно это встройка всякая типа ipmi.

cumvillain
()
Ответ на: комментарий от cumvillain

Передача звука есть в xrdp, rustdesk, steamlink, sunshine. Последний вполне можно использовать как удаленный доступ для нескольких пользователей, если бы кто-нибудь допилил захват мыши и клавы для разных пользователей.

einhander ★★★★★
()
Ответ на: комментарий от cumvillain

Только это клиент, серверной части с h264 под онтопик нету.

einhander ★★★★★
()
Ответ на: комментарий от einhander

Я планирую сделать RFC на звук с Opus для VNC в этом или следующем году. Надо разгрести эти авгиевы конюшни уже наконец, а то из звуковых форматов там только PCM, лол.

liksys ★★★★
()
Ответ на: комментарий от liksys

Реально было очень круто, а то действительно у vnc с развитием как то не очень.

einhander ★★★★★
()
Ответ на: комментарий от cumvillain

Достаточный для чего именно? На малине до четвертой включительно H.264 не может кодировать больше 1080p. На пятой вообще нет аппаратного енкодера, предлагается молотить всё процессором.

liksys ★★★★
()
Ответ на: комментарий от Shadow

Тоже тормозит, но не требует настройки.

Для продакшена остановился на связке guacamole+ldap+xrdp+virtualgl. Если внутри сетки, то guacamole не используется.

einhander ★★★★★
()
Ответ на: комментарий от firkax

Не отмазывайся

ты не обосновал

Бггг што. Насрать, говорю, на тебя, иди погуляй. Или обоснуй мне сперва «устаревшую парадигму апача», я третий год жду.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 4)
Ответ на: комментарий от firkax

Хорошо, но не сразу. Вот когда лично ты покажешь пример, завалив навсегда хлебало в тредах про апач, иннодб и пхп - тогда я подумаю.

thesis ★★★★★
()
Ответ на: комментарий от firkax

Не переводи тему.

Я не перевожу, на тебя по-прежнему всем насрать.

thesis ★★★★★
()
Ответ на: комментарий от Somebody

Отучаемся говорить за всех

Ни за что.

thesis ★★★★★
()
Ответ на: комментарий от Skullnet

Теперь можно будет сказать, что GitHub без авторизации по паспорту, это слишком угрожающе, сегодня бекдор, а завтра ваши дети, поэтому к авторизации по смс, добавится еще что нибудь интересное...

MOPKOBKA ★★★★
()
Ответ на: комментарий от Skullnet

Ну да, ну да, Andres Freund где работает? Все сходится! --sarcasm

t184256 ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.