ReactOS поборется за государственные инвестиции.

А ты быстрее подергай :) белые поля же остаются

> Разные. Даже там где окон (венды) совсем не было

Я не про те окна которые в винде, а которые в любой графической ОС. (или вы знаете ОС без окон?)

Пог твоему компилятор собирает графические приложения медленее чем неграфические?

Таки медленнее. Пока хидеры Qt подсосутся по 1000 раз, можно сходить выпить кофе.

>(или вы знаете ОС без окон?)

А я родился не в 90х.

Таки медленнее.

Ууу..

Когда одна библиотека зависит от другой, но не дублирует ее функций, я не называю это оберткой. Обертка - это когда функционал дублируется. на xlib можно писать программы? можно, значит gtk дублирует его функционал. user32.dll, gdi32.dll, kernel32.dll - дополняют друг друга, в них РАЗНЫЙ набор функций, которые слабо зависят друг от друга.

Другими словами, вы не делаете разницы между функционалом, который предоставляет gtk для создания (т.е. отображения и управления соответствующим элементом), скажем, кнопки и подобным функционалом от xlib?

user32.dll, gdi32.dll, kernel32.dll - дополняют друг друга, в них РАЗНЫЙ набор функций, которые слабо зависят друг от друга.

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

А ты быстрее подергай :) белые поля же остаются

Откровенный гон, если честно. Я сижу в icewm и если начать максимально быстро таскать окно по рабочему столу (с фоновым рисунком, естественно), то визуально оно таскается с меньшими артефактами чем в windows на той же машине - причём это не оказывает никакого влияния на воспроизведение видео в соседнем окне. В очередной раз предлагаю подумать, что ваши проблемы, возможно, никак не связаны собственно с иксами

Кстати, практически все легковесные менеджеры окон (icewm, enlightenment, boxes и ещё 100500 штук) работают непосредственно с xlib. Так что ваше утверждение, что практически нет программ, использующих соответствующий api напрямую, на поверку также оказывается несостоятельным. Об этом тоже следовало бы подумать

Вот свои легковесные вм можете оставить. Они не для людей. Где значки на рабочем столе? где удобные графические настройщики всех этих менюшек? где удобный файл менеджер? где удобные эмуляторы терминала? Получается любая приличная программа (ФМ, эмулятор терминала) тянет гном или кде, стартует 5 минут (как полноценный ДЕ), да еще и не полностью интегрируется в остальное окружение.

Попробуй таскать не по рабочему столу а по стеку других окон.

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

Вот свои легковесные вм можете оставить. Они не для людей. Где значки на рабочем столе? где удобные графические настройщики всех этих менюшек? где удобный файл менеджер? где удобные эмуляторы терминала? Получается любая приличная программа (ФМ, эмулятор терминала) тянет гном или кде, стартует 5 минут (как полноценный ДЕ), да еще и не полностью интегрируется в остальное окружение.

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

Попробуй таскать не по рабочему столу а по стеку других окон.

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

Управление окнами, работа с клавиатурой, мышой и графикой - gtk полностью перекрывает и использует функционал xlib

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

У вас действительно тяжело с пониманием или вы под дурачка косите?

> Нет программ на чистом винапи, в каждой программе полно костылей вроде user32.dll, shell32.dll и прочих.

Это ты маху дал, user32.dll как и shell32.dll - как раз реализация самого что ни на есть WinAPI.

> в венде есть ужасный kernel32.dll и обертки над ним вроде MFC или юзер32.длл.

И опять маху дал. юзер32.длл ни разу не обёртка к кернел32.длл

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

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

4.2

Все процессоры интел прекрасно чувствуют себя с битами и байтами, и все эти ваши файлы, аттрибуты и прочие права доступа вертели на eax'е и ebx'ом раскручивали.

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

Значит просто мне на моих программах и моем железе не везло.

Еще раз. Я говорю что Иксы слишком наворочены с одной стороны (сетевая прозрачность), а с другой стороны слишком убоги (xlibs не пригоден для написания приложений). следовало бы втащить нормальный графический тулкит в сами иксы, что подняло бы производительность в несколько раз.

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

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

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

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

Файлы нужы исключительно конечным пользователям. Любые попытки сделать рабочую среду без возможности работать с файлом в том или ином виде обречены на неудачу, что мы можем видеть на примерах венды, макосиХ и прочих айфонов.

Значит просто мне на моих программах и моем железе не везло.

Скорее всего, дело в «обёртке». У меня, например, firefox беспощадно тормозит (интерфейс в том числе) - я им и не пользуюсь

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

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

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

Чего уж там - давайте тулкит вместе с иксами сразу в ядро

Это ты маху дал, user32.dll как и shell32.dll - как раз реализация

самого что ни на есть WinAPI.

:trollface:

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

разделяемых библиотек, не означает, что это не ядро.

От того что гтк и qt не входит в Xorg реализацию X11 не ддалет их менее частью как графического API линукса так и вообще API линукса.

xlibs не пригоден для написания приложений

xlib для этого вообще(то есть совсем) не предназначен. :D Но почему то то что kernel32.dll, сам по себе не предназначен, для написания приложений вам интуитивно понятно. А что xlib для этого не предназначен - вам не понятно :D

следовало бы втащить нормальный графический тулкит в сами иксы, что

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

Вы можете как то *обосновать* это утверждение или так и будете просто утверждать? :D

> От того что гтк и qt не входит в Xorg реализацию X11 не ддалет их менее частью как графического API линукса так и вообще API линукса.

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

Всегда ваш, кэп.

Пример систем без файловой системы: гуглопочта с гуглодоками. Там есть письма и документы, файлами они становятся только когда их скачиваешь. ФС появились задолго до реляционных баз данных, и до массового распространения сетей. Можно сказать что ФС - это пережиток эпохи древовидных баз данных с костылями в виде симлинков и хардлинков.

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

Да вы упоротый! венда - 80%, макос - 20%, айфоны - 50% коммуникаторов. Если вы это называете неудачей, то линукс даже не неудачная система.

Надо попробовать налабать чистый бенчмарк, рисующий что-нибудь простое на линуксе и на винде в 2D, и я верю что он покажет мою правоту :) Выбирайте тулкит для линукса, а под виндой я на winapi напишу :)

В идеале наверное можно выводить градиенты быстро-быстро часто-часто в разные области окна.

Написал простой.

http://imglink.ru/show-image.php?id=d4d3d121353c77b438e7157b2d4f9849

#define HEIGHT 255
#define WIDTH 800

unsigned int FRAMES = 0;

unsigned int PFRAMES = 0;
char buf[200];
VOID updateTime(HWND hWnd)
{
   static LARGE_INTEGER freq;
   static LARGE_INTEGER stime;
   static LARGE_INTEGER etime;
   if (FRAMES==0)
   {
      QueryPerformanceFrequency(&freq);
      QueryPerformanceCounter(&stime);
   } else
   {
      unsigned int fdelta = FRAMES-PFRAMES;
      QueryPerformanceCounter(&etime);
      LARGE_INTEGER tdelta;
      tdelta.QuadPart = etime.QuadPart - stime.QuadPart;
      stime = etime;
      LONGLONG fps = (static_cast<double>(freq.QuadPart)/static_cast<double>(tdelta.QuadPart))*fdelta;
      sprintf(buf,«%lld FPS, %lld PPS,%lld LPS»,fps,fps*HEIGHT,fps*HEIGHT*WIDTH);
      SetWindowTextA(hWnd,buf);
   }
   PFRAMES = FRAMES;
}


VOID OnPaint(HDC hdc,HWND hwnd)
{
   RECT rct;
   rct.top = 0;
   rct.bottom = HEIGHT;
   rct.left = 0;
   rct.right = WIDTH;
   Graphics graphics(hdc);
   for(int i=0;i<HEIGHT;++i)
   {
      Pen pen(Color(i,255-i,0,255));
      graphics.DrawLine(&pen, 0, i, WIDTH, i);
      //graphics.DrawLine(&pen, 0, 0, WIDTH, 0);
      ++FRAMES;
   }
   InvalidateRect(hwnd, &rct, FALSE);
}

http://dl.dropbox.com/u/6574349/bench0.1.7z сорцы для вижака+бинарник release. Кто смелый? кто портирует под любимый тулкит?

http://dl.dropbox.com/u/6574349/bench.PNG

Исправленный скриншот :) теперь цифра не такая фантастическая. Сорцы обновлены

>> следовало бы втащить нормальный графический тулкит в сами иксы, что

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

Вы можете как то *обосновать* это утверждение или так и будете просто утверждать? :D

Он же на делфи писал. Ты что.

К стати я не понял чего это он разошелся - сам то писал на VCL - куда уж оберточнее. И борландовский VCL что-то никто в kernel32.dll не затаскивал.

лицоладонь.

Ты хоть бы задумался на секунду над тем фактом что чтобы чем-то мерятся - надо хотя бы измерялку сделать нейтральную а не QueryPerformanceCounter

ой да вы задрали уже. Да гагно эта ваша винда, гагно!
Вот смотрите. Сколько народу переходит с гаг^Wвинды на линукс? Очень мало!
А с другой стороны, сколько народу переходит с линукса на винды? Таких вообще нет! Итого что имеем? Виндовс - самизнаетечто! Кто пришел на линукс, тот с него уже не уйдет. trollface.jpg

Я перешел с линукса на винды обратно :) По играм соскучился...

Под линуксом надо использовать _любой линуксовый апи с наносекундной точностью_. QueryPerformanceCounter делает 25 000 000 тиков в секунду, значит его точность - около 4х наносекунд. Я не знаю _кроссплатформенного_ апи такой точности.

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

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

Приходя домой, я в grub'e выбираю Windows 7 каждый день. Это мой осознанный выбор в пользу лучшего. Что тут непонятного? Таки когда/если линукс станет годной десктоп системой, я не куплю очередной Windows 100500, а вернусь обратно на линукс.

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

Угу, это делает их вообще не частью «апи линукса», тем более

«графического», а совершенно самостоятельными библиотеками,

использующими иксы как один из бэкендов.

Линукс как ОС *весь* состоит из самостоятельных библиотек, в таком коннтексте. Тот же Xorg во многом это самостоятельные библиотеки распостраняемые и разрабатываемые вместе по историческим причинам. :D

Проблема в том что до людей из мира вижуалвасика и виндовса это все не доходит. «Ну тупые»(С) По этому всякие линукс-юникс организации придумывают всякие LSB, Unix98, SysV и прочие стандарты. Каковые являются аналогом win32 API, только в мире линукс. То есть линукс API.

Опять же - в виндовсе нету отдельно графического API, потому что оно неразрывно входит в win32. В линуксе это не так. Но если мы вводим тьакой термин то это htp/qt + xlib + ещечтото. Но отрывать xlib от gtk *в этом контексте* бессмысленно.

Всегда ваш, кэп.

Ну обьясни это дельфятнику, чо, мне можешь не обьяснять.

Надо попробовать ...

А еще попробуйте доказать что XV это костыль.

Я не знаю _кроссплатформенного_ апи такой точности.

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

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

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

Например вот видео упомянули. Что, у вас в венде по прежнему смотреть видео с приемлемой скоростью на сравнимом железе можно только при помощи линуксовых кодеков и плееров? Хаха. А ведь пока не спортировали линуксовые плееры и кодеки на венду, хреново там было смотреть видео. Практически невозможно на более слабых машинках :D

Например пень 166mmx с XV позволял сравнится чуть ли не с 600-800мнгц пнем под вендой с точки зрения просмотра видео.

Вообще QueryPerformance... просто удобнее. Удобнее работать с целыми в лонглонге, чем с посиксовыми структурами. Если вы посмотрите код, там проводится большое число операций (100 кадров) и засекается суммарное время. Приближенные к IRL? Все тулкиты рисуют графические элементы (кнопки, текстбоксы) точками и линиями. Собственно это и есть производительность графической системы для 2д.

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

На 166 пне в линуксе тоже нельзя было смотреть видео. Независимо от, нужен был 300 мегагерц компьютер. Я это очень хорошо помню, потому что первый мой успешный опыт просмотра фильма в mpeg4 был в школе на селероне-300.

Мне срать, состоит линукс из отдельных библиотек или нет. Винду вон тоже можно разобрать до одной консоли. Дело в том что люди пользуются _сборкой_, и оцениваться должна сборка целиком. Для xorg сейчас аналогов на десктопе нет, так что библиотека это или часть ядра - абсолютно не важно, все равно заменить его невозможно. Стандарты LSB, Unix98,SystemV, POSIX - запутаны туманны и противоречивы. недавно вот читал маны по функциям select/poll - каждая существует в нескольких вариантах, поведение отличается на линуксах и бсд, и все это отличается от стандартов, кроме того свои косяки есть в GNU библиотеке. Да и сами стандарты противоречивы. Потому что эти стандарты писались яйцеголовыми для мертвых юниксов, они не отражают какую-либо существующую реализацию. Для Win32 api существует единая консистентная реализация. одни и те же программы более менее надежно работают на виндах с 95 по 7. Это о чем-то да и говорит.

На 166 пне в линуксе тоже нельзя было смотреть видео. Независимо от,

нужен был 300 мегагерц компьютер.

Я это очень хорошо помню, потому что первый мой успешный опыт

просмотра фильма в mpeg4 был в школе на селероне-300.

АХАХАХАХА. Мне только это не рассказывайте. Именно на 166mmx оно работало. Потому что xv, правильные кодеки и производительность видеоподсистемы линукса.

Понятно почему у вас это только на 300 мгц получилось - вендузятники и есть вендузятники :D

> Пример систем без файловой системы: гуглопочта с гуглодоками. Там есть ...

И никому она нахер не нужна, без возможности скачать аттач. В качестве идеальной системы без файлов ты маху дал. Самая «идеальная» система без файлов - игры на консолях. И даже там людям нужны файлы, потому что они _хотят_ иметь возможность манипулировать с сохраненными играми.

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

Да вы упоротый! венда - 80%, макос - 20%, айфоны - 50% коммуникаторов. Если вы это называете неудачей,

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

Мне срать, состоит линукс из отдельных библиотек или нет.

АХАХАХА. О как оказывается! Если тебе срать, отдельные там либы или нет, чего ты тогда к то что xlib отдельная от gtk либа прикопался? :D

У тебя наверное семь пятниц на неделе и двойные стандарты в одном лице - когда тебе выгодно тут же достаем отдельные либы gtk и xlib и начинаем ругать их за то что они отдельные.

А как моча в голову ударит, так внезапно пишем : «Дело в том что люди пользуются _сборкой_, и оцениваться должна сборка целиком». То есть уже не прикапываемся к xlib и не оцениваем ее отдельно от gtk,qt и cairo, а внезапно оцениваем всю сборку. Когда это выгодно в споре, да? :D

Ты короче уже или крестик сними или трусы надень :D Чего тебе оценивать «сборку» или таки по отдельности xlib c кернел32 длл? :D

> Линукс как ОС *весь* состоит из самостоятельных библиотек, в таком коннтексте.

Ничего подобного. Линук как ОС *весь* состоит из исходников ядра и системы сборки. А из библиотек состоят системы, базирующиеся на инфраструктуре проекта GNU.

Тот же Xorg во многом это самостоятельные библиотеки распостраняемые и разрабатываемые вместе по историческим причинам. :D

Ни по каким не «историческим причинам», а как часть единого проекта - Xorg. И библиотеки из этого проекта по замыслу его создателей должны ставиться полным комплектом.

Проблема в том что до людей из мира вижуалвасика и виндовса это все не доходит.

Проблема совсем не в этом. Люди из мира вижуалвасика и виндовса никак не могут найти эту блятскую видеоподсистему, на наличие и корректное функционирование которой они бы могли рассчитывать на любом дистрибутиве GNU/Linux.

в виндовсе нету отдельно графического API, потому что оно неразрывно входит в win32. В линуксе это не так. Но если мы вводим тьакой термин то это htp/qt + xlib + ещечтото.

А за каким хером мы «вводим такой термин», который полностью лишен содержания?

Но отрывать xlib от gtk *в этом контексте* бессмысленно.

Почему? GTK может прекрасно существовать без xlib, а xlib - без GTK. Это связанные, но не зависмые друг от друга вещи. Даже полная бредовость контекста этого не отменяет.

Ну обьясни это дельфятнику, чо, мне можешь не обьяснять.

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

> Мне срать

И по этому ты пришёл на ЛОР?

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

Нельзя. Ложь № 1.

люди пользуются _сборкой_,

Зверьсиди, ога.

Для xorg сейчас аналогов на десктопе нет

Ложь № 2.

так что библиотека это или часть ядра - абсолютно не важно

Ты дебил?

все равно заменить его невозможно.

ЛОжь № 3.

Стандарты LSB, Unix98,SystemV, POSIX - запутаны туманны и противоречивы.

Ложь № 4.

недавно вот читал маны по функциям select/poll - каждая существует в нескольких вариантах, поведение отличается на линуксах и бсд, и все это отличается от стандартов

Ложь № 5.

свои косяки есть в GNU библиотеке.

Ложь № 6.

Да и сами стандарты противоречивы

Частичный повтор лжи № 4.

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

Ложь № 7.

Для Win32 api существует единая консистентная реализация.

Ложь № 8.

одни и те же программы более менее надежно работают на виндах с 95 по 7.

Ложь № 9.

Это о чем-то да и говорит.

Это говорит о том, что ты редкостный и малограмотый пиздабол.

Для Win32 api существует единая консистентная реализация. одни и те

же программы более менее надежно работают на виндах с 95 по 7. Это о

чем-то да и говорит.

Это во первых говорит о том что каждая прога таскает с собой целую кучу своих библиотек. Что бы бороться с тем что на самом деле «единая консистентная реализация» возможность «надежно работают на виндах с 95 по 7» не обеспечивает. А в том же wince вообще никакой особой консистентности с остальным нет.

А на самом деле это говорит о то что венда разработана и контролируется одной компанией. Которая на 100% решает каким быть win32 апи. Что и обеспечивает консистентность и «единость».Хотите монополизма - ваше право, одна германия - один фюрер очень популярный был в свое время лозунг. :D А вот мы монополизма мы не хотим.

Мы хотим запускать линукс на том железе и тем способом как этого решим мы - потребители линукса, а не какой то там микрософт.

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

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

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

И есть ли на какой то элемент документация решать тому кто за этот ответственен. Хотите его заменить - ваше право. Но не удивлятесь тому что другие потребители услуг этого элемента никаких замен не хотят :D

Ничего подобного. Линук как ОС *весь* состоит из исходников ядра и

системы сборки. А из библиотек состоят системы, базирующиеся на

инфраструктуре проекта GNU.

Линукс как ОС это не линукс как ядро. Нету никакого устоявшегося термина - для простого потребителя «линукс», это то, что часть линксоедов называют gnu/линукс.

Ни по каким не «историческим причинам», а как часть единого проекта

- Xorg. И библиотеки из этого проекта по замыслу его создателей

должны ставиться полным комплектом.

Конечно-конечно. Единость этого проекта - это исторические причины и есть. Xaw там в принципе нафиг не нужен, например. Если бы не определенные исторические и организационные коллизии, gtk, cairo и тп давно бы могли бы стать частью Xorg, а Xaw был бы выкинут нафиг.

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

Проблема совсем не в этом. Люди из мира вижуалвасика и виндовса

никак не могут найти эту блятскую видеоподсистему, на наличие и

корректное функционирование которой они бы могли рассчитывать на

любом дистрибутиве GNU/Linux.

Ты про что вообще сейчас?

А за каким хером мы «вводим такой термин», который полностью лишен

содержания?

Он не лишен содержания - это gnulinux32/64 API и есть. То что в нашем коммунити пользуются другим набором терминов - это те же самые исторические причины.

Но отрывать xlib от gtk *в этом контексте* бессмысленно.

Почему? GTK может прекрасно существовать без xlib, а xlib - без

GTK. Это связанные, но не зависмые друг от друга вещи. Даже полная

бредовость контекста этого не отменяет.

То что оно может существовать отдельно, не значит что оно должно существовать отдельно, особенно в конкретном контексте.

С точки зрения прикладного программиста есть графическая подсистема у которой есть API. То что оно внутри бьется на куски и может быть переконфигурируемо - к вопросу «почему не пишут на xlib» не относится. Прикладные приложения под gnulinux32/64 не пишут на xlib потому что xlib для этого не предназначен - это низкий уровень. Точно так же как прикладные приложения на gnulunux32/64 не пишут прямо на ядре, а используют libc.

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

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

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

API это множество библиотек и некая черная магия, множество библиотек это API.

> Нету никакого устоявшегося термина - для простого потребителя «линукс», это то, что часть линксоедов называют gnu/линукс.

Есть. Это либо название конкретного дистрибутива, либо их общее наименование - GNU/Linux. А для «простого потребителя» и Андроид - линукс. Ну ты же не домохозяйка? Хотя... > 90% комментов у тебя в толксах.

Он не лишен содержания - это gnulinux32/64 API и есть.

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

API это множество библиотек и некая черная магия, множество библиотек это API.

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

Я утверждаю что и то и другое всего лишь модель восприятия.

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

У него болезнь «единое апи» головного мозга у тебя болезнь «это все библиотеки» головного мозга.

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