Здравствуйте, Cyberax, Вы писали:
>> аудиторию. А даже если юниксоиды сюда забредают, то спорить с целой >> толпой мастодонтов уровня AVK им трудно C>Тогда посоветуйте, плиз, форум где юниксоидов-программистов больше.
Список рассылки по выбранному дистрибутиву.
glyph wrote: > Vi is a must для администратора, т.к. vi идет в подавляющем большинстве > дистрибутивов как часть базового комплекта. Исключением могут являться > дистрибутивы LFS, некоторые мультимедийные live-cd. emacs же приходится > доставлять.
И более того, он там тоже есть (посмотрел в дохлом LFS, который всё не
соберусь настроить, и в книге LFS)..
Кстати, вопрос — от любителя ViM защитнику emacs.
Оно того стоит переходить? Сейчас я, скажем, написал себе мелкие
расширения типа tabbed editing для ViM. Я готов от этого на время
отказаться, если есть перспектива большего удобства и инструментария.
PS. Чаще общаюсь с теми, кто знает назначение всего алфавита в ViM, чем
с любителями Emacs.
glyph wrote: > C>>>Кроме исходников есть еще и всякие документы с тех. заданиями, отчетами > C>>>и т.п. _Очень_ удобно бывает выделить табличку в Excel'е и вставить > ее в > C>>>Ворд, или из MS Project'а вставить отчет, а из Visio — иллюстрацию. > A>>Ну для этого OpenOffice есть... > C>В нем не все есть. В частности нет аналога MSProject'а и Visio. Причем > C> самое приятное в Виндовом OLE — это возможность интероперирования разных > C> программ. Так что, ИМХО, сейчас в области десктопных приложений Винда > C> себя ведет более Unix-way, чем сам UNIX.
Unix-way — это когда всё, что надо редактировать, можно редактировать в
текстовом редакторе уровня pico. > Какое-то нелогичное утверждение. Простой пример. Фотошоп (или Ворд). Мне > надо открыть файл и изменить яркость (заменить вхождения некоей строки). > Я могу это сделать с одним файлом. Без напрягов. Как мне то же самое без > напрягов сделать с 1000 файлов? Работа единоразовая, так что ваять > что-то на С будет дольше. > Это не частная проблема Windows. Это общая проблема GUI в стиле Windows. > Холиварз какой-то получается...
Для справедливости признаем, что там скрипты есть в обоих приложениях.
Правда в каждом приложении свои. И я не умею пользоваться ни теми, ни
другими, но вроде бы они не сложны.
glyph wrote: > A>Вот здесь <http://aka50.narod.ru/linux.html> как раз от таких как Вы. > (к сожалению автора не знаю, > К статье могу добавить собственных наблюдений.
Есть там вопросы из рейтинга "100 вопросов: какого?". Есть явно
нечестные ходы: FAQ читать — вспоминаю как в первый раз настраивал Х.
GIMP под винду есть и почти работает. И вообще порты половины всего под
Windows есть. И выключение по POWER у меня не мгновенное в Linux
(правда, это я настроил). И читать xml от ooffice радость та ещё (лучше,
чем Word, но...). Но, конечно, список "а что сделал MS для троянов" там
есть. И реестр правильно обложен (Ау-у! где INI-файлы Windows 3.11?).
ЯпонИц wrote:
> C>Потому что только Apple производит Маки и продает их уж по очень > высокой > C>цене. > Ну так это цена хорошего продукта, Вы же хотите все как на маках, но > под GPL.
$2000 — за средненький комп это уже СЛИШКОМ много. Хотя самый большой
недостаток в Маках — это несовместимость аппаратной платформы с x86
(хотя эта проблема скоро разрешится).
> C>Это уже прошлое, если бы его портировали под Win32, то тогда может > C>сейчас бы его все искали под Линуксом. > У меня Win32 версия ДосНавигатора
Насколько я помню, его скомпилили под Win32, но не делали никаких особых
добавлений.
> C>Вы пробовали? Я вот пробовал: ставил Линукс ученым из местного > института > C>физики. В итоге я раз в неделю к ним сейчас прихожу и правлю разные > C>глюки, которые недоступны из гуевых утилит. > То что глючность можно исправить из ГУИ не есть достоинство... Хотя > наличие глюков конечно недостаток.
Достоинство, причем очень большое. Особенно для новичков или малоопытных
юзверей.
> C>А больше Линуксом на десктопе никто и не пользуется... > Ну так я и не говорил что Линукс — это десктоп-решение всех проблем, > но и его можно использовать ддя некоторых целей, например как > текстовый редактор.
"ЮНИКС — гениальная система для обработки текстов" (с) не помню.
> Вот Вы к примеру по какой причине перешли на Линукс?
Я не перехожу — основная разработка у меня идет под Виндой. Просто
теперь еще нужно разрабатывать софт под Линуксом, так что надо изучать
девелоперские тулзы для него.
Ну и просто интересно — чего же там за столько лет придумали Юниксоиды
для разработки софта.
Здравствуйте, Cyberax, Вы писали:
C>ЯпонИц wrote:
C>Достоинство, причем очень большое. Особенно для новичков или малоопытных C>юзверей.
Вот только эти новички даже в Винде при малейшей проблеме просят помочь...
>> C>А больше Линуксом на десктопе никто и не пользуется... >> Ну так я и не говорил что Линукс — это десктоп-решение всех проблем, >> но и его можно использовать ддя некоторых целей, например как >> текстовый редактор.
C>"ЮНИКС — гениальная система для обработки текстов" (с) не помню.
Ну и Виндовс прославился благодаря наличию Ворда.
>> Вот Вы к примеру по какой причине перешли на Линукс?
C>Я не перехожу — основная разработка у меня идет под Виндой. Просто C>теперь еще нужно разрабатывать софт под Линуксом, так что надо изучать C>девелоперские тулзы для него.
C>Ну и просто интересно — чего же там за столько лет придумали Юниксоиды C>для разработки софта.
Изобрели много чего, но все мелкое и заточено слишком специфично.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Я не волшебник, я только учусь.
Posted by RSDN@HOME.
glyph wrote:
>> > Единый формат конечно не помешает, но вот Х менять нет необходимости, >> > хорошая штука. Просто она была создана больше для возможности работы с >> > терминалов, чем для получения удобного графического интерфейса. > C>Чем эта "штука" хороша? Тем что каждая графическая команда (например, > C>рисование линии) должна пройти через пару переключений контекста? > Да никто никогда и не говорил, что это "хорошо" или "плохо". > Встравивание графики в ядро противоречит Unix-way. Ну как такое ядро > потом переностиь на другую архитектуру? А если там графика вообще не нужна?
Более того, по-моему графика попала в ядро Форточек от отчаянья. Никакой
принципиальной технической необходимости ее туда пихать в природе не
существует, и пример X11 это прекрасно доказывает. X11 вполне сравним по
производительности с Форточками, если сравнивать в равных условиях. Если
Форточки чего и выигрывают, это не от идей засунуть графику в ядро, а от
более качественный видеодрайверов, что объясняется опять же не
технически, а тем, что производители видеокарт не раскрывают достаточно
информации для написания качественных опенсорсовых драйверов.
glyph wrote:
> C>В нем не все есть. В частности нет аналога MSProject'а и Visio. > Причем самое приятное в Виндовом OLE — это возможность > интероперирования разных программ. Так что, ИМХО, сейчас в области > десктопных приложений Винда себя ведет более Unix-way, чем сам UNIX. > Какое-то нелогичное утверждение. Простой пример. Фотошоп (или Ворд). > Мне надо открыть файл и изменить яркость (заменить вхождения некоей > строки). Я могу это сделать с одним файлом. Без напрягов. Как мне то > же самое без напрягов сделать с 1000 файлов? Работа единоразовая, так > что ваять что-то на С будет дольше.
var theApp=new ActiveXObject("Word.Application");
//Используется наш компонент, который позволяет красиво создавать
// выборку файлов. По желанию заменяется на что-нибудь другое.
var filez=new ActiveXObject("EleWise.FileEnumerator");
filez.showSelectionDialog();
for(var f=filez.enum();!e.atEnd();e.moveNext())
theApp.OpenDocument(f.name()). ....; //Ну и делайте все, что вам там
нужно...
Я же говорю, OLE2 — это полный Unix-way. При этом мне не надо думать о
формате файлов и т.п. А вот вам придется с этим разбираться.
> C>Вроде разобрался с xRefactory, после шаманских танцев с заголовками > GCC у меня стал индексироваться весь проект. Так что сейчас на ночь > читаю книжку по Emacs'у... > Документация особенно хороша.
Я все лучше начинаю понимать elisp, после настройки cedet и xref...
Pzz wrote:
>> Да никто никогда и не говорил, что это "хорошо" или "плохо". >> Встравивание графики в ядро противоречит Unix-way. Ну как такое ядро >> потом переностиь на другую архитектуру? А если там графика вообще не > нужна? > Более того, по-моему графика попала в ядро Форточек от отчаянья. Никакой > принципиальной технической необходимости ее туда пихать в природе не > существует, и пример X11 это прекрасно доказывает.
Пример X11 показывает, что такой подход, простите, сосет по полной на
современных графических архитектурах. Это поняли и Apple и даже Microsoft.
И даже отмазка "Xы убрали из ядра, чтобы все было более устойчиво" — не
катит, так как Xы крайне легко вешают всю систему при неправильной
работе с видеоадаптером.
> X11 вполне сравним по производительности с Форточками, если сравнивать > в равных условиях.
Агащаз. Посмотрите-ка фильм в каком-нибудь проигрывателе с выключенными
расширениями типа DRI. О впечатлениях расскажете. Да забыл, еще
попробуйте потом посмотреть фильм через удаленный терминал, а потом
расскажите о "сетевой прозрачности" Xов.
Я присылал ссылку на статью Гослинга, где как раз говорится о том, что
дизайн Xов устарел лет на 10. Он был разработан для конца 80-х годов,
когда не было крутых графических карт и многие юниксы не поддерживали
динамические библиотеки. Из-за этого при работе с Xами на каждый вызов
происходит ТРИ или даже ЧЕТЫРЕ переключения контекста (в сервер Xов,
потом в контекст ядра, потом обратно в Xы, и в приложение), да еще и
требуется маршаллинг/демаршаллинг аргументов вызова. В конце 80-х это
было нормально, так время рисования на тогдашних карточках делало
остальные затраты небольшими в сравнении.
Но в нынешних графических акселераторах есть мощные средства рисования,
все важные ОС поддерживают динамические модули, и стало вполне можно
напрямую отображать видеоповерхности адаптера напрямую в память приложения.
Поэтому изначальный дизайн Xов стал совсем неадекватен. Естественно,
сами юниксоиды это понимают, так что появилась целая куча расширений
(DRI и Xrender), которые позволяют обойти громоздкий механизм Xов или
хотя бы сделать его более оптимальным. Естественно, это ведет к
дальнейшему усложнению и так уже непростой архитектуры Xов.
В Apple'е это поняли, и вместо извращений с Xами просто сделали
полностью новую графическую архитектуру, в которой приложения напрямую
могут работать с функциями адаптера. Ну и поверх этого слоя сделали
Xовый сервер для старых приложений. Из-за этого сейчас на Маках самый
приятный графический интерфейс — он не тормозит.
В Винде изначально GDI был сделан эффективнее Xов, так как не
заморачивался с сетевой прозрачностью. При вызове функции GDI происходит
переключение в контекст ядра (при этом аргументы графической функции
маршалятся), в ядерном режиме происходит рисование, а потом происходит
возврат в контекст приложения. Но даже и такая архитектура стала слишком
неэффективной в 90е годы, так что появился DirectDraw (сначала в
GameSDK, потом GameSDK переименовали в DirectX). Первая версия
DirectDraw по сути позволяла только отображать видеоповерхности в память
приложения, и ничего более. Затем появился Direct3D, который рендерит
трехмерные сцены на поверхности DirectDraw и DirectShow, который может
рендерить видео. В районе 8го DirectXа произошло объединение DirectDraw
и Direct3D, а в Windows Vista планируется замена GDI на DirectX.
И только юниксоиды продолжают заниматься сексом с Xами....
glyph wrote:
>>> Ну не ходите вы сюда... зачем вам это? > C>Софт писать надо, однако. > С таким подходм лучше софт не писать вообще. По крайней мере, для Unix. > Я не ратую за программирование под Юникс в медитативном трансе, под > пение мантр, в комнате, обклееной коанами на рисовой бумаге. Однако я > так же против постановки личности в центр мироздания. Вполне можно > было поинтересоваться, как работают окружающие в эмаксе, в vim или в ed.
Я видел как работают окружающие — в основном они пишут в vim/emacs
простые скрипты. Мне же надо писать крупный проект — вот и интересуюсь
как это делается.
>>> Либо принимайте философию данной ос либо сидите в Вынь и оттуда > C>Плоха та ОС, которая заставляет работать в своем стиле... > Как раз эта ОС не заставлят работать в своем стиле. Девиз Unix всегда > был "mechanism, not a policy".
Ага, конечно.
> C>Сейчас так и делаем — пишем и отлаживаем под VS, nix-овые вещи > тестируем > C>под mingw, а потом собираем на Линуксе. > ?? > Что мешает их сразу собирать и тестировать под Линуксом?
Ошибки отлаживать сложнее. Локалько оно все и работает быстрее, и
отлаживается лучше.
> У вас системный администратор с достаточной кривизной извилин есть? > Может, посоветуйтесь, он просто не может не знать, как вам облегчить > жизнь...
Про сборку через ssh все у нас знают, не беспокойтесь. Вот только
неудобно это.
> C>Вот только под Линукс нету FARа (главный минус Линукса) и VS. > C>Нормального Cut&Paste с OLE-объектами тоже нет (и его жутко не хватает). > В Индию.
Покажите мне работающий FAR и OLE под Линуксом (и не внутри
vmware/wine), а потом хоть в Антарктиду.
C>Я видел как работают окружающие — в основном они пишут в vim/emacs C>простые скрипты. Мне же надо писать крупный проект — вот и интересуюсь C>как это делается.
Ну хорошо. Отвечу. Как человек, относительно недавно занимавшийся разработкой и
поддержкой проекта размером примерно в несколько сотен мегабайт исходных
текстов — и отвечавший за пару десятков этих мегабайт, и сколько-то единиц
мегабайт написавший и отладивший лично.
Если вкратце, то так (я): vim + plugins (много плагинов) + ctags (общие на
весь проект и пересобиравшиеся с nighly builds). Плюс лично я очень любил к
виму делать кодогенерящие/кодооблагораживающие расширения на perl. С некоторых пор, для
меня в редакторе одна из важнейших фич — это умение взять часть текста, скормить ее в
STDIN сторонней программе, а STDOUT вставить обратно. Контекстная допечатка, кстати,
была. И навигация по коду. Остальные участники группы — кто в чем. Кто в vslick,
кто в nedit. База ctags была общая на всех.
И все прекрасно разрабатывалось. И сейчас разрабатывается. Со времени этой разработки,
у меня есть уверенность в том, что навороченные IDE — от лукавого. Код должен писать не я,
с использованием каких-то мутных костылей, а его должны писать за меня скрипты, которые пишу
я
C>Про сборку через ssh все у нас знают, не беспокойтесь. Вот только C>неудобно это.
Чем?
>> C>Вот только под Линукс нету FARа (главный минус Линукса) и VS. >> C>Нормального Cut&Paste с OLE-объектами тоже нет (и его жутко не хватает). >> В Индию.
C>Покажите мне работающий FAR и OLE под Линуксом (и не внутри C>vmware/wine), а потом хоть в Антарктиду.
Нету. И верите — нафиг не вперлось. Который год. Видимо, не вперлось большинству,
иначе бы сделали. Что касается работы с ssh / ftp / samba (ну или как там называются виндовые шары) —
файловые системы ssfs, lufs, smbfs настолько удобны, что мне больше и не надо.
Особенно, после появления fuse. Что касается озвученных проблем (время таймаута) — да, я сталкивался,
но они решаются на уровне настроек и организации работы.
Удобная консоль если привыкнуть — заруливает файловый менеджер в минуса. Под юникс он просто особенно
не нужен. Я им пользуюсь только иногда, и только гуевым — потому что в 99% случаев я там работаю
с большим количеством картинок — и мне удобно видеть их превьюшки в виде иконок.
Что касается OLE. Если он вам для автоматизации и скриптования — то просто надо привыкнуть, что это
делается здесь по другому. Что до передачи данных, то это отдельная тема, конечно. В простых
случаях неплохо работает. В сложных — ит депендс.
glyph wrote:
> C>Вот уж насчет потребления памяти и скорости работы — Винда пока без > C>вариантов выигрывает у KDE/GNOME. Загруженная XP прилично работает на > C>P233/128Mb — сам лично работал, а на P433/256Mb она вообще летает без > C>всяких проблем. > Хы, насколько мне известно, не работают в режиме ядра.
Работают, работают. Иначе как бы они доступ к аппаратуре современных
ускорителей получали? Поэтому, кстати, глючные Xовые драйверы (для ATI,
например) замечательно завешивают всю систему.
> C>Конечно, под Линукс есть оконные менеджеры, которые займут памяти > C>намного меньше, чем Винда. Но вот только пользоваться ими могут только > C>профессионалы. > Да не сказал бы. Как раз маленькими менеджерами легче пользоваться > т.к. там из функциональности — джентельменский набор.
Людям, переходящим с WinXP — не легче.
>>> Единый формат конечно не помешает, но вот Х менять нет необходимости, >>> хорошая штука. Просто она была создана больше для возможности работы с >>> терминалов, чем для получения удобного графического интерфейса. > C>Чем эта "штука" хороша? Тем что каждая графическая команда (например, > C>рисование линии) должна пройти через пару переключений контекста? > Да никто никогда и не говорил, что это "хорошо" или "плохо". > Встравивание графики в ядро противоречит Unix-way.
Чем? Почему тогда файловая система и драйверы устройств не работают вне
ядра? Чем графика фундаментально отличается?
> Ну как такое ядро потом переностиь на другую архитектуру?
Ну так графику тоже надо будет переносить. Какя разница: переносить
ядерные модули или user-level код?
> А если там графика вообще не нужна?
Ну так не вкомпиливать ее просто (выключить модуль в конфигурялке) и все
дела.
>>> Можно конечно пользоваться в них только командной строкой, но ведь >>> пока не изучишь ОС не знаешь что есть не только окна. > C>Ну да, Линукс заставляет каждого новичка копаться во внутренностях > скриптов. > Не надо путать праведное с правильным. Линукс — это ядро.
Хорошо: не Линукс, а GNU/Linux.
> Дистрибутив — это ядро с набором софта. Дистрибутиво тьма. И в > зависимости от составителя дистрибутива сильно варьируется потребность > в ковырянии внутри скриптов.
glyph wrote:
>>> аудиторию. А даже если юниксоиды сюда забредают, то спорить с целой >>> толпой мастодонтов уровня AVK им трудно > C>Тогда посоветуйте, плиз, форум где юниксоидов-программистов больше. > Список рассылки по выбранному дистрибутиву.
У меня Debian и Gentoo — там в архивах списков про С++ мало что есть.
Cyberax wrote:
> glyph wrote: > >> C>Вот уж насчет потребления памяти и скорости работы — Винда пока без >> C>вариантов выигрывает у KDE/GNOME. Загруженная XP прилично работает на >> C>P233/128Mb — сам лично работал, а на P433/256Mb она вообще летает без >> C>всяких проблем. >> Хы, насколько мне известно, не работают в режиме ядра. > Работают, работают. Иначе как бы они доступ к аппаратуре современных > ускорителей получали? Поэтому, кстати, глючные Xовые драйверы (для ATI, > например) замечательно завешивают всю систему.
Работают в режиме ядра драйверы, а не модули самого KDE по рисованию
окон (отдающие, впрочем, много работы драйверам). А опасные драйверы от ATI — это да.. Меня они заставили поставить DRI.
>> C>Конечно, под Линукс есть оконные менеджеры, которые займут памяти >> C>намного меньше, чем Винда. Но вот только пользоваться ими могут только >> C>профессионалы. >> Да не сказал бы. Как раз маленькими менеджерами легче пользоваться >> т.к. там из функциональности — джентельменский набор. > > Людям, переходящим с WinXP — не легче.
Первый час под XP я потратил на отключение различий с Windows98
(Luna-парк, вид меню...). Хотя некоторым нравится. Чем специфичным для
WinXP Вы пользуетесь в KDE?
>> >> Единый формат конечно не помешает, но вот Х менять нет необходимости, >> >> хорошая штука. Просто она была создана больше для возможности работы с >> >> терминалов, чем для получения удобного графического интерфейса. >> C>Чем эта "штука" хороша? Тем что каждая графическая команда (например, >> C>рисование линии) должна пройти через пару переключений контекста? >> Да никто никогда и не говорил, что это "хорошо" или "плохо". >> Встравивание графики в ядро противоречит Unix-way. > > Чем? Почему тогда файловая система и драйверы устройств не работают вне > ядра? Чем графика фундаментально отличается? > >> Ну как такое ядро потом переностиь на другую архитектуру? > > Ну так графику тоже надо будет переносить. Какя разница: переносить > ядерные модули или user-level код?
Полностью согласен. Модули не помешали бы. Впрочем, к этому всё и
катится. А файловые системы вне ядра я скоро, наверное попробую (Hurd) —
если понравится, расскажу.
>> Дистрибутив — это ядро с набором софта. Дистрибутиво тьма. И в >> зависимости от составителя дистрибутива сильно варьируется потребность >> в ковырянии внутри скриптов. > > И везде она != 0.
А необходимость копаться в реестре == 0 под Windows? В ASPLinux
копаться в скриптах мне понадобилось не сразу. Хотя привычки...
Консольные. Поэтому писать скрипты я начал сразу после инсталляции
ASPv10. Но выбор этого не делать есть. Он ненамного меньше, чем под
Windows до момента копания в реестре. Просто после опыта попыток
настроить Х методом проб и ошибок, уже не напрягает (меня лично).
raskin wrote:
>> Работают, работают. Иначе как бы они доступ к аппаратуре современных >> ускорителей получали? Поэтому, кстати, глючные Xовые драйверы (для ATI, >> например) замечательно завешивают всю систему. > Работают в режиме ядра драйверы, а не модули самого KDE по рисованию > окон (отдающие, впрочем, много работы драйверам). А опасные драйверы > *от ATI* — это да.. Меня они заставили поставить DRI.
Ну вот, значит дизайн Xов уже не фундаментально стабильнее и надежнее —
все опять зависит от качества реализации.
>>> Да не сказал бы. Как раз маленькими менеджерами легче пользоваться >>> т.к. там из функциональности — джентельменский набор. >> Людям, переходящим с WinXP — не легче. > Первый час под XP я потратил на отключение различий с Windows98 > (Luna-парк, вид меню...). Хотя некоторым нравится. Чем специфичным для > WinXP Вы пользуетесь в KDE?
Control Panel'ом с его "Computer Administration", так же менюшкой
"Сетевые соединения". Да, еще у меня есть очень удобное меню свойств
экрана, где я могу легко настроить параметры ускорителя и
подкорректировать цвета.
>> Чем? Почему тогда файловая система и драйверы устройств не работают вне >> ядра? Чем графика фундаментально отличается? >>> Ну как такое ядро потом переностиь на другую архитектуру?
Так же, как и сейчас — по кусочкам. Сначала перенести поддержку базового
framebuffer'а, запустить базовую графику на другой системе, а потом
переносить все остальные графические функции.
>> Ну так графику тоже надо будет переносить. Какя разница: переносить >> ядерные модули или user-level код? > Полностью согласен. Модули не помешали бы. Впрочем, к этому всё и > катится. А файловые системы вне ядра я скоро, наверное попробую (Hurd) — > если понравится, расскажу.
Hurd — это фантастика. В смысле — не существует в реальности для
реальных применений.
>>> Дистрибутив — это ядро с набором софта. Дистрибутиво тьма. И в >>> зависимости от составителя дистрибутива сильно варьируется потребность >>> в ковырянии внутри скриптов. >> И везде она != 0. > А необходимость копаться в реестре == 0 под Windows?
Да, для многих пользователей. Многие пользователи про него просто не знают.
> В ASPLinux копаться в скриптах мне *понадобилось* не сразу. Хотя > привычки...
Повезло. Мне вот сразу же пришлось разбираться как настроить PPoE до
провайдера — графических утилит в пакете ASP9 я не нашел.
Здравствуйте, Cyberax, Вы писали:
C>Агащаз. Посмотрите-ка фильм в каком-нибудь проигрывателе с выключенными C>расширениями типа DRI. О впечатлениях расскажете. Да забыл, еще C>попробуйте потом посмотреть фильм через удаленный терминал, а потом C>расскажите о "сетевой прозрачности" Xов.
А нехрен фильмы смотреть . Работать без проблем. Даже с графикой работать можно
(я сижу на терминале, все крутиться на сервере... никаких тормозов. А
вот через RDP — отстой полный). Если фильмы нужны и локально — dri и др
нормально решают эту проблему (Doom3 же как-то бегает )
C>Я присылал ссылку на статью Гослинга, где как раз говорится о том, что C>дизайн Xов устарел лет на 10. Он был разработан для конца 80-х годов, C>когда не было крутых графических карт и многие юниксы не поддерживали C>динамические библиотеки. Из-за этого при работе с Xами на каждый вызов C>происходит ТРИ или даже ЧЕТЫРЕ переключения контекста (в сервер Xов, C>потом в контекст ядра, потом обратно в Xы, и в приложение), да еще и C>требуется маршаллинг/демаршаллинг аргументов вызова. В конце 80-х это C>было нормально, так время рисования на тогдашних карточках делало C>остальные затраты небольшими в сравнении.
dri тут никак разве не поможет? А вот под вынью че-то альтернатив не видно.
Например я могу спокойно пускать программы и локально и удаленно (например
через ssh -X). Вынь только весь десктоп в отдельном окне мне предоставить может.
C>Но в нынешних графических акселераторах есть мощные средства рисования, C>все важные ОС поддерживают динамические модули, и стало вполне можно C>напрямую отображать видеоповерхности адаптера напрямую в память приложения.
И? опять же X11 весьма расширяемая вещь. Работайте с Xrender например.
Зачем всех то в одну кучу мешать?
C>Поэтому изначальный дизайн Xов стал совсем неадекватен. Естественно, C>сами юниксоиды это понимают, так что появилась целая куча расширений C>(DRI и Xrender), которые позволяют обойти громоздкий механизм Xов или C>хотя бы сделать его более оптимальным. Естественно, это ведет к C>дальнейшему усложнению и так уже непростой архитектуры Xов.
А что в этом мире просто? Естветвенно под каждую задачу свои инструменты:
— фильмы гонять — будь добр пускать локально через тот же dri.
(да и без него все неплохо бегает)
— работать прозрачно с любой машины — пожалста (через модем правда
не получится, тут vnc более предпочтителен)
— игрушки гонять — имей дрова соотвествующие и OpenGL.
C>В Винде изначально GDI был сделан эффективнее Xов, так как не C>заморачивался с сетевой прозрачностью.
хъ C>Но даже и такая архитектура стала слишком
хъ интересные подробности о direct*
Ну и? Вынь не приобрела эффективного механизма гуев (тормоза GDI известны)
и при этом не имеет сетевой прозрачности. Ну и нахрен такое чудо? Может
стоит отделить мух от котлет? Пусть гуи рисуются медленнее, но прозрачно.
Для быстрых вещей типа игрух и видео пусть будет _отдельный_ механизм.
В упор не вижу чем таким выдающимся DirectX отличается от OpenGL или
даже того-же Xrender. ИМХО те же яйца токо в профиль.
Здравствуйте, Cyberax, Вы писали:
>> C>Тогда посоветуйте, плиз, форум где юниксоидов-программистов больше. >> Список рассылки по выбранному дистрибутиву.
C>У меня Debian и Gentoo — там в архивах списков про С++ мало что есть.
1) список рассылки debian-russian
2) ньюсгруппы fido7.ru.unix.prog, fido7.ru.unix, fido7.ru.linux, fido7.ru.unix.linux.
aka50 wrote:
> C>Агащаз. Посмотрите-ка фильм в каком-нибудь проигрывателе с выключенными > C>расширениями типа DRI. О впечатлениях расскажете. Да забыл, еще > C>попробуйте потом посмотреть фильм через удаленный терминал, а потом > C>расскажите о "сетевой прозрачности" Xов. > А нехрен фильмы смотреть . Работать без проблем.
Запустите KDE 3.2 через модем и попробуйте написать мне ответ. Хотя нет,
несколько лет мне ждать не хочется.
А вот Outlook Express через RDP по модему — вполне нормально. Когда у
меня не было ноутбука я читал (и писал) новости через RDP по модему.
Работало вполне прилично.
> Даже с графикой работать можно (я сижу на терминале, все крутиться на > сервере... никаких тормозов. А > вот через RDP — отстой полный).
Какое совпадение: у меня сейчас как раз в Cygwin'е тормозит KDE, а в
соседнем окне летает RDP с Win2k3.
> dri тут никак разве не поможет?
Поможет. Но по сути DRI — это просто способ обойти X-протокол.
> А вот под вынью че-то альтернатив не видно.
DirectX
> Например я могу спокойно пускать программы и локально и удаленно (например > через ssh -X). Вынь только весь десктоп в отдельном окне мне > предоставить может.
Не только, можно создать отдельный Window Station даже для одного окна,
и экспортировать его в RDP. У Citrix'а есть что-то в этом духе, просто
не часто это нужно.
> C>Но в нынешних графических акселераторах есть мощные средства рисования, > C>все важные ОС поддерживают динамические модули, и стало вполне можно > C>напрямую отображать видеоповерхности адаптера напрямую в память > приложения. > И? опять же X11 весьма расширяемая вещь. Работайте с Xrender например. > Зачем всех то в одну кучу мешать?
А зачем реализовывать сложнейший протокол, если потом будут, в основном,
использоваться средства обхода этого протокола? Тут уже получается
антипаттерн "инверсия решения" (когда более примитивные вещи делаются
через более сложные, а не наоборот).
> А что в этом мире просто?
Ну а зачем усложнять все?
> Естветвенно под каждую задачу свои инструменты: > — фильмы гонять — будь добр пускать локально через тот же dri. > (да и без него все неплохо бегает) > — работать прозрачно с любой машины — пожалста (через модем правда > не получится, тут vnc более предпочтителен) > — игрушки гонять — имей дрова соотвествующие и OpenGL.
А не проще ли иметь:
1. Быстрый графический слой, который работает в режиме ядра, небольшой
по размеру и хорошо отлажен.
2. Поверх этого слоя сделать оконную библиотеку (с хуками для оконных
менеджеров, естественно).
3. Поверх этого слоя реализовать отключаемые Xы.
> C>В Винде изначально GDI был сделан эффективнее Xов, *так как не ** > C>заморачивался с сетевой прозрачностью*. > C>*Но даже и такая архитектура стала слишком* > Ну и? Вынь не приобрела эффективного механизма гуев (тормоза GDI известны)
Ну так Хы еще тормознее: если на тормоза GDI уже можно было не обращать
внимание в 2000-2001 годах, то Xы тормозят до сих пор.
> и при этом не имеет сетевой прозрачности. Ну и нахрен такое чудо? Может > стоит отделить мух от котлет? Пусть гуи рисуются медленнее, но прозрачно.
Так ведь не получается: или мухи и котлеты, или только мухи без котлет,
или котлеты без мух.
> Для быстрых вещей типа игрух и видео пусть будет _отдельный_ механизм.
А зачем? Сейчас рабочие столы не сильно уступают в детализации игрушкам.
> В упор не вижу чем таким выдающимся DirectX отличается от OpenGL или > даже того-же Xrender. ИМХО те же яйца токо в профиль.
От XRender'а он отличается сильно, как и от OpenGL. В основном потому,
что OpenGL соответствует только части DirectX'а.
Cyberax wrote: >> Работают в режиме ядра драйверы, а не модули самого KDE по рисованию >> окон (отдающие, впрочем, много работы драйверам). А опасные драйверы >> *от ATI* — это да.. Меня они заставили поставить DRI. > > Ну вот, значит дизайн Xов уже не фундаментально стабильнее и надежнее — > все опять зависит от качества реализации. >
Так оно не через Х всё вешает. А через insmod. А Windows левым
vxd/wdm/anything повесить не сложнее. Или сложнее?
>> (Luna-парк, вид меню...). Хотя некоторым нравится. Чем специфичным для >> WinXP Вы пользуетесь в KDE? > > Control Panel'ом с его "Computer Administration", так же менюшкой > "Сетевые соединения". Да, еще у меня есть очень удобное меню свойств > экрана, где я могу легко настроить параметры ускорителя и > подкорректировать цвета.
Ну да, это вероятно, удобно. Просто я эти утилиты по одной дёргаю из-под
wmaker, пока не добираюсь до back-end сам. Это, действительно, требует
чуть больших усилий.
>> катится. А файловые системы вне ядра я скоро, наверное попробую (Hurd) — >> если понравится, расскажу. > > Hurd — это фантастика. В смысле — не существует в реальности для > реальных применений.
Ну, оно сейчас вообще скорее не существует. Но, быть может, дойдёт до
уровня,
когда устроит меня как мой рабочий стол.
>> >> Дистрибутив — это ядро с набором софта. Дистрибутиво тьма. И в >> >> зависимости от составителя дистрибутива сильно варьируется потребность >> >> в ковырянии внутри скриптов. >> > И везде она != 0. >> А необходимость копаться в реестре == 0 под Windows? > > Да, для многих пользователей. Многие пользователи про него просто не знают.
Многие базовые вещи (для меня) делаются муторно без реестра. С ним — менее
муторно.
>> В ASPLinux копаться в скриптах мне *понадобилось* не сразу. Хотя >> привычки... > > Повезло. Мне вот сразу же пришлось разбираться как настроить PPoE до > провайдера — графических утилит в пакете ASP9 я не нашел.
Э-э.. не помню... Кажется, в установщике это делается. И через
redhat-config-не помню. Но это, действительно, может быть и спрятано.
Впрочем, Mandriva — это лукавство, GNU не станет ОС для тех, для кого
компьютер меньше, чем важный инструмент, никогда. По понятным причинам —
кто поймёт таких пользователей? Из энтузиастов этой системы. А все
Linspire будут нести в себе подарки из Африки.. Впрочем, всё равно такие
пользователи часто пользуются ОС, которую поставили и настроили при
предпродажной подготовке, а в это MS вкладывается. А если Вам под Linux
писать — то всё равно огребание ловушек не заканчивается при установке.
)
