[печаль] Абстракция

IT c джавой попутал

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

хорошие примеры: Tk, Snack

Я вижу еще вариант похожий на JSR, только нужно хорошо постараться писать стандарт, иначе начнутся абстракции над абстракциями и выше. Это тяжело сделать на студентоплатформах, хотя им это так же нужно

переписать всё заново, потом звать маму

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

Linux kernel альтернативу еще не написали? Ну и кому от этого плохо?

Кроме кошмарного жабского логирования еще примеры будут?

ORM, веб-технологии, кодеки

Ты конкретику давай. Выше перечисленное, хорошие, годные абстракиции. Срывай покровы@обнажай напластования ненужных оберток.

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

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

и как всё персональными велосипедами закончилось.

pango -> xft -> freetype. Не вижу ни одного велосипеда. Каждый занимается своим делом.

Linux kernel альтернативу еще не написали?

Linux Kernel - само альтернатива.

>Linux Kernel - само альтернатива.
Именно. Безальтернативная альтернатива. Но в единственном экземпляре она всех устраивает.

Есть ещё *BSD всякие, как минимум. Ну и, там, HP-UXы c QNXами. И ими даже пользуются.

Есть ещё...QNX

это не альтернатива, это несколько другая область. альтернативой QNX будет для vxWorks или LynxOS

> Кроме кошмарного жабского логирования еще примеры будут?

Вот текущий пример, с которого я офигеваю в данный момент:

Есть 4 типа панелей для апплетов, не совместимые между собой: gnome2-panel, xfce-panel, панель из свежей убунты (юнити?), lxpanel.

Апплеты типа AppIndicator могут встраиваться в панель юнити и в gnome2-panel через промежуточный proxy-апплет. Апплеты gnome2-panel могут встраиваться через слой совместимости в xfce-panel.

Также есть трей, на апплеты которого существует отдельная спецификация. Прокси-апплет для встраивания объектов трея есть под каждую панель отдельный.

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

Есть globalmenu (который использует иксы для передачи меню приложения), серверная часть которого существует в вариантах для gnome-panel, xfce-panel и lxpanel.

Есть appmenu, который точно такое же, но другой. Потому что работает через dbus и серверную часть имеет только в виде AppIndicator-а. (И еще, кажется, под кедами.)

В Gnome2 есть свой лисапедик для хранения недавно открытых документов, а в Gnome3 используется уже целый лисапедище на движке zeitgeist.

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

...И это мы еще KDE не начали рассматривать. :D

Или Linux-RT. http://www.linux.org.ru/forum/talks/6630972, опять же.

s/потоков/протокол/

> ...И это мы еще KDE не начали рассматривать. :D

И ещё интересно рассмотреть, как всё это соотносится с тем, что написано на freedesktop.org.

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

Про «X Font Server» напомнить? Да и далеко не все используют xft и тем более pango.

RT вообще не нужно, а нужна минимальная latency

Эээ... Объясните чайнику, а, разве, не первое ради второго?

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

> > RT вообще не нужно, а нужна минимальная latency

Эээ... Объясните чайнику, а, разве, не первое ради второго?

Ну всё, RT-срач готов к старту.

По всеобщему признанию местных жителей - они альтернативой не являются.

Согласен. Но заметь, чем гуевее абстракция тем хреновее разработчик ее делающий, поэтому ничего удивительного нет. Если опуститься на уровень ниже, где люди хоть немного думают, то всё совсем не так печально. Есть иксы, NetWM, EWHM, если не ССЗБ, просто опирайся на них и всё будет пучком.

А эти неадекваты пускай дальше упарываются своими апплетами и глобальными меню. Еще люто повеселимся, когда вейленд выйдет.

Про «X Font Server» напомнить?

И, где мегатонны оберток которые покрывают его слоями велосипедных абстракций? А особенно приложения его использующие. Было и прошло, как говориться.

Эээ... Объясните чайнику, а, разве, не первое ради второго?

нет. первое - это гарантия отклика приоритетного процесса в системе: полностью вытесняемое ядро, минимальное время запрета исключений, исключение инверсии приоритетов. достигается это не за бесплатно, общая производительность падает, а стало быть падает и latency

> нет. первое - это гарантия отклика приоритетного процесса в системе: полностью вытесняемое ядро, минимальное время запрета исключений, исключение инверсии приоритетов. достигается это не за бесплатно, общая производительность падает, а стало быть падает и latency

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

для низкоприоритетных — растёт

это, интересно, почему?

Хм. Почему для низкоприоритетных растёт гарантированное время отклика? Ну надо полагать, потому что они низкоприоритетные.

потому что они низкоприоритетные

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

> один чёрт общесистемная задержка будет выше, чем для честного шедулера

У меня вот, скажем, идёт копирование файлов через FUSE и компиляция. И как вокруг CFS не пляши, а указать ему, что этим процессам вообще быстрый отклик как таковой не нужен, и что можно забивать на их выполнение, когда другие процессы готовы в очереди — никак не получится. И выходит, что страдают от них _все_ остальные процессы, при чем ощутимо страдают, вплоть до лагов ввода текста в редакторе. А вот «нечестными» строгими приоритетами исполнения я бы эту проблемы решил на раз.

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

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

во-первых, о десктопе речи не было

страдают от них _все_ остальные процессы

а во-вторых, в случае RT-системы от приоритетных процессов у тебя с тем же успехом будут страдать все остальные. и лаги ввода текста в редакторе будут только выше - можешь оценить отзывчивость фотона в QNX на практике, например (а там Hard RT, между прочим)

> а во-вторых, в случае RT-системы от приоритетных процессов у тебя с тем же успехом будут страдать все остальные.

От приоритетных, а не от запущенных с nice 19.

а там Hard RT, между прочим

Да вот только взаимодействие с пользователем — это по своей сути SRT задача с динамическим планированием.

От приоритетных, а не от запущенных с nice 19.

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

взаимодействие с пользователем — это по своей сути SRT задача с динамическим планированием

это несколько нетривиальная задача

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

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

> SRT

http://dl.acm.org/citation.cfm?id=136559

Scheduling of Hard Real-Time

Дальше не читал.

> А эти неадекваты пускай дальше упарываются своими апплетами и глобальными меню. Еще люто повеселимся, когда вейленд выйдет

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

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

Пусть покажут мне панель задач и оконный менеджер для вейнланда. А я поржу.

> Знаешь, между системой с жесткими приоритетами и системой с CFS я определенно выберу первую. Потому что, хотя они оба отвратны для десктопа, на первой я _могу_ влиять на выполнение задач, а на второй мудрые математики уже всё за тебя решили.

тебе же русским по белому написали, что про десктоп речи не было.

а зачем ты это здесь написал?

Как зачем. «Технологии» же собрались переписывать. WM какой-нибудь вменяемый уже осилили портировать? :D

Дальше не читал.

как будто Dynamic SRT в лучшем состоянии

я определенно выберу первую

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

> тебе же русским по белому написали, что про десктоп речи не было.

Лол, а про что было? Речь, напомню, шла про время отклика. А раз критично время отклика — значит разговор идёт о ЖРВ, либо о МРВ задачах. А рисовать гуй без лагов — это типичный пример МРВ задачи.

Парадоксально: системы, которые создаются, чтобы гарантировать малое время отклика, на самом деле увеличивают время отклика. Хорошая орруэловщика, ящитаю.

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

P.S. а вобще меня, как пользователя в X всё устраивает.

тебе же русским по белому написали, что про десктоп речи не было.

мне уже кажется, это очередной срач ради срача, reductio ad rectum. какая разница, о чём речь?

пойду лучше чаю выпью

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

Давай я лучше тебе расскажу о впечатлениях от работы на CFS при компиляции в фоне. У меня много их, этих впечатлений. :)

> Речь, напомню, шла про время отклика. А раз критично время отклика — ...

Минимализация среднего времени отклика != гарантия максимального времени отклика.

Парадоксально: системы, которые создаются, чтобы гарантировать малое время отклика, на самом деле увеличивают время отклика. Хорошая орруэловщика, ящитаю.

не понимаю, что тебе не нравится, скорее всего неуверенное знание матчасти.

> При этом я не вижу связи с текущем положением вещей.

Это заметно.

Hint: WM, таскбары, треи, переключатели рабочих столов и прочая оснастка по управлению окнами работает без всяких тулкитов, напрямую юзая средства ICC иксов. Которых в вейланде нет. И в принципе быть не может. Совсем не может.

> Минимализация среднего времени отклика != гарантия максимального времени отклика.

Выдохни и сформулируй еще раз. По-русски.