Linux: In Kernel GUI

Непонятно. Майкрософт развивает проет Авалон - вынесение графики из ядра, в Линухе наоборот решается графику в ядро впендюрить. Или я чего не допонял?

судя по всему, надо эту графику "где-то посередине" оставить...

> Непонятно. Майкрософт развивает проет Авалон - вынесение графики из ядра, в Линухе
> наоборот решается графику в ядро впендюрить. Или я чего не допонял?

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

>Вот у меня есть компковский ноут с 32 метрами озу.

>Никакой кде там просто не работает, а например windows 98 работает

RH 5.0 c KDE 1.1 у меня именно на 32 мегах бегал .... всего на год старее 98=ой. на 16 запускался, но уже не бегал :). так шта не кизди штудентик.

Реестр еще туда! Реестр!!! Хотим ну чтоб совсем как в Вынь все было!!! :))))))

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

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

Блин... ну сколько можно... сказанно же было что FBUI позицианируется как GUI для встраиваемых систем и систем с ограниченными ресурсами... никто не заставляет использовать это на обычных машинах... НЕНРАВИТСЯ НЕ ЕШ!!!

отлично.
но зачем в ядро?
почему нельзя все то же самое, с теми же преимуществами в размере/скорости сделать отдельной библиотекой в userspace?
аргументация у автора по меньшей мере странная:
> I've put this code in the kernel as a preventative measure against software bloat. Most
> programmers have the tendency to produce ever-growing software, and if one wants to
> prevent unlimited growth, it is convenient to put the GUI in a place that does not
> tolerate it -- the kernel.

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

> Надо еще веб сервер в ядро засунуть - вопще чума будет по скорости.

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

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

Ой...

А жабку J2ME в ядро никак нельзя? Поспособствовать эмбеддингу, тысызыть... =)

ха, автор не позаботился о совместимости с иксами - в трубу
(кстати, там по речи пацан школьник какой то этот гуй пишет)

Никакие иксы ине тормоза. Утяни демо-версию коммерческих Accelerated X, скомпили их ядреную присадку xsvc.o под ядро свое (под 2.6 не знаю, получится ли?) и посмотри.

Я вам вот что дорогие вы мои скажу. Линух чем сейчас пытается стать? Правильно настольной ОС. Ну и зачем городить внутри системы клиент/сервер структуру? Нельзя ли дейсвительно простое устройство типа fb и чтоб единый интерфейс для гуйёв? Проще=лучше (с)

И в догонку: вот у меня разрешение ЛЦД 1680х1050. Нафиг мне в консоли стандартной мучатся если можно человечиские шрифты на человеческих разрешениях через fb?

>Надо еще веб сервер в ядро засунуть - вопще чума будет по скорости.

Уже давно...

>Ну и зачем городить внутри системы клиент/сервер структуру?

в настольной ОС должна быть кастрированная поддержка сети? по типу оффтопика? нафик

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

Ктому же я думаю что вынесение задачи X сервера в Ring0 неочень то уж прибавит скорости раз(для этого в иксах уже существуют всяческие DRI), и уж точно не прибавит надежности два.

Уже. khttpd; кажется, один из режимов у tux'а.

> Ктому же я думаю что вынесение задачи X сервера в Ring0 неочень то уж прибавит скорости раз(для этого в иксах уже существуют всяческие DRI), и уж точно не прибавит надежности два.

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

О! Идея! А что если сделать ФБ-шные ncurses ? Чем не виджеты? И аппликухи туда портануть консольные, но уже с новым лук-ен-фил ? Могет закучкуемся и попробуем ?

> Уже. khttpd; кажется, один из режимов у tux'а.

Однако саныч хорошо постебался, сколько народу повелось... =)

> О! Идея! А что если сделать ФБ-шные ncurses ? Чем не виджеты? И аппликухи туда портануть консольные, но уже с новым лук-ен-фил ? Могет закучкуемся и попробуем ?

Я не понял, это такой новый изврат: переписывать псевдографический гуй под fb? Зачем?? Что это даст принципиального?

> псевдографический гуй под fb

а не это ли именно сделано в графическом режиме links?

> Я не понял, это такой новый изврат: переписывать псевдографический гуй под fb? Зачем?? Что это даст принципиального?

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

Гуй? Да просто человек сделал возможность создавать несколько "областей ввода" на одной консоли.

> а не это ли именно сделано в графическом режиме links?

Не там просто двойной гуй - поскольку в графике размер растра иной.

сорри некорректно выразился

Там две реализации пользовательского интерфейса Размер знакоместа в графическом режиме нефиксированный.

>Ктому же я думаю что вынесение задачи X сервера в Ring0 неочень то уж прибавит скорости раз(для этого в иксах уже существуют всяческие DRI), и уж точно не прибавит надежности два.

Может пора уже на x86 не только два ринга использовать? Вроде проц позволяет.

Саныч, ты чего, http уже в ядре аж с 2.2.х :-)

> а не это ли именно сделано в графическом режиме links?

Не это. Там fb используется на полную катушку - таблицы там рисовать, картинки... а здесь зачем-то предлагают ncurses - саму библиотеку! - под fb перетащить.

> Во-первых изменится внешняя эстетика, добавится пресловутый АА.

Вот чего в консоли никогда было не нужно, так это AA. Там и так шрифты красивые по жизни.

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

А ты думаешь, иксы - это только графика? А как насчет буфера обмена между приложениями, например?

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

А если пользуешь - в текстовом режиме оно уже больше не пойдет? И ни на чем, кроме линуха, тоже?

> Вот чего в консоли никогда было не нужно, так это AA. Там и так шрифты красивые по жизни.

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

> А ты думаешь, иксы - это только графика? А как насчет буфера обмена между приложениями, например?

Я прекрасно понимаю, что иксы - это 30% граф дрова, остальное реализация протоколов обмена. Но тут имелось ввиду 1 консоль - 1 приложение. Видимо я некорректно мысли излагаю... попробую на примере. Как я себе это вижу... Мутт собранный не с ncurses, a c (допустим) fbcurses. Пущенный на /dev/ttyN работает с фб окна - рисуются с тенями (гадом буду такое с фиксированным знакоместом реализовать можно) шрифты сглаженные, диапазон цветов 16 битный, скроллинг плавный. Наворотов можно придумать немерянно. Тот же mutt с /dev/pts пускает привычный консольный интерфейс. Портировать имеющийся софт будет достаточно легко. Внешний вид GUI + функционал консольных аппликух иксы не нужны

> А если пользуешь - в текстовом режиме оно уже больше не пойдет? И ни на чем, кроме линуха, тоже?

В примере выше. А насчет имиджей - возвращаясь к примеру с мутью... Скажем патч позволяющий по From: перебирать алиасы с сылками на фото отправителей и отображающий их в окне mutt или в виде полупрозрачного региона поверх рабочей области. В случае запуска в текстовом режиме - функционал либо просто глушится, либо просто показывает что-то вроде [IMG:PETROVICH.JPG].

Остапа несло...... :)))))

Надеюсь получилось объяснить...

Но если интерес не "дискуссии ради" могу нарисовать что-то вроде макета. Я б сам за это взялся, но пока целиком не потяну - опыта маловато.

Диктую большими буквами: ЗАЧЕМ ГОРОДИТь СИСТЕМУ ТИПА Х СЕРВЕР? Почему пользователь персоналки (он же в 99% случаев ее владелец) не может на прямую писать в /dev/nvidia или /dev/ati или еще куда (ну или конечно в /dev/fb)?! А в ядре должен быть простая поддержка прорисовки на экране типа drawPixel, drawLine и т.д. А консоль подключать для rescue или для извращенцев или если fb не пашет.

А Х пусть для реальных (TCP по Ethernet, etc) сетей остается. На Апп сервере пусть крутится.

Вот.

> Диктую большими буквами: ЗАЧЕМ ГОРОДИТь СИСТЕМУ ТИПА Х СЕРВЕР?

А почему бы и нет, собственно? Зачем городить что-то другое?

> Почему пользователь персоналки (он же в 99% случаев ее владелец) не может на прямую писать в /dev/nvidia или /dev/ati или еще куда (ну или конечно в /dev/fb)?!

И чем это отличается от возможности писать в /tmp/.X11-unix/X0, к примеру?

Притом, что X protocol - известен и стандартен, а что писать в твои /dev/fb - это еще придумывать надо.

> А в ядре должен быть простая поддержка прорисовки на экране типа drawPixel, drawLine и т.д

Ты уверен, что она будет простой?

> Диктую большими буквами: ЗАЧЕМ ГОРОДИТь СИСТЕМУ ТИПА Х СЕРВЕР?

Еще раз внимательно перечитай - X сервер никто городить не собирается. Мало того я предлагаю обычную замену ncurses на его графическую реализацию, которая должна будет изменить внешний вид в лучшую сторону, не напрягая разработчиков которые писали софт под нкурсы.

что-то я туплю уже к вечеру совсем, наверное

если у меня в ядре CONFIG_FBCON_*=y, и грузится оно с vga=788, это по-вашему графическая реализация консоли, или нет?

какие выгоды можно получить от переписывания curses для fb? когда у меня nvidia какая-то была, в fb-консоли скроллинг был намного быстрее (ls -lr / например) и разрешение больше. других преимуществ не помню. а в curses-программах скроллинга-то не бывает

>если у меня в ядре CONFIG_FBCON_*=y, и грузится оно с vga=788, это по-вашему графическая реализация консоли, или нет?

Да, но по функционалу это обыкновенная текстовая консоль с большим колвом символов в высоту и ширину, более навороченная вещь - bootsplash. Я же просто предлагаю расширить возможности в плане оформления для консольных програм, а для удобства разработки/портирования повторить API ncurses. Грубо говоря функция box(mywin,0,0); Будет рисовать не псевдографическую рамку, а однотонный регион, или рамку, но со скругленными краями, или текстуру на выбор ?

> а в curses-программах скроллинга-то не бывает

Когда делают wprintw("blah blah blah") в заполненное окно - оно "отматывается" на строчку вверх. ОТматывание можно сделать не посимвольным, а попиксельным (по большому счету попса, но глазам приятнее).

Блин! Мужики 21-й век на дворе, а консольный софт до сих пор "ходит в шинели" 80x25, может пора дать ему нормальную "одежку" ?

Есть xterm. Зачем ещё что-то придумывать?

> Есть xterm. Зачем ещё что-то придумывать? А без Иксов он есть ? А что он дает по сравнению с обычной консолью? Что его таскать по экрану можно ?

Ладно или я не там вопрос поднял, или криво объясняю, или действительно "фффтопку".

> А без Иксов он есть ?

нет.

> А что он дает по сравнению с обычной консолью?

Например:

http://www.linux.org.ru/jump-message.jsp?msgid=192785

> Что его таскать по экрану можно ?

Ну так.

Ты не там вопрос поднял, IMHO
А мысль интересная. Надо будет подумать... :))))

2Loki

С тобой как сконтачится можно ?

> Никакой кде там просто не работает, а например windows 98 работает
Гы гы гы... Гонишь :-). KDE там будет работать. Даже любой, а не 98го года выпуска.

>Еще раз внимательно перечитай - X сервер никто городить не собирается.

Это ты меня не правильно понял. Я и говорю что надо Х оставлять для тех ситуаций где без клиент/сервер никак. А в однопользовательской системе должен быть простой и легковесный интерфейс для прорисовки окон, кнопок и тп. Вот нкурсы типа с наваротами и подойдут. А потом можно OpenGL доделать. Короче более простой, легковесный, прозрачный и быстрый аппарат графики.

Да! Извини! Вот я как раз о том и говорю. Что для однопользовательской среды такой интерфейс и нужен, просто предложил подогнать API под ncurses, дабы не осложнять портирование. А то этих FB-движков много, и каждый считает, что именно его движок правильный и имеет правильное API, а разработчики само собой в этом "винигрете" не кидаются не влево не вправо и пишут либо консольный софт под ncurses либо под X-ы. Но поскольку первые (ИМХО) не имеют товарного вида, а вторые в погоне за наворотами пухнут как дрожжи в ... золотая середина отсутствует. Опять же ИМХО: Будущее десктопного линуха именно за фрэймбуферными виджетами.

а как быть с уже существующим багажом приложений, расчитанных на X?
опять все выбросить и переписывать заново?
хочешь не хочешь, а Х протокол поддерживать надо.
кстати вы не пробовали Х-сервер из CVS-проектов DirectFB?
говорят на matrox-карточках он всякие прочие xfree рвет как тузик грелку
но на моем старом железе, увы, не поднимается :((

> Нет выбрасывать Х приложения ИМХО крайне противопоказано, все-таки основной смысл X-ов - тонкие клиенты. Нет не пробовал, но все остальное от DirectFB пощупал - понравилось, за исключением их реализации multiapplication mode, тут они начали городить обмен между приложениями, аналогично тому который предоставляет Xserver,но через примочку в ядре.

>Когда гуй в ядре, то эта шняга работает гораздо быстрее.

Конечно вся эта затея с внесением GUI в ядро напонимает Windows, но в любом случае у нас есть (и надеюсь останется) самое главное -- "право на выбор" (с) Гарик Сукачев