Enlightenment в будущем перейдёт на Wayland и не заинтересован в поддержке Mir

О KDrive я в курсе, но как это соотносится с современными KMS-драйверами? Как мне собрать (статический, но это необязательно) X-сервер, в котором выпилено всё, кроме базовых модулей, Xineramы и поддержки интеловского KMS?

Как мне собрать (статический, но это необязательно) X-сервер, в котором выпилено всё, кроме базовых модулей, Xineramы и поддержки интеловского KMS?

Не знаю. А зачем тебе? KDrive мог работать в мегабайте памяти, но зачем это сейчас?

Не знаю.

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

А зачем тебе?

Вебкит-десктоп.

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

...а когда у этого странного хемуля с невнятной дикцией что-то не получилось, он решил отомстить - выкинуть иксы отовсду.

И зачем там статический сервер? Чем тебя не устраивает обычный? В конце концов, ты не обязан ставить драйверы не-Intel.

И тем не менее он вполне ясно обосновал, почему кроме чем как «работает — не трогай» за Х11 аргументировать трудно.

Меньше бинарников тащить, проще структура корневой ФС. Но это как раз не критично. Важно собрать минимальнейшие иксы.

Важно собрать минимальнейшие иксы.

Да почему это важно? Та же xinerama - модуль, тупо не грузи его. Можешь при сборке пакета «myminimalx» его не включать в пакет.

Я говорю об архитектуре графических серверов, а не их реализаций.

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

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

Щас. Если надо - лезут. Вопрос в «стоимости» залезания.

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

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

В 90-х в экосистеме X произошла катастрофа - последствия которой до нас докатились сейчас. Парадигма Иксов была рассчитана на то что для решения возникших вокруг потребностей в них именно что *будут залезать*. Выпускать по необходимости X12, X13, X14 и так далее, инкорпорируя изменения ландшафта.

Более того, это должно было происходить в XFree86/Xorg. А тут оказался затык на порядок более мощный: мы видим что огромное число вещей которые в 80-х включались бы в X или даже в экстеншины но менее костыльно - в 90-е прикручивались в виде костылей.

Собственно пример с видео в X тут показателен. Что с точки зрения логики X значительная часть mplayer должна крутится в внутри X сервера - а точнее тасклетов каких нибудь. Что бы ведоплеер черех X протокол кормил X сервер просто сжатым видеопотоком, при чем в целой кучи форматов. Прозрачно-сетевым способом. А на сервере уже само расширение решало - юзать ли vdpau/ акселератор разжатия / whatever. И программирование таких вещей должно быть *лехким*. Вообще программирование чего-либо ВНУТРИ X сервера, или просто серверсайд, должно быть ЛЕГКИМ Вот как бы как это все надо было делать в *парадигме* X.

И кстати о да - в коммерческих Х такое есть, видеоэкстеншины, во всяких sun ray.

А получилось в xorg што? Правильно - примитивные локальные расширения. *Ниасилили* правильное с точки зрения X решение, потому что Паккардов *нехватило*.

И опаньки. Дальнейшая история лишь следствие.

Но выход то из нее не писать вейленд. А вот все это осознать, и сделать выводы и делать тру-юниксвейную графическую подсистему. Воплощающую не 2.5 принцип юниксвея - а все.

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

Мне тут подсказывают, что у Maemo внутри именно X. Так что с гибкостью у X на сегодняшний день всё более-менее.

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

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

ЕМНИП, вполне позволяет. Правда, это требует Пакарда, но тем не менее.

Ну так как раз именно Пакард сотоварищи и делает вейленд - и я говорю потому что даже он в результате описанной задачи неасиливает.

Хм. Это первый более-менее здравый технический аргумент _за_ вяленд, который я слышал.

Я не уверен что это аргумент «за вейлед». Он этот вейленд объясняет лишь.

...а когда у этого странного хемуля с невнятной дикцией что-то не получилось, он решил отомстить - выкинуть иксы отовсду.

Именно.

Проблема именно что социотехническая - проблема хемулей.

Вопрос то в том - а хде взять других? Это либо бабло надо - либо энтузиазистов нарожать. И так и так - ххх.

Это либо бабло надо - либо энтузиазистов нарожать. И так и так - ххх.

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

Возможно тут поможет развитие всяких специализированных девайсов вроде промышленных визуализаторов, медицинских девайсов и прочей - но насегодня там жестокая кастомная проприетарщина - «opengl на CBuilder паяет боинги и космические ракеты» (С) мой знакомый который этим занимался. То есть надо достигнуть порога за которым потребуется развитие достаточно универсальных промышленных платформ, которы будут как сейчас с ядром - просто уже с графической подсистемой которая будет достаточно универсальна, чтобы разрабатывать на ней платформы такого типа.

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

Щас. Если надо - лезут. Вопрос в «стоимости» залезания.

X-серверов много, залезть во все - очень дорого получится, а профита ноль. Но это не проблема X-серверов вообще и xorg в частности.

И программирование таких вещей должно быть *лехким*. Вообще программирование чего-либо ВНУТРИ X сервера, или просто серверсайд, должно быть ЛЕГКИМ Вот как бы как это все надо было делать в *парадигме* X.

Программирование внутри сервера - это парадигма NeWS. И, говорят, у нее были серьезные проблемы.

*Ниасилили* правильное с точки зрения X решение, потому что Паккардов *нехватило*.

Спорно и то, что правильное решение лежит внутри X, и что в нехватке «Паккардов» виновата архитектура X. Задача сложна сама по себе, и не факт, что любая серверная архитектура сделала бы ее решение проще, чем решение на клиенте.

Я не уверен что это аргумент «за вейлед». Он этот вейленд объясняет лишь.

Да никакой разницы.

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

У нас вся ситуация фактически возникла из-за того что вот эти товарищи из ужасной проприетарщины пришли в линукс - потребности создать некую нормальную общую платформу не выработали. Ведь андроиды это собственно оно и есть - SoC девайсы и «opengl на CBuilder паяет боинги и космические ракеты»

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

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

Вот!
Более того - что бы можно было запилить теми же силами всякие экстеншины. Ситуация когда у нас полно различных (графических) сопроцессоров сильнопроприетарных, различных инновационных способов ввода информации и тп, плюс разннобразные юзкейсы, обязательно приведет к тому что для того что бы что-то с этим поделать нужно будет запустить цикл trial&error. Делать разные экстеншины и их тестить в real world сценариях.

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

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

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

да нет - падения метеорита не относится к условиям жизни. Всегда и везде это относится к катастрофам

;-)

в своё время сборка X-a разрешала выбор необходимых компонент, подозреваю одно из первых нововведений после ухода от XFree86 было выпиливание такой системы сборки