Wayland научился эмулировать несколько мониторов

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

Орли? Открой что ли http://en.wikipedia.org/wiki/X_Window_System_protocols_and_architecture и попробуй сформулировать, сколько именно из расширений протокола тебе даром не сдалась.

И нарушение самой концепции unix.

Нужна сетевая прозрачность?

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

«Сетевая прозрачность» — это не только сетевая прозрачность. Это просто напросто организация вещей так, как и должно быть: в виде набора независимых процессов, соединенных потоками байт. А возможность подключиться к удаленному X-серверу — всего лишь одно из следствий того, что все сделано правильно.

Нужна сетевая прозрачность? Загружается плагин, реализующий определённый сервис, подключаясь к чему-то лёгкому, вроде Wayland.

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

к чему-то лёгкому

KDrive. Или ты никогда не слышал о том, что реализация X-сервера может быть произвольной? Это называется X-протокол и поддерживается всеми клиентами еще со времен, когда по небу летали динозавры, а компьютеры показывали только по телевизору. Велосипеды не нужны.

Процентов 90 кода иксов не нужна большей части пользователей. Так зачем было намертво замуровывать их в иксы?

Процентов 90 кода — это исходный код драйверов. Которые не намертво замурованы, а как раз, либо грузятся динамически (бэкэнд xfree86 в X,Org), либо с иксами слинкован только один из них (TinyX, иксы для винды и макоси). Запусти какой-нибудь сервер из семейства TinyX, посмотри на потребление памяти, и потом попробуй порассуждать о залежах ненужного кода. С вейландом можно поступить аналогично: создать еще один бэкэнд в X.Org, цепляющийся к вейленду. Будет какой-нибудь Xwayland, так же как существуют Xvesa и т.п. А вот попытки портировать и использовать на вейланде GTK и Qt сродни попыткам слинковать к каждому сетевому приложению библиотеку, реализующую IP прямо поверх канального уровня конкретной железяки — херня получается вместо системы. Времена MSDOS прошли, но некоторые просто всё никак не могут успокоиться.

>и попробуй сформулировать, сколько именно из расширений протокола тебе даром не сдалась.

Это бесполезно. Марк сказал, что надо вэйланд, и иксы тормозят. Тысячи хомячков сразу бросились рассказывать про устаревший протокол, огромный сетевой оверхед и т.д. Хотя только на днях узнали про X11 вообще.

Хотя проблемы у иксов и правда есть, но вэйланд - не решение. Это даже не серьёзно.

Что большая часть кода иксов - драйверы, я и так в курсе. Но посмотрите на оставшуюся часть. Вот там-то самое интересное... Не надо ковырять код, просто гляньте на расширения протокола. А ведь собираются выпустить двенадцатую версию протокола. И для простого управления окнами многое из того, что заложено в протокол - даром не надо. Сколько процентов от возможностей протокола заюзали в Openbox? Или в Gnome? А сколько там мусора, который не удаляют только потому, что он нужен для совместимости с ненужными древними тулкитами и прочими подделиями 80 и 90-х? Разбить бы иксы на ядро, и плагины(как в Compiz). А то получилось нечто большое и неповоротливое. Тем-более. что RDP,Spice и другие подобные технологии отлично справляются с расшариванием рабочего стола по сети. Так-что сетевая прозрачность не очень-то и нужна. А вот оператива свободная - всегда нужна, тому же Eclipse она очень нужна.

Вот выхлоп от top, смотрим на иксы:

2763 root 20 0 190m 46m 4420 S 0.3 4.9 0:25.25 Xorg

А бывает и больше. Иногда иксы и в два раза больше памяти жрут, это нормально? При том, что я юзаю Gnome 3/OpenBox, и иногда awesome, не компиз какой-то. И эффекты не люблю, поэтому всё у меня просто и без прикрас.

Вот выхлоп от top, смотрим на иксы:

2763 root 20 0 190m 46m 4420 S 0.3 4.9 0:25.25 Xorg

Смотрим. 46 мегабайт у вас занимают в памяти иксы. Вы действительно полагаете, что это много? Если да, то это значит, что криокамеры сломались, анабиозники ползут на свет, и вы — один из них. А теперь серьёзно:

Блоб nvidia, практически пустой сеанс из одного openbox-а и пары терминалов. Смотрим на потребление памяти:

  RSS    SZ    VSZ CMD
30624 12880  41576 /usr/bin/X -nolisten tcp -br -deferglyphs 16 -auth /var/run/slim.auth vt07

30 метров — многовато для пустого сеанса. Глянем карту памяти процесса:

$ pmap -q 9676 | sed 's/^[^ ]*//' | sort -hr | head -n20
  11960K r-x--  /usr/lib/opengl/nvidia/lib/libGLcore.so.173.14.28
   5868K r-x--  /usr/lib/xorg/modules/drivers/nvidia_drv.so
   5120K rw-s-  /dev/nvidia0
   5120K rw-s-  /dev/nvidia0
   2896K rw---    [ anon ]
   2240K r-x--  /usr/lib/opengl/nvidia/extensions/libglx.so.173.14.28
   2216K rw---    [ anon ]
   1712K r-x--  /usr/bin/Xorg
   1588K rwx--  /usr/lib/opengl/nvidia/lib/libGLcore.so.173.14.28
   1456K rw---    [ anon ]
   1284K r-x--  /lib/libc-2.11.3.so
    588K rw-s-  /dev/nvidia0
    532K r-x--  /usr/lib/libfreetype.so.6.6.2
    532K rw---    [ anon ]
    456K r-x--  /usr/lib/libgcrypt.so.11.6.0
    440K rwx--  /usr/lib/opengl/nvidia/extensions/libglx.so.173.14.28
    364K r-x--  /usr/lib/libpixman-1.so.0.20.2
    356K rw---  /usr/lib/xorg/modules/drivers/nvidia_drv.so
    228K rw---    [ anon ]
    216K r-x--  /usr/lib/libXfont.so.1.4.1

Ба! Да там практически всю эту память занимает драйвер. Иксы-то, оказывается, и ни при чем.

Зайдём в нормальный сеанс: с gnome-panel, Pidgin-ом и кучей других программ.

  PID   RSS    SZ    VSZ CMD
 2737 35864 14304  51240 /usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-OvSTcZ/database -nolisten tcp vt7

Даже практически не почесалось увеличиться. Ок, запустим пару окон наутилуса, оперу с 3-мя окнами и кучей вкладок, да firefox с полдюжиной роликов ютюба. Смотрим:

  PID   RSS    SZ    VSZ CMD
 2737 79424 49924  94860 /usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-OvSTcZ/database -nolisten tcp vt7

80 мегабайт. Учитывая, сколько приложений запущено, это даже не смешно. htop мне говорит, что сейчас занято 750 метров. Вам 1/10 потребляемой памяти жалко на графическую подсистему? Кстати, я сейчас запускал GoboLinux, и там у иксов потребление памяти RSS 6MB и VSIZE 14MB, а полностью прогруженный сеанс KDE3 вместе со всеми панельками и прочим барахлом отнимает всего 85 метров. Что характерно, жрет памяти система гораздо меньше, чем современное bloatware, но соотношение RSS иксов к общему количеству занятой памяти примерно то же. А вы бы и 6 мегабайт пожалели на иксы?

Не надо ковырять код, просто гляньте на расширения протокола.

Как раз _надо_ ковырять код, иначе так и будете доказывать несуществующее. Но, впрочем, и с расширениями протокола не мешает ознакомиться. А потом сравнить с размерами библиотек какого-нибудь gtk3 или, прости господи, qt4. Кстати, о птичках:

$ pmap -q `pgrep pidgin` | sed 's/^[^ ]*//' | sort -hr | head -n30
  51828K r----  /usr/share/icons/gnome/icon-theme.cache
   8792K rw---    [ anon ]
   8192K rw---    [ anon ]
   8192K rw---    [ anon ]
   8192K rw---    [ anon ]
   8192K rw---    [ anon ]
   8192K rw---    [ anon ]
   5308K r-x--  /usr/lib/gstreamer-0.10/libgstffmpeg.so
   4984K rw---    [ anon ]
   4756K r----  /usr/share/icons/hicolor/icon-theme.cache
   3848K r-x--  /usr/lib/libgtk-x11-2.0.so.0.2200.1
   2856K r--s-  /usr/lib/aspell-0.60/ru-ye.rws
   2348K r-x--  /usr/lib/libmysqlclient.so.18.0.0
   2048K r----  /usr/lib/locale/locale-archive
   1428K r-x--  /usr/lib/libvorbisenc.so.2.0.8
   1424K r-x--  /usr/lib/libdb-5.1.so
   1420K r-x--  /usr/lib/libcrypto.so.1.0.0
   1404K r-x--  /lib/libc-2.13.so
   1352K r-x--  /usr/lib/perl5/core_perl/CORE/libperl.so
   1156K r-x--  /usr/lib/libxml2.so.2.7.8
   1152K r----  /usr/lib/locale/locale-archive
   1120K r-x--  /usr/lib/libX11.so.6.3.0
   1080K r-x--  /usr/lib/libnss3.so
   1036K r-x--  /usr/lib/libtk8.5.so
    992K r-x--  /usr/lib/libtcl8.5.so
    984K r-x--  /usr/lib/libpurple.so.0.7.11
    928K r-x--  /usr/lib/libgio-2.0.so.0.2600.1
    904K r-x--  /usr/lib/libstdc++.so.6.0.16
    844K r-x--  /usr/bin/pidgin
    824K r-x--  /usr/lib/libglib-2.0.so.0.2600.1

А вот этот товарищ мне еще больше нравится:

$ pmap -q `pgrep eiskaltdcpp-qt` | sed 's/^[^ ]*//' | sort -hr | head -n30
  10628K r-x--  /usr/lib/libQtGui.so.4.7.2
   9216K rw---    [ anon ]
   8456K rw---    [ anon ]
   8192K rw---    [ anon ]
   8192K rw---    [ anon ]
   8192K rw---    [ anon ]
   8192K rw---    [ anon ]
   8192K rw---    [ anon ]
   8192K rw---    [ anon ]
   8192K rw---    [ anon ]
   8160K rw---    [ anon ]
   3848K r-x--  /usr/lib/libgtk-x11-2.0.so.0.2200.1
   3436K r-x--  /usr/bin/eiskaltdcpp-qt
   2856K r--s-  /usr/lib/aspell-0.60/ru-ye.rws
   2600K r-x--  /usr/lib/libQtCore.so.4.7.2
   2584K r-x--  /usr/lib/libQtScript.so.4.7.2
   2468K r-x--  /usr/lib/libkdecore.so.5.6.0
   2048K r----  /usr/lib/locale/locale-archive
   1696K r-x--  /usr/lib/libeiskaltdcpp.so.2.2
   1420K r-x--  /usr/lib/libcrypto.so.1.0.0
   1404K r-x--  /lib/libc-2.13.so
   1156K r-x--  /usr/lib/libxml2.so.2.7.8
   1152K r----  /usr/lib/locale/locale-archive
   1148K r-x--  /usr/lib/libQtNetwork.so.4.7.2
   1120K r-x--  /usr/lib/libX11.so.6.3.0
   1024K rw---    [ anon ]
   1024K rw---    [ anon ]
   1024K rw---    [ anon ]
   1024K rw---    [ anon ]
   1008K rw---    [ anon ]

Всё еще хотите поговорить о раздутости иксов? Может стоит сначала поговорить о раздутости тулкитов и приложений?

А ведь собираются выпустить двенадцатую версию протокола.

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

И для простого управления окнами многое из того, что заложено в протокол - даром не надо.

Там как раз ничего нет про управление окнами, вас кто-то обманул. Окнами управляет оконный менеджер. А в протоколе лишь заложены базовые механизмы для произвольного обмена данными между клиентами. Фактически, прообраз _нормальной_ сессионной шины, какой она могла бы быть, вместо недоношенной dbus. И это — как раз одна из ключевых фич протокола, и строго выдержанная в духе концепции unix.

А сколько там мусора, который не удаляют только потому, что он нужен для совместимости с ненужными древними тулкитами и прочими подделиями 80 и 90-х?

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

А вот оператива свободная - всегда нужна

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

Спасибо за познавательный материал. Честно говоря, много не знал. А точнее даже не думал в этом направлении. Ругают в обзорах иксы за раздутость, значит раздутые иксы... А на самом деле не всё так просто. Что касается тулкитов, они и дальше будут распухать. Больше контролов, анимации и прочих плющек, вроде CSS-стилей и декларативного UI. Это модный тренд, и его никто не отменял. Эх, вариант один - прийдётся покупать память. Да и не столько иксам, сколько Firefox'у и Eclipse'у. Такие они прожорливые... Это из-за них я постоянно ищу свободные мегабайты, потому что своп не очень радует, тормоза...