Когда графику наконец перенесут в ядро?

к идее всунуть графический сервер/композитор в ядро относятся отрицательно?

потому что:

• нечего впихивать т.к. работающий графический сервер, который поднимали с колен больше 20 лет (Xorg) - заброшен и не развивается (банальное отсутствие mixeddpi и fractionaldpi в 2020 это проблема) а не заброшенный графический сервер (вяленый) не работает (с кучей приложений и в целом находится в стадии «глючное фуфло»)
• идея запихивать графику в ядро оси, которая до сих пор не готова для нормального десктопа (банально не имея вменяемый графический сервер) - довольно посредственная

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

иксы тормозят не из-за переключений контекстов, лол, и в последних виндах графика уже не в ядре

Тут ребята китайские пробовали сделать свой ip стек вне ядра и переключений контекста и он там у них заработал значительно быстрее. Но графика то чтобы попасть в ядро должна быть написана на Си. Она должна быть легкой и простой. Она не должна быть Rio, потому что Plan9 с ней не взлетел. Собственно в Paln9 это все сделали, но вот желающих не было взять код gpl2 и всунуть его в ядро линукс от plan9 как это произошло с utf-8, procfs.

иксы тормозят не из-за переключений контекстов

А из-за чего?

и в последних виндах графика уже не в ядре

Не полностью https://docs.microsoft.com/en-us/windows-hardware/drivers/display/images/dx10arch.png

Кста, а кто-то в курсе что там с вяленым сейчас?

dx10 устарел уже давно. dx12 сейчас используют.

Но графика то чтобы попасть в ядро должна быть написана на Си. Она должна быть легкой и простой.

Писателей драйверов ФС Си не останавливает. А драйверы ФС бывают весьма непростые, типа btrfs и ZFS.

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

Штатно работает в GNOME и wlroots-композиторах, в следующем выпуске KDE сильно улучшили стабильность Wayland-сессии.

Пользоваться можно.

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

dx10 устарел уже давно. dx12 сейчас используют.

А архитектура драйверов осталась та же: часть в user-space, часть в kernel-space.

В общем да. Но Xorg это операционная система сбоку. Тем не менее он потребляет ресурсов меньше якобы просто протокола wayland. Там еще нужно будет wlroots и прочую фигню заодно тащить, и не факт, что будет работать лучше в ядре, отрисовывая пространство пользователя. Просто вейланд иногда вылетает или например не грузится нормально после перехода в другую консоль и показывает какое-то марево. ZFS поглощает память как не в себя. А теперь представим роутер с такой вот приблудой жрущей 500 мегабайт стоя на месте. Может эта мысль неспособна поместиться в голове Линуса или он не хочет делать аналог Plan9 изобретенный на заре появления линукса.

Некие ребята пробовали сделать NFS-сервер в юзерспейсе на джаве. И он работал быстрее ядерного на C. (Справедливости ради, ядерный подтянули после этого по производительности).

Почему многие плюются от микроядер, говорят, что FUSE — это игрушка и реальные ФС должны быть в ядре, но при этом к идее всунуть графический сервер/композитор в ядро относятся отрицательно?

Плюются, ибо работа с ФС является критической, в отличие от «иксов». Относятся отрицательно потому, что:

а) уже такое было. Называлось Windows NT 4.0, и вся линейка «оффтопиков» 90-х и начала 00-х слыла своей «стабильностью», если вы понимаете, о чём я. Прикол про «переустанови шындоуз», кстати, пошёл именно из тех времён.

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

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

Почему многие плюются от микроядер

но при этом к идее всунуть графический сервер/композитор в ядро относятся отрицательно?

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

графика заметно тормозит, что порождает темы вроде Windows работает плавнее и четче

Дык точно такая же схема и в «оффтопике» – часть в ядре, часть в «юзерспэйсе». Это проблема конкретной реализации (Fedora).

Супер, кеды не падают?

уже такое было. Называлось Windows NT 4.0, и вся линейка «оффтопиков» 90-х и начала 00-х слыла своей «стабильностью», если вы понимаете, о чём я. Прикол про «переустанови шындоуз», кстати, пошёл именно из тех времён.

Виндус деградировал со временем именно из-за графики в ядре?

это ненадёжно. Ибо, во-первых, если навернётся граф. подсистема, а она навернётся, то упадёт и ядро. А во-вторых, на серверах принято делать аппараты более надёжными … Ну и «графику» к серверу никто в здравом уме не будет прикручивать, ресурсы под другие вещи нужны.

А как ядерная графика на это повлияет? Сейчас ты не запускаешь Xorg на сервере, с ядерной графикой не будешь подгружать модули DRM и композитора в ядро.

если залезут в «графику», залезут в ядро.

Каким образом?

Они и сейчас не падают, даже на «вяленом». Просто недоделаны, обещают доделать в 5.20.

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

куча переключений контекста, поэтому графика заметно тормозит

Пруф или не было.

Ты это профайлил?

И да, если хочешь кусок винды — directx12 будет в линуксах (в wsl2), но мелкософт хочет, чтобы это было деталью имплементации и весь софт будет юзать openngl to directx.

обещают доделать в 5.20.

Ну ладно, уговорил, попробуем =)

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

Что значит «когда начнут»? Когда появится заинтересованные индивид или организация, тогда и начнут. Как обычно это будет какой-то отдельный набор патчей или форк репозитория. Большинство пользователей будут пользоваться дефолтом. Громкая часть меньшинства будет кричать «ненужно». Всё как обычно.

но при этом к идее всунуть графический сервер/композитор в ядро относятся отрицательно?

Так не смотри на других — бери и «всовывай» графический сервер/композитор в ядро.
Линус ни у кого разрешения не спрашивал когда писал своё ядро.

В общем да. Но Xorg это операционная система сбоку. Тем не менее он потребляет ресурсов меньше якобы

«якобы» на старых ослонах/дюронах и 128 мб оперативки у меня он летал.
причём, ещё старый Xorg.
устроим кислотный тест?

жрущей 500 мегабайт

сцуко, зовите санитаров с формалином, пациент уже отходит, нужно срочно это ускорить!

Ты опять картинкой задницей разглядываешь?

В ядре драйвер вывода, менеджер памяти и планировщик. GDI целиком и полностью в юзерленде.

Виндус деградировал со временем именно из-за графики в ядре?

Он деградировал из-за индусов во главе M$, которым приспичило стать лордами Телеметрии. «Эффективные менеджеры» и мерзкие маркетологи тоже сыграли свою роль.

А как ядерная графика на это повлияет? Сейчас ты не запускаешь Xorg на сервере, с ядерной графикой не будешь подгружать модули DRM и композитора в ядро.

А, в смысле запихнуть «графику» в ядро? Ну это ещё куда ни шло, при условии сохранения отдельной подсистемы в качестве резервной.

Каким образом?

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

Ты видимо наискосок прочитал. Памяти жрет вейланд больше. Иксы и правда намного менее жрущие. И да попробуй включи кеш в память на zfs и она сожрет и поболее. 500 мегабайт это дистр с легким рабочим столом на zfs без кеширования в оперативную память.

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

Если все всё понимают, почему Hurd по-прежнему пилят полтора лесоруба? Проект вроде бы и живой, но в режиме зомби. Его бы и осилили и допилили заодно…

Виндус деградировал со временем именно из-за графики в ядре?

В том числе. Гуглить «ресурсы windows»

Он деградировал из-за индусов во главе M$, которым приспичило стать лордами Телеметрии.

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

каждая программа должна уметь

это решается библиотеками. так что ты чё-то не то выдумываешь

Когда графику

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

Владимир

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

Причём здесь какие-то доступы, не понятно.

А кому он нужен, когда есть готовое рабочее ядро? И, опять же, осиливать надо.

Кста, а кто-то в курсе что там с вяленым сейчас?

Докладываю ситуацию по популярным дистрибутивам.

• В последнем Debian по умолчанию Wayland-сеанс.
• В Fedora уже как года два по умолчанию Wayland-сеанс.
• В CentOS 8 и RHEL 8 по умолчанию Wayland-сеанс.
• SUSE SLE одни из первых ынтерпрайзных дистров заюзали Wayland по умолчанию.
• В LTS-версиях Ubuntu по умолчанию X.Org, в не LTS, насколько понимаю Wayland.

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

Не сами же договорятся память у всех запущенных программ общая будет

Причём здесь какие-то доступы, не понятно

мощно делишь на ноль

иксы тормозят не из-за переключений контекстов

И тормозят там не иксы.

NFS-сервер

Ну, это вообще куча реализаций.

Спасибо комрад, родина тебя не забудет =)

В общем да. Но Xorg это операционная система сбоку.

Была ей. Потом иксы начали кастрировать и из ОС у нас остался лишь хреново работающий оконный сервер.

Два разных предложение объединил в одно, а ни первое, ни втрое не понял, красота.

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

Это будет следующая «идея» для полного переписывания, когда вяленного наконец-то доведут до состояния, когда его может использовать нормальный человек. Ну тоесть лет так через 10. +)

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

а там где нужна простая графика в ядре она давно уже есть - framebuffer .

не про разграничение в смысле запрета

не перезаписывали

деление на ноль продолжалось…

Ты концептуально не одупляешь.

По сабжу – часть графики в ядре Windows это Legacy. И помещена она была в ядро не потому, что «хаха тупые мелкософтовские говнокодеры ни шмогли в архитектуру», а потому что в те далёкие времена железо не позволяло сильно разгуляться. Зато Windows мог работать там, где иксы (XFree86) выдавали пук.

Но сегодня Microsoft и любой другой создатель ОС никогда не стал бы делать подобное. Графика в ядре это плохо. Она слишком сложна и объёмна. И Windows с ней до сих пор мучается, когда сервера хакают из-за того, что из ядра торчат графические уши. Эпичные уязвимости из-за графики в ядре:

1. https://www.thezdi.com/blog/2019/12/16/local-privilege-escalation-in-win32ksys-through-indexed-color-palettes

2. https://securelist.com/new-win32k-zero-day-cve-2019-0859/90435/

3. https://www.welivesecurity.com/2019/07/10/windows-zero-day-cve-2019-1132-exploit/

И т. д.

Всем тем, кто хочет графику в ядре посвящается.

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

Ну да, только когда иксы жрут 20 мегабайт, bspwm 1 мегабайт, sxhkd, polybar, rogi/dmenu тоже по-слегка это все еще в разы меньше, если использовать compton, который жрет 4 мегабайта, а не 40+ мегабайт. Если не ошибаюсь, то mozc_server жрет больше иксов. А ведь это не графика а движок IME всего лишь. И враки это что иксы тормозят. Может на задохлых двуядерный ноутбуках это и так. Только это проблема говернора, а не иксов. Там 40%+ бывает прирост.

Зумерок не палится. Намешал в кучу проблемы 9x и NT, васянские переустановки и графику в ядре. Лол.