Что Линус говорит о Иксах?

Я уже объяснял - замена X11, которая не будет обратно совместима с самыми древнючими аппаратными терминалами будет быстро послана в тухес. Что и происходило десятки раз. И всё равно, пыанэры всё лезут и лезут...

Ты видел SGI? Видел там тормоза у X11? К сожалению, до таких коммерческих реализаций Xorg ещё далековато. Но это не проблема самой архитектуры, это только лишь проблема реализации.

А на хера нужен этот убогонький псевдогуй, что был в QNX?

наконец то наш младший децельный научный сотрудник проснулся :)

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

> Я уже объяснял - замена X11, которая не будет обратно совместима с самыми древнючими аппаратными терминалами будет быстро послана в тухес.

сколько еще лет будем тащить за собой совместимость с этими древними терминалами?

10, 20 или безконечно?

> Ты видел SGI? Видел там тормоза у X11?

Хотел бы глянуть. Не на тормоза, а на SGI. Ну, правда, у них железо навроде как "свое" и им не надо особо париться с переносимостью на все существующие в природе арзитектуры, что может значительно снизить оверхед. Ну и, окроме того, они могли с самого начала делать "как надо", а не как я описал выше. Такое тоже бывает...

One-Eye, мне это кажется или твои другие имена суть Mauhuur, WidowMaker, Howler и просто vsl? Уж больно стилем похож.

> One-Eye, мне это кажется или твои другие имена суть Mauhuur, WidowMaker, Howler и просто vsl? Уж больно стилем похож.

да, это тот самый луговский

Безотносительно к железу, у них:

a) всё тот же самый X11, с клиент-серверной архитектурой

b) оверхеда нет, тормозов нет.

Теперь пыанэры будут кричать, что в SGI аппаратные ускорители unix domain sockets, да?

> Теперь пыанэры будут кричать, что в SGI аппаратные ускорители unix domain sockets, да?

Да причем тут "ускорители доменных сокетов"? Хватит, чтобы разрухи в головах не было с самого начала проектирования и разработки. То есть, сразу делалось по принципу get it right. С разработчиками из SGI не выпивал, посему ни за какой вариант не поручусь.

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

Дык об то и речь - проблема ну ни разу не в клиент-серверной архитектуре, и не в протоколе. Просто расплодились пыонэры, воспитанные на WinAPI и прочей подобной поцне... :(

Я бы даже сказал, что тяга к переписыванию всего тянется еще из ДОСа. Ведь там все, что было "стандартно", было криво (да и в винапи те же грабли), и хочешь-не хочешь, а должен был переписывать системные вызовы, чтобы оно работало более или менее приемлемо.

Но даже самый плохой никс на несколько голов выше самой хорошей винды, так что...

> Я бы даже сказал, что тяга к переписыванию всего тянется еще из ДОСа.

А это уже риторический вопрос, во времена доса - переписывали мало, в основном перли и ждали кряков. В случае с линухом - тут по принципу "кто если не мы". Я так думаю весьма неконструктивно сидеть и ждать пока очередная контора сжалится и откроет сырцы каго-нить графического проекта. Надо пытаться делать, криво/косо но делать. Мертворожденных будет много, но в конечном итоге на чем-то наименее кривом и косом остановится необходимая масса разработчиков, чтобы сделать что-то более менее удобоваримое. Кстати ситуация с диктатурой (большими корпорациями) "стандартов" несколько ослабла.

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

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

А вот "тонкие клиенты" рулят, а для них реализация X-протокола не нужна ! Им нужен шустрый, нетребовательный к локальным ресурсам ГУЙ.

> А вот "тонкие клиенты" рулят, а для них реализация X-протокола не нужна !

Вот именно, что им как раз нужна, они же _клиенты_. Сдохнуть не посоветую, но справиться у Google на предмет определения "тонкого клиента" не мешает.

Кроме того, для них иксы -- самое то.

> А это уже риторический вопрос, во времена доса - переписывали мало, в основном перли и ждали кряков.

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

> Им нужен шустрый, нетребовательный к локальным ресурсам ГУЙ.

Возьми пенек эдак второй с более-менее достойной видюшкой -- чтобы она сама по себе не тормозила. Запусти иксы. Обычные. Запусти с рядом стоящего четырехпроцессорного монстра на его дисплее что-то ресурсожрущее (но с чем монстр справится на ура). Удивись быстроте и красивостям гуя на своем нетолстом клиенте.

И вдогонку: лучше не зли One-Eye такими вещами. А то в этом вопросе он как раз прав. И я могу его понять, хотя у меня терпения и поболее будет ;)

Почему он прав -- можно прочитать в книжке http://catb.org/~esr/writings/taoup/html/. Которая скоро в бумажном виде появится и на русском языке (вроде до июля должны сделать).

> Почему он прав -- можно прочитать в книжке http://catb.org/~esr/writings/taoup/html/.

Не обещаю передумать ;) , но прочту обязательно !

Я когда-то тоже был Фомой неверным в отношении данного вопроса. Но уже давно одумался.

> Вот именно, что им как раз нужна, они же _клиенты_. Сдохнуть не посоветую, но справиться у Google на предмет определения "тонкого клиента" не мешает.

Возможно, но при реализации X - клиентов повышается расход траффика. Элементарно - отдел продаж. Каждый торговый терминал передает все введенные данные на сервер и также отображает результаты. В то время как при реализации интерфейса локально + компрессия передаваемых данных взависимости от типа траффик сокращается настолько,что 5-6 станций можно спокойно резервировать диалапом.

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

Так смотри. Можно держать легкий браузер локально и тяжелый WM на стороне более сильного компа (утрирую). Можно наоборот. After all, it's all about choice. Комбинации -- любые. Делать реализацию "только локально" -- значит урезывать этот выбор.

Кроме того, весь траффик X11 можно вентилировать через SSH, который вполне может обеспечивать компрессию.

В принципе да в случа с X-клиентом решение получается более универсальным. Немного не из той области я пример привел... Кстати за ссылку огромное спасибо. Описалово Directfb + Xdirectfb за мной.

Ну, на XDirectfb я посмотрел. Это делается так. Берутся иксы, туда копируется ошметок сырцов, иксы после некоторой правки конфига собираются (советую выспаться, или прогуляться с подругой в это время, беседовать желательно на темы от техники отвлеченные -- время быстрее пройдет). После этого они пашут через DirectFB с возможностью индивидуально колесом мышки подкручивать прозрачность любого окна (это несколько лучше "стационарной" установки -- посмотрел, что творится на терминале под другим окном, и вернул обратно), иметь приличную и даже очень 2d-акселерацию (там и 3d наклевывается, не знаю, правда, в какой мере) через один-единственный драйвер, что способно значительно облегчить вес иксов, вес же библиотек DirectFB сравнительно ничтожен. Вот такие пироги. Не совсем то, что хотелось, конечно, но тем не менее, довольно вкусно.

Еще бы взглянуть на Nano-X. Но это разве как-то потом :)

В первом абзаце предыдущего поста под "иксами" я имел в виду основанную на XFree86 реализацию.

> Ну, на XDirectfb я посмотрел.

Ну тогда API самого Directfb.

> Еще бы взглянуть на Nano-X. Но это разве как-то потом :)

Microwindows пробовал эдак с пол-года назад. Немного угловаты по ощущуениям от пользования, заморочки некоторые с фокусом окна и сменой режимов, при возврате в консоль приходилось вслепую набирать fbset 1024x768-75.

Зато для полутелевизора какого-нибудь, думаю, самое то.

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

Тема вообще-то была, что по этому поводу думает Линус. :) Еще не решили, что он об этом думает.

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

А, заменой иксам может стать разве 8 1/2, точнее, уже Rio. Но только в случае замены юникса Plan 9. Свое решение для своей среды, каждому свое, по-своему эффективное.

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

С иксами, придя на работу, я могу teleport'ом из дому перебросить на свой дисплей какую-то аппликушку из дому, которая должна у меня вертеться весь день. Архиудобно. И главное -- оно *уже* и придумано, и работает.

что ты подразумеваешь под teleport? ;)

$ apt-cache show teleport
Package: teleport
Priority: optional
Section: x11
Installed-Size: 128
Maintainer: Moray Allan <moray@debian.org>
Architecture: i386
Version: 0.33-3
Depends: libatk1.0-0 (>= 1.6.0), libc6 (>= 2.3.2.ds1-4), libdisplaymigration0, libgcrypt11, libglib2.0-0 (>= 2.4.1), libgpewidget1, libgpg-error0 (>= 0.7), libgtk2.0-0 (>= 2.4.4), libpango1.0-0 (>= 1.4.0), libsqlite0 (>= 2.8.13), libx11-6 | xlibs (>> 4.1.0)
Filename: pool/main/t/teleport/teleport_0.33-3_i386.deb
Size: 16966
MD5sum: 63ced7c5d95fb8b374eaf590c5e074a1
Description: moves running applications between displays
 Teleport allows some applications to be moved between X displays without
 being closed and restarted. It uses X properties to request that applications
 which support the display migration protocol move to another display.
 .
 The display migration protocol used by Teleport is currently best supported
 by applications belonging to the GPE Palmtop Environment.