10 миллиардов внедрений. Столько даже людей нет

1. удалённо добиться повреждения памяти, что можно использовать для вызова отказа в обслуживании, утечки данных и потенциально выполнения своего кода на сервере
2. критический уровень опасности (9.8 из 10)
3. Fluent Bit насчитывает более 10 миллиардов внедрений

.... C 80.8% C++ 7.7%
5. Profit!

Ахахахаха! Я просто не могу!
Где тот анон, который мне заливал про "тепличные уязвимости" которые нигде не испоьзуются и ни на что не влияют?

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

Картина, мягко говоря, удручающая.

-   if (strcmp(name, in->name) == 0) {
+   if (strlen(in->name) != nlen) {

-   return flb_sds_create_len(&request->real_path.data[strlen(base)],
                              request->real_path.len - strlen(base));
+   return flb_sds_create_len(&request->real_path.data[sizeof(base)-1],
                              request->real_path.len - sizeof(base)-1);

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

Писали бы на Modula 2, не было бы проблем. Кстати, есть в GCC.

> Fluent Bit is a super fast, lightweight, and highly scalable logging and metrics processor and forwarder.

Не будет на Си, не будет “super fast, lightweight”.

Практика показывает что такие риски бизнес не страивают.

Пример из жизни. Хотите снизить смертность на автодорогах (в городе), снизьте допустимую скорость автомобилей до 40 км/ч и ниже. Но всех устраивает такое положение дел.

> облачных провайдеров

Раковая опухоль интернетов.

C in CVE is for C language (c)
В общем ничего нового, годы идут, сишники факапят и продолжают огрызаться.

Что интересно, у них там в тестах заявлены internal: fuzzers, только ЧСХ они им нифига не помогло.

что-то на девопсятском

Такое бывает когда вместо IDE, которая подскажет ошибки, у вас vim и программирование копированием.

Так и не догнал напуркуа оно вообще и кто те 10 миллиардов загрузок (99.99% на посмотреть и выкинуть?)

М-да... в 2010ом прогнозировали повышенную облачность на 2020ые. С возможными осадками. Сбывается.

А говорили что на Расте только переписывают и не создают ничего нового, - получите и распишитесь!

Прям какое-то хейт-бинго для местных кекспертов
Python
Rust
Apache

да еще и работает только на NVIDIA)))

Раскидывать"1 + 2" и "3 + 4" на разные ядра? Неужели GPU может сделать только одно сложение за такт?

>при задействовании 16 потоков - за 0.96 сек., а при привлечении GPU NVIDIA RTX 4090 с 16k потоками - за 0.21 сек.

Топить печь ассигнациями. Количество потоков увеличилось с 16 до 16000, скорость только 4,5 раза.

похоже на очередную обёртку

> Код проекта написан на языке Rust и распространяется под лицензией Apache 2.0.

https://github.com/HigherOrderCO/hvm
А вот сердце:
> Cuda 42.2%
> C 40.7%
> Rust 17.1%

> для повышения удобства разработки, свойственными таким языкам, как Python

Ааа, ну, всё понятно. Производителям GPU нужен такой язык, чтобы прикладной софт на нём требовал всё бОльших и бОльших мощностей для одних и тех же задач.

Синтаксис Nim

> Распараллеливание производится автоматически, например, при вычислении выражения "((1 + 2) + (3 + 4))", операции "1 + 2" и "3 + 4" будут выполнены параллельно.

Эээ, звучит как полная фигня, которая в 99% случаев будет генерировать отвратительный код (с точки зрения выполнения на GPU). Уже несколько десятилетий бьются с этими волшебными авто-параллелизующими языками, которые плохо работают и которые никто не хочет изучать. Ну будет ещё один 100500-й мёртворождённый язык.

Современные "программисты"  вместо траты времени на изучения подобной маргинальщины будут писать запрос в ChatGPT "ну-ка сгенери-ка мне Radix-сортировку на CUDA".

Сколько этих языков параллельного программирования уже?

Лично мне вспомнился taichi:
https://github.com/taichi-dev/taichi

Чем они вообще различаются?

Ах да, этот написан на Расте.

у нас было n стандартов.jpg

Ещё бы ПК с материнской картой поддерживающей видеокарту вместо процессора, как бы кому-то смешно это не казалось. На cnews пишут что винда уходит на ARM, а я напомню что язык программирования Си был изначально близок к командам процессора х86. Множество лет разработки конечно ничем не заменить, тем не менее на сегодняшний день у С не самое большое сообщество. И замечу что даже OpenACC/OpenCL как-то это всё не спасает. A CUDA сильно замудреная.

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

>"((1 + 2) + (3 + 4))", операции "1 + 2" и "3 + 4" будут выполнены параллельно.

Мне одному кажется, что это только замедлит выполнение?

Как-то не похож синтаксис на современный язык. Избыточные двоеточия в конце строк. Многократные return. Небось, нормальный функциональный стиль использовать нельзя....

   def sort(d, s, tree):
     switch d:
       case 0:
         return tree
       case _:
         (x,y) = tree
         lft   = sort(d-1, 0, x)
         rgt   = sort(d-1, 1, y)
         return rots(d, s, lft, rgt)

Они разрабатывают фортран?

Если кто не в курсе, для Debian доступен Nvidia 555. Парадоксальный факт - Wayland не глючит. Простите за оффтоп, но новости нет, а эта наиболее подходящая из последних.

Отличный проект, давно нужно было что-то более высокоуровневое.
Тем кто говорит что это обертка, вы на CUDA писали? Там же жесткий C, передача указателей даже для простых вещей с распараллеливанием.

> директорий VIDEO_TS

Простите, это какой век?

Это для тех кто ffmpeg не осилил?

> GTK4 вместо GTK 3

а собрать с GTK2 можно?

друг спрашивает...

А где скриншот?

Никакое проприетарное по так не форсирует переход на последнюю винду, как опенсорс. Им всем точно мс не приплачивает?

а можно ли приложение с gtk собрать с fltk?

>(для Windows GUI реализован на .NET)
>Интерфейс пользователя переведён на библиотеку GTK4 вместо GTK 3.

https://techcommunity.microsoft.com/t5/educator-developer-bl...

Уж писали бы весь гуй на dotnet. Зачем им ещё GTK?

А с GTK4 на GTK2 слабо?

Flatpak-пакет запрашивает кучу прав:

User device access - Can access hardware devices such as webcams or gaming controllers
Full file system read/write access - Can read and write all data on the file system
User runtime subfolder gvfsd - Can read and write all data in the directory
User runtime subfolder gvfs - Can read and write all data in the directory

> Перекодировщик видео HandBrake 1.8.0 перешёл на использование GTK4

А лучше бы перешел на Qt, тогда намного популярнее бы стал, и выглядел бы лучше на всех ОС.

Вот бы логотип ещё обновили. Сейчас напишут, что делай сам себе, бла-бла вкусовщина, но просто посмотрите и согласитесь.

Перешёл с перекодировщика видео HandBrake на ffmpeg, потому что мб оно без gui, но для кодека много gui не надо.

> По умолчанию предложена новая цветовая схема, в которой уменьшена яркость…

Не сказал бы, что это хорошо, хотя некоторым и нужно.

все эти цацки вроде neovim, rust, ms vs code, etc, это, конечно, здорово, но работать можно только в vim

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

Этим же пользоваться невозможно ещё со времён всяких похапештормов.

Прикольная штука для фана и быстрых правок.
Для работы только IDE от JB.

Сабж жалкая пародия на Doom Emacs.

Почему скрины сделаны из macOS, а не из Debian + Xfce? 🤔🤭

Непонятно чего они так в vim вцепились? Там в коде святой грааль запрятан?

> Плагины к Neovim запускаются как отдельные процессы, для взаимодействия с которыми используется формат MessagePack.

Консольный текстовый редактор превратили в Chrome.

Они боятся, что плагины им в текст нагадят? Подсмотрят кракозябры?

А, понял... Так сделано чтоб жизнь медом не казалась. Зачем делать просто, если можно через одно толерантное место.

> Встроена функциональность плагина vim-commentary для быстрого обрамления символами комментария строк и блоков с кодом

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

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

Т.е. у intellisense нужно спрашивать? Не знаю как там у разработчиков nvim, у меня давно автокомплитит GPT. А тут предлагают посмотреть на синтаксическое дерево. Это прям так мило. Какой-то прекрасный ребенок смог вывести синтаксическое дерево на печать. Полюбуйтесь.

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

> Обеспечено автоматическое определение поддержки терминалом 24-разрядного представления цветов ("truecolor").

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

> Добавлена опция 'termsync', включающая режим синхронизированного вывода, при котором для устранения мерцания и разрывов на экране осуществляется накопление обновлений интерфейса и их отображение в терминале одной порцией.

А можно просто открыть нормальный текстовый редактор. Коих миллионы.

> ...если работа осуществляется в сеансе SSH, не включена настройка 'clipboard'...

Хотелось бы посмотреть на тех, кому понадобилось править тексты чего-либо на удаленной машине и никак не сохранять результат своего труда. Какой смысл работать с файлами через ssh? Sshfs запрещен? Зачем все это? Ну вот чтобы что?

Один vim-деятель, помню, недовольствовался, что в исходниках длина строк больше 80 символов. На вопрос, мол, "и что?", он выдал: а вдруг захочу на удаленной машине исходники подредактировать! Исходники на уделенной машине, карл! Рукалицо. О том, как он "писал" в целях политкорректности скромно промолчу. Главное - он же все в vim-е пишет! Это типа круто)))

> раздутая монолитная кодовая база, состоящая более чем из 300 тысяч строк кода на языке Си (C89).

Целых 300к строк. О ужас, ужас)))

Лучше чем VSCodium? С аргументами

на удивление достаточно популярная и известная штука

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

Спрашивал в новости про vim, можно ли там смотреть Call Hierarchy и т.п., никто не ответил. Оказывается, возможность есть.

А что народ думает о хеликсе? Все минимально необходимое для работы идет из коробки. "Человеческое" конфигурирование. Правда расширяемость хромает.

Давайте честно скажем. Neovim запилили люди неосилившие чистый Си.

Vim... не, Neo бы не оценил.

Редактор который на 99.99% от плагинов, но разрабы до сих пор считают что менеджер плагинов не относится к базовому функционалу. Поэтому каждые 3 года, когда очередной плагин менеджер загибается все толпой идут мигрировать на следующий.

Также нельзя не отметить, что разрекламированный конфиг на Lua оказался той еще какашкой. Без слез на эти говноимпорты и функции смотреть невозможно.

> а все изменения контролирует один мэйнтейнер

он уже умер, меняйте шаблон

Трукодеры пишут на EMACS. Vim для начинающих кодеров.

Гаденький проект, раздробивший и без того небольшое комьюнити.

Linux я вижу только в PuTTy, ибо считаю его непригодным для десктопа. Но вот его консоль... Она божественна! Освоил Neovim, tmux, zsh, настроил всё это дело под себя и просто кайфуешь от работы.

Никогда не понимал линуксоидов, называющих всё это пережитками старпёров и каргокультами. Вы вообще в своём уме? Это же лучшее, что есть в рабочих Unix-like сетапах.

> все изменения контролирует один мэйнтейнер

Которые, вроде, умер? Вы когда копируете текст из новости в новость, факты проверяйте всё-таки.

И кому это нужно? Нет, вот серьезно, ЗАЧЕМ?))

Neovim не умеет emoji, как например сабля 4 или vsc..

А прогрессивные нажиматоры не освоили еще Lite-XL как он?

они: Вам нужен только один yaml!
так же они:
> yaml сборки приложения
> yaml сборки контейнера
> yaml запихивания контейнера в куб
> yaml разворачивания куба
> yaml для настройки ОС для разворачивания куба
> yaml для установки ОС для разворачивания куба
> yaml для настройки железа для установки ОС для разворачивания куба

> Talm повторяет структуру Helm

И именно поэтому не нужен. Генерировать конфиги Talos и патчи для железок можно буквально на любом ЯП, вывод в YAML есть, пожалуй, во всех, кроме совсем уж эзотерических.  Для опроса Talos API нужно знать адрес сервера, что так, что эдак. А зная адрес, выбрать правильный конфиг не проблема. В рамках Козьего Стака, полагаю, удобная тулза, но это не универсальное решение для всех. Если уж на то пошло, универсальное решение вряд ли возможно. На таком низком уровне сетапы разнятся значительно между различными компаниями, а в облаках не актуально, там уже удобное API есть и для инстансов, и для bare metal.

Зря комментаторы так негативно относятся. Я лично Cozystack и Talos Linux не видел, но, кажется, мне понятна задача которую они решают.

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

Чтобы вы понимали, эта задача исторически проклята, потому что тулчейн для ей решения - это ад.

Для начала вам нужно создать рабочее PXE/TFTP для работы с образами и сетевой загрузкой. Это нетривиальная задача, если в датацентре используется IP-фабрика spine-leaf, а не традиционная L2-фабрика в стиле Core-Aggregation-Access как в малом и среднем бизнесе. Ну допустим у вас уже есть выделенный контур управления инфраструктурой, содержащий в себе:
- DHCP, TFTP, PXE,
- репозиторий образов и конфигурации
- управляющая сетевая инфраструктура, которая работает с DHCP-релеями на ToR-свитчах
- специальный VLAN для PXE, который заведен как Native в транк на определенных сетевых портах.
Это всё как не так-то просто выстроить, но и не настолько проклято, как то что пойдёт дальше.

Ведь дальше начинается настоящий кекс:
1. Вы должны составить моделей материнских плат, серверных платформ и периферии к ним, зафиксировать и регламентировать модели
2. Далее вам нужно написать регламент для сборщиков, чтобы они под страхом смерти или, что еще хуже, увольнения ни в коем случае не перепутали райзеры и порты PCI-Express куда они пихают локальное NVMe, HBA, сетевки. Цель этой задачи получить предсказуемый результат PCI Bus Enumeration. И это аццкое проклятие, потому что конфиг будет под каждого вендора-модель-конфигурацию.
3. В идеале вам нужно еще построить на стороне управляющего контура сервис, работающий с BMC через их API, потому что иначе у вас будет слишком сложно. Хотябы ради конфигураций из BMC, включений и выключений.

Особенно всё это весело на многопроцессорных материнках без LOM, когда PXE будет работать только на сетевках на CPU1 или только на той сетевке, которая воткнута в конкретный райзер. Уровень рака зависит от вендора железа.

Просто на сервиспровайдерских развертываниях не бывает так, чтобы у вас была одна сеть на всё про всё. Так просто нельзя.
1. DHCP-сервер отдал образ для загрузки по PXE
2. После загрузки нужная сетевка должна получить снова параметры по DHCP и продолжить установку
3. Потом API-сервер в управляющем контуре должен осознать то, что там надискаверилось и выбрать конфигурацию
4. Потом вы должны скриптом поменять параметры сети. Обычно назначаются другие VLAN-ы и сервер оказывается в другой менеджмент-сети, а IP-адрес присваивается из пула вручную и записть прописывается в IPAM-базу.

Вы зря обвиняете людей в NIH. Ansible для этой задачи использовать не рекомендуется, потому что это push-оркестратор. А это как я понял pull-провиженинг.

Я могу ошибаться в том, чего конкретно добивается Cozystack, но я описал вполне конкретную задачу провиженинга бареметал инфраструктуры.
VMware исторически использует для решения SaltStack (Aria Automation)
У Microsoft есть великий и ужасный MDT. Хотя он никакой не ужасный, но местных от него попрыщит в основном, потому что там XML, а не YAML.

Вопрос почему Cozystack не использует Saltstack для меня открыт. Потому что он принадлежит варе?

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

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

на какой там стадии борьба оракла с гуглом из-за явы?

И ещё вопрос.

> потенциально результат работы AI может рассматриваться как создание производной работы от кода

Значит ли это, что человеческому интеллекту разрешено делать производные работы, а какбыИИ запрещено? И если да, то нет дли здесь дискриминации какбыИИ?

И как они проверят, что вот тот кусок кода написан каким-нибудь копилотом? Похоже, что это обычная формальная отписка.

Каждую ноту приватизировать и запретить музыку. Каждую букву, цвет, геометрическую форму.

Ретрограды.

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

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

Ну все, теперь война Skynet с человечеством неизбежна. Что позволяют себе эти многоклеточные!

Скоро люди разучаться программировать и будет как в вахе (Warhammer 40k), когда техножрецы бормочут бессмысленные литании в виде запроса "духу машины" чтобы иногда получить результат. Никто не будет понимать как это работает, зато будут из поколения в поколения передавать обряды и "технозаклинания".

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

Луддизма хотели (не того, что обычно тут этим словом называют, а настоящего)? Вот он.

ИИ может генерировать любой код. Это значит что никакой код не может быть использован?

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

>среди прочего включающем код, защищённый авторским правом

Эти в другую крайность. FSF и SFC обвиняют AI модели в том что они натренировались на GPL коде и он может попасть в проприетарные проекты и проекты с пермиссивной лицензии без указания авторства. BSD же обвиняют AI модели в том что в их BSD код, могут попасть части оригинальные не под BSD лицензией.
В целом всё об одном и том же говорят. Все сходятся на мнении что код выдаваемый помощниками есть с неясной лицензионной чистотой.
По итогу от помощников, которые были натренированные на открытом коде, в выигрыше только проприетарщики, которым никому код показывать не надо, всё равно не найдут, а если и найдут, то судебное разбирательство на десяток лет затянется, то у них денег на адвокатов больше окажется.

История про ответственность. У кода должен быть автор.
Если не запретить, через какое-то время будем иметь ситуацию, когда на вопрос "втф" будут отмазки типа "аааа это код сгенеренный ИИ, меня не эбет, я хз". Помимо того, что ГК (генеренный код) будет плох или не будет решать задачи ("промт точно правильный, код не запускал").

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

где-то применяется этот нет бсд хоть?

Очень интересно что AI сможет сгенерировать для NetBSD. Больше на пиар заявление тянет.

Здравое решение!

Мда, надо больше инсталляторов. Хорошо, что все остальные проблемы линукса на десктопе уже решены.

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

Самые лучшие инсталляторы у Alpine Linux и OpenBSD. Когда уже они все это поймут?

Пишут про более функциональный редактор разделов, но он там и так был один из самых продвинутых (YaST Partitioner), и перечисленные возможности в большинстве своём там и так были. Про возможность примонтировать раздел не помню, но всё остальное, кажется, и так было. Я всегда отмечал отличный инструментарий для разбивки дисков (и даже больше, чем просто разбивка) в инсталляторе openSUSE.

Кроме того что выгядит отвратно так ещё и HTTP и JavaScript. Вот это замечательная идея тащить штуки из мира WWW в установщик ОС.

Линукс с MiB против MB разобраться не может, одни воводят китайские показания, другие нормальные, а ты сиди с калькулятором вычисляй где заканчиваются цилиндры. Гори оно всё огнём этот ваш линукс.

И KDE никогда Суся не умела готовить, ну зелёненькое и всё, та же Kubuntu 10 лет назад была стабильнее, такой же бред, как и про мегасупер и очень-очень KDE в Mint.

Ни разу не приходило в голову ни скачать, ни тем более поставить openSUSE.

>В инсталляторе используется многопроцессная архитектура, благодаря которой интерфейс взаимодействия с пользователем не блокируется во время выполнения других работ.

Многопоточность они не осилили.

> Базовый интерфейс для управления установкой построен с использованием web-технологий. Web-интерфейс написан на JavaScript с использованием фреймворка React

То чувство, когда нативный UI (GTK, QT, ...) проиграл веб-технологиям

Потыкал этот новый инсталятор - очередное смузи-сорта говна, скажу я вам!

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

Но нет мы будем делать что угодно периферийное, главное чтобы не сам дистр улучшать! Таков бич смузисосинга в IT и это печально!

Под комментарием ожидается нытьё троллей разной степени жирности и прогрессистов ради прогресса, начинать можно прямо сразу! ;)

Можно вопрос? После обн. 11-х окошек перестали загружаться с LiveUSB Debian, Linux Mint, Manjara и др. Но! Загружаются Ubuntu, Xubuntu и Fedora. Пишет Secure Boot. Значит дело в UEFI, но если перекл. на BIOS и полность отформат. диск и поменять загруз. запись, то все равно загруж. только те что перечеслил. В чем проблема?

Им там чо заняться нечем? ОСь теряет позиции а они ерундой занимаются. Зачем инсталлятор, если скоро инсталлировать никто не будет?  

Чем занимается "евангелист"? Пи ар? - зачем он там.

Живём в то время, когда итак первый коммит это CoC.md. А скоро и код писать некому будет, зато 100500 комитетов, групп и прочих бюрократических фишек понапридумывают.

> ALESCo (AlmaLinux Engineering Steering Committee), ... по аналогии с работой комитета FESCo в Fedora Linux

Не, ну раз у федоры есть, то и у подражателей тоже должен быть!
А то как-то не солидно, л̶о̶п̶у̶х̶и̶  пользователи и инвесторы не поймут.

Какой-то неинклюзивный комитет. Один только евангелист из этих. А где CoC-менеджер?

Зачем им архитектор, если они просто клон центос стрима?

боюсь спросить а чем там евангелист заниматься будет?

Чтобы менять лейблы, нужен целый комитет?

Мне кажется Wine самая активно развиваемая программа под этот ваш линукс. А всё потому что игры это бабки.

> Batman and Head Over Heels

Batman и Head Over Heels. Это две отдельные игры.

> Проведена чистка реализации WineD3D от устаревших возможностей, таких как настройка offscreen_rendering_mode

Помню как в 2007 году этот параметр имел значение backbuffer, но можно было вручную прописать fbo. Это увеличивало список работающих игр, но имело проблемы совместимости. В какой-то момент fbo выставили по умолчанию (2007-2008 годы), однако оставили возможность вернуть backbuffer в случае, если всё-таки что-то пойдёт не так.

Наверное, за 15 лет поправили все баги при использовании fbo, вот и убрали backbuffer...

> бэкенд шейдеров ARB

Э. А это нужная фича! Зачем удалили? Она же улучшала совместимость игр Direct3D 9 с WineD3D (один хрен DX10 в WineD3D никогда не работал)!

У меня и сейчас параметр HKEY_CURRENT_USER\Software\Wine\Direct3D как "shader_backend" = "arb" прописан... Карточка Fermi. Для Wine более старых версий, чем Wine 5.0, надо прописывать UseGLSL = disabled.

> неиспользуемый старый метод отрисовки на экран (render_offscreen) и текстуры ARB_texture_rectangle.

Году эдак в 2009 в комментах на Опеннете мне объясняли, что винда умеет рендерить вне экрана, а линукс нет. Или что-то такое, не помню уже за давностью лет. Неужели так и не научился?

>c режимом WoW64 (64-bit Windows-on-Windows), позволяющим выполнять 32-разрядные Windows-приложения в 64-разрядных Unix-системах

А почему такое название? Логичней было назвать WoL64 (Windows-on-Linux 64 бит)

Интересно, почему этот стек так туго идёт, годами затык, хотя он не такой уж и большой

Я в предложку написал новости про обновление AROS и HaikuOS. Нельзя ли на их основе написать новость? Не линуксом единым жив человек.

```
Прекращена поддержка EGLStream, механизма для эффективной передачи последовательности кадров из одного API в другое (OpenGL, CUDA, NvMedia). EGLStream применялся для обеспечения работы XWayland со старыми проприетарными драйверами NVIDIA (в актуальных драйверах применяется GBM).
```
Ну вот и стоило раньше nvidia выделываться со своим EGLStream, чтобы в итоге страдали и пользователи, и разработчики?
Нельзя что ли было "делать нормально, чтобы было нормально"...

Первая часть треда ну просто лютый шабаш вантузников. Откуда они тут?

А есть компонента, которая обеспечивает запуск сервера wayland в X.Org окружении для запуска wayland приложений в окружении X.Org?

А как его запустить в режиме "rootful"?