Как там создание X12?

Polugnom> Wayland и есть X12, если что.

В каком месте? Wayland по всем без исключениям пунктам противоречит концепции X.

Чем GLX ненормален?

Сетевой прозрачности нет. Ну давай - предложи HTTP.

Вас, господа, послушаешь, так сетевая прозрачность - это главная и самая востребованная фича современного линукса. На все насрать, лишь бы сетевая прозрачность была.

Polugnom> А у X12 вообще нет никаких требований.

Есть.

Polugnom> Та портянка на wiki Xorg к реальности не имеет никакого отношения.

Имеет самое прямое.

Polugnom> А X12 имеет?

X12 - это и есть иксы. Только версия протокола другая.

Polugnom> Ну давай переименуем Wayland в X12, что изменится?

Давай мы говноеда назовём твоим ником - что изменится?

Это же очередная тема о x11/вяленде. Если не скатить её сразу, кто-то может всерьёз начать обсуждать её.

X12 - это и есть иксы. Только версия протокола другая

X12 - это страничка в вики и ни одной строчки спецификаций или кода. На этом можно заканчивать.

Wayland по всем без исключениям пунктам противоречит концепции X.

Может мы какую-то другую страницу про X12 читаем? Потому что в моем мире Wayland во многом соответствует требованиям X12, кроме сетевой прозрачности.

А у x12 в списке требований сетевая прозрачность

Пока на ЛОРе борятся с утечками в криокамере в Weston запиливают поддержку RDP и SPICE. Вы всё ещё кипятите(сь)? Тогда мы идём к вам. (C)

Вы всё ещё кипятите(сь)?

ну если только в ванне с жидким азотом.

(Самая простая крио-камера, если что… их ещё продают в простой полиэтиленовой упаковке+канистра)

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

Polugnom> X12 - это страничка в вики и ни одной строчки спецификаций или кода. На этом можно заканчивать.

А Wayland - это имя мифического кузнеца и ни единой строчки кода. На этом можно заканчивать.

Polugnom> Потому что в моем мире Wayland во многом соответствует требованиям X12

Вот и возвращайся в свою параллельную и вообще второстепенную вселенную и не трогай главную.

Больше йогурта иксофилов в тред!

Никто не мешает тебе запилить свои )

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

в чём же, трол юшка?

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

вау. только ли фреймбуффер?

вау. только ли фреймбуффер?

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

X12

нинужно

wayland - во многом шаг назад.

4.2 /thread

Пока на ЛОРе борятся с утечками в криокамере в Weston запиливают поддержку RDP и SPICE

Новости почти годичной давности - это, конечно, круто, но, например, RDP в Wayland тогда был откровенно примитивным (а SPICE вообще был студенческой курсовой). Что-нибудь изменилось с тех пор?

Я так понимаю что примитивные технологии шаринга фреймбуфера по сети вызывает у школоты ощущение «вот мы и сделали иксы111»? :D

А Wayland - это имя мифического кузнеца и ни единой строчки кода.

ровно как и X11. не путай протокол и реализацию.

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

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

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

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

Последние лет 20 с иксами только и делали, что искали способ попрямее протащить на экран рисуемые клиентом буферы минуя тормозное и примитивное серверное иксовое рисование.

ты забыл ответить на вопрос, знаток

Последние лет 20 с иксами только и делали, что искали способ попрямее протащить рисуемые клиентом буферы минуя тормозное и примитивное серверное иксовое рисование.

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

Например вместо того что бы взять готовый x+opengl от силиконовой графики, прикручивали месу к xfree. И далее такая же фигня - есть NX но он не входит в базу xfree, есть многократное дублирование хилых усилий пока xfree дотачивали до возможностей коммерческих юниксов. И есть потребность запилить графику для примитивных девайсов вроде телефонов при отсутствии людей которые могут запилить такую графику в сложной системе типа X, а не в примитивном велосипеде шареного фрембуфера.

Последние 20 лет у X кризис финансирования и организации процесса разработки, перманентный. Отсюда кризис кадров. В результате есть бабки у разных использующих X коммерсов, есть форки у юникс вендоров, есть форки у фришных людей, есть программеры которые пишут то что должно было войти в иксы но в gtk/qt/ И все под несовместимыми лимцензиями. А вот полноценного развития X как системы нет уже 20 лет.А отсюда и песец.

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

ты забыл ответить на вопрос, знаток

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

Мне кажется проблема глубже. Задачу вывода картинок от разных приложений на экран нельзя выполнить одновременно архитектурно красиво, быстро и просто. Например в план9 графическая система архитектурно красива и проста, но жутко тормозная. В вейленде всё просто и быстро, но архитектурные решения оставляют желать лучшего.

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

Мне кажется проблема глубже.

Так названная мной проблема гораздо глубже чем кажется.

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

Это вы сейчас сказали что-то вроде «написать ядро ОС, которое было бы универсально, красиво, быстро» - невозможно. Но вот линукс, он опровергает :D. Собственно сравните ситуацию с линуксом и с X11. Задача создания графической подсистемы с такими возможностями это задача сранимая с созданием ядра ОС. Только вот программистов иксов на 2-3 порядка меньше, ага.

И есть большая разница между *просто* и *примитивно*. Если наколенный шареный фреймбуфер типа вейленда может накодить любой студент CS/CE, то вот сдизайнить протокол который позволяет «архитектурно красиво, быстро и просто», при чем позволяя выбирать динамически, прозрачно для клиента, наиболее эффективный способ - это хайлевел, вершина инженерной мысли. Профессура беркли и мит, старая школа. И огромные бабки. Фактически фундаментальщина такая, инженерная.

Тот же Линус например, он же не выдумывал юникс. Он реализовал уже придуманные кем то сисколлы, а далее просто расширял.

Например в план9 графическая система архитектурно красива и проста, но жутко тормозная.

Она там не столько тормозная, она крайне примитивна и устаревшая. Это по сути не «графическая система», а stub графической подсистемы что бы продемонстрировать архитектуру plan9.

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

И забыли добавить, путем отсечения существенной части ТЗ, если сравнивать с иксами. Дизайн мало того что не сетепрозрачный, так он еще и не расчитан на аппаратно ускоренную графику. Суть примитивов иксов в том что они должны были рисоватся графической картой, а не процессором :D Соответственно сам набор примитивов и подход к ним устарел, а вот концепция - нет ;D

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

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

Это не совсем так. Не у иксов, а у текущей реализации иксов скорее. И я не считаю bypass решения вида MITSHM, XV или GL direct rendering недостатками и усложнениями архитектуры, просто потому что они bypass. Такие bypassы встречаются в любом месте ИТ систем, это один из главных способов обеспечения оптимальности работы вообще - например точно так же работает шареная память в PCI, совершенно не отменяя регистров и класическую работу с шиной.

Грубо говоря замысел состоял в том что у нас есть X протокол и инфраструктура к нему, которая
а) может мутировать и развиваться с сохранением совместимости( расширения ).
б) гибок - рассчитан на замену всего и вся, проксирование там и тп. позволяет делать реализацию фич в том числе bypass'ом существующих компонент.

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

Проблема в том что у нас классическая проблема diminishing returns при серьезном отсутствии ресурсов. Огромное количество иксовых расширений застыли на уровне «кое как присобаченные сбоку», хотя должны были эволюционировать далее и заменить базовые иксовые протоколы. Грубо говоря ну что там делают примитивы 1980-го года выпуска? Низкоуровневое гтк с qt уже давно должно исполнятся на графическом процессоре, коммуницируя через Х.

так он еще и не расчитан на аппаратно ускоренную графику

Гм. Вейланд создавался как раз из расчёта на то, что система поддерживает egl. Он оперирует текстурами на гпу и ожидает от приложений таких же текстур для отрисовки.

Гм.

кажется, ты тоже начал подозревать :)

Но вот линукс, он опровергает :D.

Погдтверждает.
1. Linux не красив. Ядро монолитно и разработчикам требовались годы, чтобы выделить некоторые подсистемы в отдельные модули (вроде пранировщиков). И не смотря наэто, они сохраняют сильную связанность. (Нельзя врять и на лету заменить планировщик процессов, например.)
Сделать всё красиво, по заветам Танненбаума не получается. Ибо выходит совсем уж не быстро.
2. Linux не универсален. С одной стороны его подпирает кривизна архитектуры(например нельзя сделать универсальное arm-ядро, работающее на любом arm-устройстве). А с другой - потребность охватывать весь спектр поддерживаемого оборудования, из-за чего часто ломается внутренний API, мешающий долговременному существованию проприетарных драйверов (оставим пока дискуссию их нужности в стороне).
3. И, наконец, благодаря вышеперечисленному, Linux не быстр. Несмотря на все усилия мы всё ещё имеем примеры рецидивов 12309.

Если наколенный шареный фреймбуфер типа вейленда может накодить любой студент CS/CE,

Накодьте, а? И сдизайньте. Если учесть, что описание протокола wayland занимает немного больше двух строчек, очень хочется посмотреть на вашу нетленку.

это хайлевел, вершина инженерной мысли.

Сдайтся, тут банальное слепое поклонение.

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

Разработчики Mutter и KWin озадачены вашими словами... Оказывается, они давно уже делают невозможное...

Что-нибудь изменилось с тех пор?

Не интересовался. Мне это в данный момент не нужно. Однако же, это ставит под вопрос утверждение о хронической несовместимости вяленого с сетью.

Однако же, это ставит под вопрос утверждение о хронической несовместимости вяленого с сетью.

Если «совместимость с сетью» - это возможность сделать аналог VNC, то с сетью совместимо вообще всё, что отображается в битмап.

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

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

Про OpenGL слышал? DirectX? И, если уж на то пошло, в X-протоколе тоже есть средства работы с битмапами.

Про OpenGL слышал? DirectX?

Слышал, разумеется. DirectX как раз изначально был менеджером буфферов (DirectDraw часть, разумеется). Рисовать как раз программисту предлагалось. (Direct2D всякие уже не смотрел, равно как и Direct3D.)

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

И, если уж на то пошло, в X-протоколе тоже есть средства работы с битмапами.

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

DirectX как раз изначально был менеджером буфферов (DirectDraw часть, разумеется)

А, так у тебя сильное логическое мышление... имелся в виду Direct3D.

OpenGL? Ну есть там примитивы. Только я очень сомневаюсь

Имеешь полное право.

Сделать всё красиво, по заветам Танненбаума не получается. Ибо выходит совсем уж не быстро.

Ядро Plan 9. А Танненбаум так ничему и не научился (http://harmful.cat-v.org/software/andy_tanenbaum).

имелся в виду Direct3D.

Ну так и? Что есть такого в Direct3D? Те же регионы, только не квадратные, а треугольные?

Имеешь полное право.

OK, так просвятите меня, в чём же я не прав? Какой тулкит использует такие примитивы OpenGL, как точки, линии?

Ядро Plan 9.

А есть где-то сравнение Plan 9/Linux на тяжёлых задачах?

Гм. Вейланд создавался как раз из расчёта на то, что система поддерживает egl. Он оперирует текстурами на гпу и ожидает от приложений таких же текстур для отрисовки.

Вейленд получает целиком нарисованное «на CPU» приложением окно, копирует его в текстуру egl и дальше композитит при помощи опенгл es или на cpu. Ну или приложение напрямую рисует в OpenGL как в директ рендеринге.

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

1. Linux не красив.

Он некрасив только если мыслить в парадигме «нарисовать красивые микроядерные квадратики как у танненбаума»

Ядро монолитно

Ну вот - и сразу 4.2.

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

То есть тут вы противоречите себе и пишете что ядро таки не монолитное а модульное. окей.

И не смотря наэто, они сохраняют сильную связанность. (Нельзя врять и на лету заменить планировщик процессов, например.)

Сохраняют. Чудес, как вы сами написали, не бывает. Красота архитектуры она не в красивых квадратиках танненбаума, а в том что бы добится красоты при решении поставленных жизнью задач. А то квадратики на плакатике рисовать, это не «живую» ОС делать.

Сделать всё красиво, по заветам Танненбаума не получается. Ибо выходит совсем уж не быстро.

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

2. Linux не универсален.

Линукс в настоящий момент наиболее универсальная ОС с огромным отрывом. Если это «не универсальная» то так и пишите - универсальных ОС не бывает вообще. А нечего чорный пеар линуксу устраивать.

С одной стороны его подпирает кривизна архитектуры(например нельзя сделать универсальное arm-ядро, работающее на любом arm-устройстве).

А это точно кривизна архитектуры линукса, а не например кривизна архитектуры арма? Где у процессоров нет ничего общего кроме некоторого подмножества команд и бренда?

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

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

3. И, наконец, благодаря вышеперечисленному, Linux не быстр. Несмотря на все усилия мы всё ещё имеем примеры рецидивов 12309.

Так, еще один поехавший из армии «вендузятники за вейланд» и «а у вас в линупсе 12309».

А у людей у которых 12309 нету, линупс как, быстро работает? :D А вы таки уверены что «рецидивы» это 12309, а не существующий в системах еще до появления линукса проблема с постановкой системы раком свопом?

Если наколенный шареный фреймбуфер типа вейленда может накодить любой студент CS/CE,
Накодьте, а? И сдизайньте. Если учесть, что описание протокола wayland занимает немного больше двух строчек, очень хочется посмотреть на вашу нетленку.

Идиотское предложение. А нафига еще один шареный фреймбуфер? У нас уже 3 штуки есть. Надо больше шареных фреймбуферов для вейленда, бога шареных фреймбуферов?

это хайлевел, вершина инженерной мысли.

Сдайтся, тут банальное слепое поклонение.

Нет, это объективный факт инжиниринга. Придумать красивую гибкую и сложную архитектуру на пару порядков более сложная задача чем просто решить проблемы согласно ТЗ. Для того что бы такая архитектура реально возникла нужно не квадратики на плакатиках рисовать, а придумывать архитектуры, реализовывать их, тестировать ... и опять браться за чертежи выкидывая очередное поделие. В результате красивых архитектур очень не много, а в живой природе в основном присутствуют криворукие поделия в стиле «нагнали индусов, они закодили ТЗ. если теперь к ТЗ добавить еще строчку - все редизайнить и переписывать с нуля»

Разработчики Mutter и KWin озадачены вашими словами... Оказывается, они давно уже делают невозможное...

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

Понятия не имеют что термин «аппаратное ускорение» значит не только ускорение композитинга в нужном только дебилам компризе.

То есть тут вы противоречите себе и пишете что ядро таки не монолитное а модульное. окей.

модульность != монолитность. Подсистемы не изолированы в отдельных адресных пространствах. Некорректный модуль способен привести к непредсказуемому поведению ядра.

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

Но тогда вы себе противоречите. Ниже вы пишете, что «на мобиле красиво окошки листались и птички злые летали - а дальше хоть трава нирасти». Но это и есть «поставленная жизнью» практическая задача. Так что решите: Мы об архитектуре (а выроде вы начинали про неё) или о результате перед глазами пользователя? Тогда, знаете ли, и венда кошерна.

А это точно кривизна архитектуры линукса, а не например кривизна архитектуры арма?

«Нельзя жить в обществе и быть свободным от него». Ленин.
Нельзя поддерживать железо и быть независимым от аппаратной реализации. Так или иначе, но Linux вынуждени иметь фарш #if в подсистеме arm. И какая разница - кто виноват? Можно же было возгордиться и не поддерживать. Зато - чистота, ага. :)

А нечего чорный пеар линуксу устраивать.

Боюсь вы меня в корне не поняли. Я не пытаюсь тут сказать, что Linux плохой. Наоборот, я считаю его хорошим. Просто ваши требования абсурдны. Их строгое соблюдение противоречит требованиям использования и суровым реалиям аппаратных реализаций. По этому Linux не идеален, X не идеальны и вяленый не идеален. Но такая «сакральная» идеальность нужна только в головах профессоров. В жизни она вредна и излишня.

А у людей у которых 12309 нету, линупс как, быстро работает? :D

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

А вы таки уверены что «рецидивы» это 12309, а не существующий в системах еще до появления линукса проблема с постановкой системы раком свопом?

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

Идиотское предложение.

OMG. Только не подумайте, что я всерьёз предлагал вам кодировать. Вот уж точно «не нужно». Нет, я не считаю, что вы не справились бы. Действительно, уже хватает. :)

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

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

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

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

Это, мягко говоря, невероятный плевок в разработчиков clutter. Они и не знали, что их библиотека лишь на композитинг годна. Завтра же им напишу, чтобы выкинули принитивы. :)

термин «аппаратное ускорение» значит не только ускорение композитинга

Ну, если оставить в стороне cairo и clutter, то что вам по большому счёту нужно? Мне казалось, что дрожащими окошками мы благополучно переболели ещё во времена compiz. Неужели нет?

Аминь. Никто кроме тебя самого не помешает тебе :)

Разве что какой-нибудь атомный поединок в списке рассылки Линуса с аффтарами Plan 9.

модульность != монолитность. Подсистемы не изолированы в отдельных адресных пространствах. Некорректный модуль способен привести к непредсказуемому поведению ядра.

Вообще то часть кода многих модулей уже исполняется в ядерных тредах не в режиме ядра, внезапно. Линукс давно уже не классический, как его понимали в учебниках, монолит. Это не считая всяких fuse.

... Так что решите: Мы об архитектуре (а выроде вы начинали про неё) или о результате перед глазами пользователя? Тогда, знаете ли, и венда кошерна.

Мы о том что красоту надо сравнивать на сравнимом диапазоне задач. Вы трясете микроядерностью как достоинством, но с чего вы взяли что это достоинство? Танненбаум рассказал? Ну там вон приводили емейл не менее маститых специалистов сделавших план9, на тему того куда идет танненбаум.

А это точно кривизна архитектуры линукса, а не например кривизна архитектуры арма?
Нельзя поддерживать железо и быть независимым от аппаратной реализации. Так или иначе, но Linux вынуждени иметь фарш #if в подсистеме arm. И какая разница - кто виноват? Можно же было возгордиться и не поддерживать. Зато - чистота, ага. :)

Вообще говоря огромная разница «кто виноват». Потому что если авторы архитектуры не виноваты в том что она «никрасивая» - так и нечего перечислять это в качестве недостатков линукса, как вы делаете. И да вы так делаете.

Мой тезис был «посмотрите какой годный линукс сделали на не менее сложной задаче. если бы такие же силы были бы брошены на иксы - все с иксами было бы иначе». Вы контраргуменетируете мне тезисом «линукс тут неаргумент, так как линукс тут и тут негодный».

Боюсь вы меня в корне не поняли. Я не пытаюсь тут сказать, что Linux плохой.

Нет, вы именно это и пытаетесь сказать. Отчего и повторяете аргументы *именно* критиков линукса.

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

Я не требую строгого соблюдения чего бы то ни было.

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

Но нет этого - по многим вполне нормальным причинам.

По этому Linux не идеален, X не идеальны и вяленый не идеален. Но такая «сакральная» идеальность нужна только в головах профессоров. В жизни она вредна и излишня.

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

Нет. ... Т.е. специализированное решение в каждом конкретном случае будет лучше. Но универсальное - удобнее.

Боюсь это произошло не потому что вы пишите, а потому что 2.4 отлаживали для их спектра задач именно на тормозных компах прошлого. Это не значит что 2.6 для такого пропатчить невозможно потому что 2.6 такое универсальное, это значит что это никому не нужно.

А вы таки уверены что «рецидивы» это 12309, а не существующий в системах еще до появления линукса проблема с постановкой системы раком свопом?

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

Отключенный своп данный глюк никак не отрубает, просто со свопом он чаще возникает. Грубо говоря вы копируете файл, а система лезет на диск за системными файлами вылезая из кеша. Треш, угар, все встает раком. Дешевые десктопные дисковые подсистемы рассчитаны на однозадачный юзкейс, фактически. В свое время я ради этого ставил SCSI диск на свой компутер. Он был дорогой, маленький, но кардинально менял юзер экспириенс.

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

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

Вы просто недооцениваете студентов CS/CE - а то что вейленд прост, это не значит что он не time-consuming.

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

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

Это, мягко говоря, невероятный плевок в разработчиков clutter. Они и не знали, что их библиотека лишь на композитинг годна. Завтра же им напишу, чтобы выкинули принитивы. :)

То есть что бы в вейленде сделать ускоренный вывод графики, нужно не просто переписать весь софт на clutter, так еще нужно стать как Крузис, хыхы. Писать в свой отдельный OpenGL контекст в режиме дырект рендеринга :D Вообще эта попытка начиная с QTшников делать ускоренную графику написанием собственного крузиса :D она показательна. Каждая блядь стремится заховать прямой доступ к железу из юзероспейса :D

Ну, если оставить в стороне cairo и clutter, то что вам по большому счёту нужно? Мне казалось, что дрожащими окошками мы благополучно переболели ещё во времена compiz. Неужели нет?

То есть вы считаете что директ рендеринг в opengl должно делать абсолютно каждое приложение рисующее хоть что-то, если оно хочет аппаратно ускоренной графики ? :D

Слушайте, а давайте вообще выкиним этот ваш линупс, едро там какоето, сисколлы там, файлы эти сраные. Ето же всио устарело как говно мамонта и атски тормозит - у миниа постоянный 12309 и телки из 10го бэ нидают. Напишем с нуля все, и сделаем каждой проге чисто по хардкору ультрабыстрый прямой доступ к железу! И шаринг этого доступа по крайне простому протоколу. Будет кроме директ рендеринга у каждой проги еще и директ нетворкинг, директ дискинг, директ мышинг и директ клавинг. Ах да, ищо директ звукинг обязательно.

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

Внезапно это вы хватили. Ядерные потоки, конечно, есть. Но код в них выполняется в режиме ядра.

Вы трясете микроядерностью как достоинством, но с чего вы взяли что это достоинство?

Ну, низкая связанность отдельных частей большой программы, их изоляция всегда благо. Эта прописная истина родилась не в уютных кабинетах профессоров, а в боевых условиях, где за неё платили кодом и болью. :) Короче, чем менее зависимы друг от друга отдельные части кода, тем легче ими управлять.

Танненбаум рассказал?

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

так и нечего перечислять это в качестве недостатков линукса, как вы делаете.

Понимаете, если бандиты поймают человека и отрежут ему ногу, то виноваты будут, конечно, бандиты. Но человек все равно будет одноногим. Хоть он и не виноват. Такие дела.

Вы контраргуменетируете мне тезисом «линукс тут неаргумент, так как линукс тут и тут негодный».

Я контраргументирую «Linux не настолько годный, как вы хотите показать».

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

Ваша переработка иксов была бы тем же самым. Берём иксы, выкидываем из них то, чем никто не пользуется и пользоваться не будет (вроде примитивов), ломаем все совместимости, чтобы соотствествовать текущим реалиям и оставить задел на будущее, выкидываем все расширения, существующие сейчас на костылях и заменяем их нормальной реализацией. Добавляем возможность расширять протокол и... Получаем Wayland.

Это не значит что 2.6 для такого пропатчить

Можно. Выкинуть всё, что не нужно на слабых компах и получить... 2.4. :)

В свое время я ради этого ставил SCSI диск на свой компутер.

Ну, уменя система на ssd, /home на hdd sata achi ncq, а 12309 ловил в каноничном случае копирования на флешку. Как копирование с hdd на flash могло помешать читать что-то с ssd ума не приложу. Причём, ssd висит на sata 3 (ASM1062), а hdd на Intel. Т.е. он с разных контроллеров одновременно читать не может.

Отчего и повторяете аргументы *именно* критиков линукса.

О, да! Давайте всем немцам немедленно запретим говорить на немецком, ведь на нём говорил Гитлер!!!111111
Это фанатизм, запрещать высказывать аргумент, потому что его говорили враги Linux. :)

Я думаю что авторы вейленда просто значительно переоценили потенциальные трудозатраты.

Т.е. люди, которые многие годы разработывали xorg переоценили трудозатраты, потому что не знали с чем имею дело? Ладно. :)
Ваша точка зрения всё больше на теорию заговора начинает походить, потому что теряет критерий фальсифицируемости. Любой аргумент вы оборачиваете в свою поддержку, типа быстро разрабатывают - студота, лабающая на коленке. Медленно - нубы, не понимающие с чем связались. Вау!

То есть что бы в вейленде сделать ускоренный вывод графики, нужно не просто переписать весь софт на clutter, так еще нужно стать как Крузис, хыхы.

Слушайте, вы уж определитесь, чего вы хотите, а? А то ваши ранние слова про необходимость аппаратного ускорения итерфейсов начинают на маркетологический булшит походить. Делаем композитинг аппаратно - этого слишком мало. Рисуем кнопочки через OpenGL - много. Что же в самый раз? Как понимать ваши слова про "Низкоуровневое гтк с qt уже давно должно исполнятся на графическом процессоре"?