Wayland готов для десктопа

> Вы зря исключаете вероятность того, что иксы могут стать быстрее. Это тоже возможно.

Ну конечно. С костылем они станут быстрее.

> Я еще раз предлагаю считать программы не по пальцам, а с весом, соответствующим их использованию.

Дурацкая идея. Сколько процентов пользователей используют Mathematica? 0.0001? А сколько она стоит?

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

> Сколько процентов пользователей используют Mathematica? 0.0001? А сколько она стоит?
А при чем тут деньги вообще?
Очевидно, что при принятии решений о направлении развития десктопа файрфокс намного важнее математики, даже если он бесплатен, а она стоит кучу бабла.

> Вы никогда не видели, как в виртуалке приложения бегали быстрее, чем нативно?

Нет, конечно. А вы где видели?

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

иксы+вейленд>иксы

> А вы где видели?
Видел. За счет шустрого дискового ввода-вывода.

иксы+вейленд>иксы

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

> Видел. За счет шустрого дискового ввода-вывода.

То есть, имеется в виду разное оборудование.

В левой части не просто иксы - а иксы заточенные под вейленд.

На ходу придумали?

>Сколько процентов пользователей используют Mathematica?
В свете нашей дискусси - пофиг. Математику уже 3 версии как на КюТе.

> То есть, имеется в виду разное оборудование.
Оно всегда разное. Снаружи реальное, внутри виртуальное. Я говорю о том, что виртуальные диски могут быть быстре реальных.

На ходу придумали?

Очевидные соображения - если из иксов выкинуть (будьте спокойны, в билд-тайм) кучу ненужного кода для сопряжения с разными железами и оставить только код код для вейленда - можно его вылизать и соптимизировать. Он станет лучше ложиться в кеши процессора, в частности. Так что это СОВСЕМ не те же самые иксы, которые работают на железе.

> Я говорю о том, что виртуальные диски могут быть быстре реальных.

Быстреее реальных RAM-дисков?

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

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

> Быстреее реальных RAM-дисков?
Где я сказал, что в виртуалке ВСЕГДА быстрее? В некоторых случаях (не в случае рам-дисков) виртуалка может быть быстрее.

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

Ему там полюбасу быть. Мой пойнт был в том, что иксы вейлендовые не тождественны иксам самостоятельны.

> В некоторых случаях (не в случае рам-дисков) виртуалка может быть быстрее.

Если оборудование одно и то же, виртуалка не будет быстрее.

> Он станет лучше ложиться в кеши процессора

ROTFL

> Если оборудование одно и то же, виртуалка не будет быстрее.
Оборудование внутри виртуалки выглядит иначе, чем для основной ОС.

Так вот, если диск достаточно тормозной, два уровня кеша (я огрубляю, конечно, их там больше - в общем случае N и N + M) при некоторых условиях могут быть эффективнее одного. Поэтому дисковые операции внутри могут быть быстрее.

>Все верно.

а вот сего как раз нету. самый простой пример: открываем гугол и набираем msvcr...

Увы, в окнах такой же бардак, как и в unix, только власть захватили не четлане, а пацаки. И причина кроется главным образом в хитрожопом способе обфускации имены С++ных символов, меняющимся от одной версии gcc/msvc к другой. Тот же буст, чувствительный к этим штучкам под винду водится в виде охапок библиотек с именами навроде libtrololo[-mt][-gd][-vc{6,7,8,9,10}].dll.

А всё это происходит от того, что давным давно программисты решили, что мол давайте ка мы не будет на экспортируемый класс заводить одну таблицу методов, и экспортировать её как один символ, а все кишки наружу высунем. КПД одинаковый - и так и так 1 indirect call будет, что через таблицу, что через GOT.

Просто сделано через жопу в самом основании.

хотел бы отметить - для directFB существует XdirectFB:

«XDirectFB is a rootless X Server using DirectFB windows for X11 toplevel windows.»(с сайта)

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

>И что? все равно придется пускать вейленд параллельно с иксами.

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

>хотел бы отметить - для directFB существует XdirectFB:

а для мака есть XQuartz - америку ты не открыл:)

>И причина кроется главным образом в хитрожопом способе обфускации имены С++ных символов, меняющимся от одной версии gcc/msvc к другой.

Отъвленное 4.2. Дело не в манглинге, а в том, что они не умеют поддерживать ABI

>Сейчас таких программ большинство. Уверен, что большинство из этого большинства под вейленд не перепишут.

Твои третьи кеды точно не перепишут :)

А кстати я как-то еще не задумывался - это придется писать новый X сервер, который в вейленде будет работать?

>это придется писать новый X сервер, который в вейленде будет работать?

Не обязательно, но иначе будет некоторый оверхед

наверняка X в виде клиента к существующей системе написать проще, но все-таки это много работы.
Еще opengl непонятно как должен работать у иксовых программ при такой схеме.

> Твои третьи кеды точно не перепишут :)

О чем и речь. И не только третьи кеды.

>Тот же буст, чувствительный к этим штучкам под винду водится в виде охапок библиотек с именами навроде libtrololo[-mt][-gd][-vc{6,7,8,9,10}].dll

Скажи спасибо разработчикам MSVC. Причем этот компилятор считается «стандартом» ABI для Windows (например, интеловский с ним совместим), но при этом совершенно не обременен поддержанием этого «стандарта» между версиями. MinGW не в состоянии гоняться за совместимостью, поэтому у них свой ABI

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

Что поделаешь, сишное наследство) Поленились написать линкеры с поддержкой C++

>И не только третьи кеды.

Но и вторые :)

> Но и вторые :)

Вообще КДЕ не перепишут.

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

>Вообще КДЕ не перепишут.

kwin уже поддерживает opengles2, а значит, может быть портирован на wayland. Qt уже начали портировать (используя lighthouse)

Кстати, в том же лайтхаусе (http://gitorious.org/+qt-developers/qt/lighthouse) есть и коммиты связанные с XCB, что гораздо интереснее для ближайшего будещего

> kwin уже поддерживает opengles2, а значит, может быть портирован на wayland. Qt уже начали портировать (используя lighthouse)

kwin и Qt - возможно. А КДЕ - нет.

>А КДЕ - нет.

В кедах нет НИЧЕГО завязанного на иксы, кроме kwin (до недавнего времени)

> В кедах нет НИЧЕГО завязанного на иксы, кроме kwin (до недавнего времени)

В Qt есть.

есть. Но новый бэкэнд уже пишут (см. lighthouse)

> Но новый бэкэнд уже пишут (см. lighthouse)

Ну так он же если появится, будет только для новых версий Qt

>Ну так он же если появится, будет только для новых версий Qt

Спасибо, кэп. Очевидно, что в пролете только проприетарный софт, упакованный со своей (старой) версией Qt (не так давно встречал программы с Qt 4.4, наверное влом было продлевать коммерческую лицензию:)

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

> Очевидно, что в пролете только проприетарный софт, упакованный со своей (старой) версией Qt

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

> а вообще Qt поддерживает обратную совместимость, т.е программа, скопилированная со старой версией, должна работать и с новой

гон

>В пролете весь софт, который не портирован на новую версию.

Под «портированием» понимается перекомпиляция? Скорее всего не требуется

>гон

сам посмотри: http://linuxtesting.org/upstream-tracker/versions/qt4.html. Проблемы будут в экзотических случаях, например если ты внедрял QtAssistant, могут быть проблемы при переходе с 4.6 на 4.7, все остальное совместимо

Официально поддерживается совместимость Qt 4.N.x с 4.N-1.y

Это он о Qt3

дело вовсе не в линкерах. дело в том, как экспортируются с++ные классы. пусть у нас есть class

foo{
public:
  bar();
  lol();
};

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

struct __mangled_class_name_for_foo {
   void * bar;
   void * lol;
}

void * foo __attribute__((class foo));
...
foo=dlsym(MANGLED("foo"), RTLD_NEXT);
...
if(foo)code1(); else code_without_foo();

это не линковщик виноват, что ABI кривое и косое

>вечно меняющиеся правила манглинга вместо отдельной секции сpptab

в котором будет написано, какие С++ классы нужны обязательно. по 8 байт на класс + 1 запись в symtab. мелкая доделка в линковщике и изменение ABI. На х64 вообще бубна не потребуется, как писали mov reg, foo + call [reg+offset] так и продолжали бы писать - сейчас то же самое.

на i386 таблицу пришлось бы уносить в свой бинарь в момент линковки(еще пяток строчек типа malloc/memcpy на С в линкер добавилось, и всё.

а теперь сравните с тем, что сейчас творится.

> могут быть проблемы при переходе с 4.6 на 4.7, все остальное совместимо

Неправда, совместимость есть только в рамках мажорного релиза. Qt3 с Qt4 не совместима.

все, что ты написал, имеет отношение только к линкеру. А правила манглинга никто не меняет, насколько мне известно

я об этом и говорил, КДЕ 3 не портируют

Еще GTK <= 2 не портируют, там на иксы много завязано

>мелкая доделка в линковщике и изменение ABI

Не понимаю, где здесь изменение ABI, я вижу тут только изменение формата библиотеки

ABI - это application binary interface, то есть соглашение о том, как представить тот или иной объект ЯП в низкоуровневом виде и как их соединить. как найти в библиотеке тот или иной символ

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

> Еще GTK <= 2 не портируют, там на иксы много завязано

Ну да. А на GTK2 сейчас большинство приложений.

еще Java Swing. Значит, придется десктопу ждать оптимизированной реализации X11 на вяленде. А для планшетников и смартфонов самое то: легаси там нет.