Windows vs. Linux , Продолжение

Цитата zera @ 23.01.10, 18:05

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

и о какой полнофункциональной настройки тут тогда можно рассуждать?

А можно Кеды или Гном только лишь из конфингов настроить?

Цитата Keepun @ 23.01.10, 18:59

А можно Кеды или Гном только лишь из конфингов настроить?

KDE можно, гном хз... У него там нечто вроде реестра, хотя я их его структуру ни разу не видел...

Добавлено 23.01.10, 19:07

Цитата Keepun @ 23.01.10, 17:48

Лучше предоставь вариант конфинга fstab и initd с комментариями всех настроек

пример, кстати, не очень удачный. fstab уже практически нигде редактировать не надо, а initd я даже не знаю, что такое

Цитата Keepun @ 23.01.10, 18:59

и о какой полнофункциональной настройки тут тогда можно рассуждать?

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

Цитата Keepun @ 23.01.10, 18:59

А можно Кеды или Гном только лишь из конфингов настроить?

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

Цитата CodeMonkey @ 22.01.10, 21:06

Позволю себе ещё ссылочку кинуть

Лучше не надо.
Первая - о консоли, впечатлила - "окно консоли в Виндоуз запускается под ClientServer Runtime System (CSRSS), а CSRSS не может быть "themed", потому что это опасно, т.к. это системный процесс" Ну а зачем делать косоль системным процессом? Не понятно.
По этой же ссылке, первое же предложение, первый же абзац: "INI files don't support Unicode." Или кто-то меня хочет обмануть, или виндоуз разучилась работать с текстовыми файлами в кодировке UNICODE?

Цитата Adil @ 23.01.10, 19:47

Первая - о консоли, впечатлила - "окно консоли в Виндоуз запускается под ClientServer Runtime System (CSRSS), а CSRSS не может быть "themed", потому что это опасно, т.к. это системный процесс" Ну а зачем делать косоль системным процессом? Не понятно.

Я так думаю, что там располагается вся оснастка по обслуживанию консольных окон, в частности оконная функция. Кроме того, он ещё и тесно с видеодрайвером взаимодействует. Насколько это может быть важным и сложным, знают те, кто когда-то разбирался в видеодрайверных грабберах под Win16. Нужно уметь работать в текстовых полноэкранных режимах, а при запуске в той же консоли DOS-приложения нужно быть готовым и к графическим, включая по меньшей мере 16-цветные EGA и VGA, а в идеале и VESA. В Win3xx эти вещи были частью видеодрайвера и поставлялись в составе драйверов вместе с железом, для Win9x, в которой была реализована mini-port модель видеодрайверов, MS сама написала универсальные грабберы. Но обе эти концепции плохо ложатся на WinNT, т.к. и Win3xx, и Win9x модели предусматривают доступ к железу с пользовательского уровня. Поэтому уживчивость консолей с подсистемой DOS и была вынесена в сервис.
На самом деле "консольный" код не работает под CSRSS-ными привелегиями. Я так думаю, что последний при создании окон имперсонирует создаваемые нитки под клиента, но те в свою очередь используют механизмы внутрипроцессного взаимодействия (которые естественно быстрее межпроцессных) для запросов тех или иных привелегированных операций. Так что опасность видимо не в нарушении прав доступа или привелегий, а в том, что темы предполагают исполнение пользовательского кода, который в общем случае непредсказуем, и может уронить все процессы, разделяющие эту консоль между собой. А вот это уже плохо.

Добавлено 24.01.10, 02:52
О сложностях, с которыми столкнулась MS при реализации нормальной консоли, говорит хотя бы то, что в Win9x полноценной консоли создать не пролучилось. Она была медленная и не полнофункциональная. И обслуживанием консольных окон занимался специальный VxD.

Qraizer, т.е. получается, что вся эта байда с консолью только для совместимости с досовскими прогами, работающими только в полноэкранном текстовом режиме? Много ли из них смогут вообще работать по 7кой? Опять любимые грабли виндоуз - обратная совместимость. Т.е. получается, что в, допустим, Windows Server 2008 из-за поддержки старых досовских игрушек нет нормального консольного терминала - одного из основных средств администрирования этого самого сервера? И где тут здравый смысл?
З.Ы. Кстати, в никсах такая проблема с консолью не возникает на генетическом уровне из-за разделения ядра и ГУИ.

Цитата Adil @ 24.01.10, 09:50

из-за разделения ядра и ГУИ

этот самый ГУИ в никсах хронически тормозит

Цитата MichSpar @ 24.01.10, 10:21

этот самый ГУИ в никсах хронически тормозит

Не правда. Надо юзать расововерный гуй, Xfce, например. Я в соседней теме приводил скриншот. Это летает на ноуте с 384 М ОЗУ, Celeron Mobile 1.86 ГГц, Radeon Xpress 200M

Добавлено 24.01.10, 11:17
Ну и расововерный дистр - Gentoo - тоже не помешает

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

Я имел дела с ДОСовскими графическими приложениями под Windows, тут все отдано на откуп драйверам. На одной машине приложение спокойно, почти не тормозя, работает в окне, на некоторых машинах даже в VESA-режимах. На другой сразу переключается на полный экран, при переключении в окно останавливается, при переключении в полный экран работает дальше. На третьей работает только в полном экране, попросту зависая при переключении в окно. В последнем случае работать практически невозможно. Так что совместимость была чисто номинальная. Более того, так себя ведут и некоторые текстовые программы.
Я такие приложения, если приходится, как игрушки, в DOS-Box запускаю. Или вообще в виртуалке, под DOS.
Microsotf имело смысл при первых признаках такой "несовместимости" отказаться от совместимости и воткнуть в систему виртуалку, вроде досбокса.

Добавлено 24.01.10, 15:36
В линуксе такой проблемы нет не

Цитата Adil @ 24.01.10, 09:50

из-за разделения ядра и ГУИ

, а потому, что там и без гуя приложение прямого доступа к экрану не имеет.

Цитата amk @ 24.01.10, 15:29

Я имел дела с ДОСовскими графическими приложениями под Windows

Цитата Qraizer @ 24.01.10, 14:47

Или в никсах такой проблемы нет

Нет конечно же. Все эти игры с адаптерами из-за того, что DOS вообще никак графику не поддерживал. А X (графическая среда под *nix) тогда уже существовала. И сейчас существует. Насчет совместимости не знаю, но проблем в nix с графическими приложениями не было никогда.

Цитата MichSpar @ 24.01.10, 10:21

этот самый ГУИ в никсах хронически тормозит

Как всегда, порете чушь, молодой человек.

amk, да, видеодрова тут играют немалую роль, но эта проблема дальше интерфейса CSRSS с ними не распространяется. Видеодрова же не будут делать ничего лишнего по сравнению с "железными" возможностями видеокарты. Сравни результаты VESA-информации от nVidia и Radeon. Из DOSа, естественно, а не виртуализированную дровами.

Цитата amk @ 24.01.10, 15:29

Microsotf имело смысл при первых признаках такой "несовместимости" отказаться от совместимости и воткнуть в систему виртуалку, вроде досбокса.

Вероятно. Но в 1993 году, потом в 1998, и даже в 2001 об этом не могло быть и речи. Догадываешься, почему?

Добавлено 24.01.10, 16:19
Мяут-Настоящий, верно. Но у Windов выбора не было. Каковой DOS получилась, таковой её и нужно было эмулировать. Иначе б до судьбы OS/2 было бы недалеко.

Цитата Qraizer @ 24.01.10, 14:47

в 7-е консоль, как я понял, уже нормальная, а не совместимая. Но воочию пока не видел.

Это смотря какая. PS-консоль - да нормальная, cmd как была так и осталась.

Цитата D_KEY @ 22.01.10, 21:48

Guderian, браво. Второй раз не дают плюсик поставить... Так что на словах принимай

Ценю

Цитата Мяут-Настоящий @ 22.01.10, 22:04

Да. Чтобы узнать все автоматически стартующие сервисы в Solaris нужно знать 4 буквы.

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

Цитата Мяут-Настоящий @ 22.01.10, 22:04

Ну в общем-то все три задачи изящно решаются grep/awk. Если говорить о логах web-сервера или ftp- (последний есть под рукой), то пжалста:

Это изящество задачу не решило. Если ты не понял, то это типовая задачка на просмотр посещаемости. Лог группируется по урлам, для каждого урла рассчитывается количество хитов и выводится в порядке убывания этих хитов. Так что пока мимо.

Цитата Мяут-Настоящий @ 22.01.10, 22:04

Получилось - очень изящно

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

Цитата Мяут-Настоящий @ 22.01.10, 22:04

У MS есть эпичный баг - http://support.microsoft.com/kb/283318 . Они баг назвали - "особенностями реализации". Я теперь все шо я щитаю глупым со стороны M$ называю особенностями реализации.

Я лично прочитал "Такая возможность не поддерживается... ну не сделали". Точно также, как линукс не поддерживает, например, ActiveX, by design. Но у меня, наверно, английский хромает

Цитата Астарот @ 22.01.10, 23:05

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

Тебе что именно не понятно - иерархия как структура или ее содержание? Может какой-нибудь /usr/local/apache/http.conf/гдетотамнайтиопцию чем-то гениально новым в конфигостроении отличается? Или, скажем, HKCU/Software/Mirosoft/Office не по силам? А потом, как здесь уже было справедливо замечено, никто не лезет в реестр просто так, за посмотреть. Он предназначен в большей степени для девелоперов. Ты либо конфигуришь его через консоли/гуй, либо у тебя на руках конкретная опция, которую надо поставить и находится она моментом. Просто пытаться почитать реестр на ночь - это удел гиков

Цитата Астарот @ 22.01.10, 23:05

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

А тебе какие конфиги больше нравятся? Таблички порисовать как в fstab'е? Чем-то напоминающий васик xorg.conf? ini-подобные в духе rc.conf? xml-пародии вроде апача? А может жабаскриптовые как в файрфоксе?

Цитата Adil @ 23.01.10, 19:47

Первая - о консоли, впечатлила - "окно консоли в Виндоуз запускается под ClientServer Runtime System (CSRSS), а CSRSS не может быть "themed", потому что это опасно, т.к. это системный процесс" Ну а зачем делать косоль системным процессом? Не понятно.

Наверно потому, что этот процесс решает еще множество других, системных задач. Например, на нем висит environment. Или предполагается, что все системные переменные должны грохнуться при закрытии окошка cmd.exe?

Цитата Adil @ 23.01.10, 19:47

По этой же ссылке, первое же предложение, первый же абзац: "INI files don't support Unicode." Или кто-то меня хочет обмануть, или виндоуз разучилась работать с текстовыми файлами в кодировке UNICODE?

А какая связь между текстовыми файлами и API для работы с ini-файлами? Не, если работать с ними вручную, то юникод поддерживается, а если через WinAPI, то нет.

Цитата amk @ 24.01.10, 15:29

Microsotf имело смысл при первых признаках такой "несовместимости" отказаться от совместимости и воткнуть в систему виртуалку, вроде досбокса.

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

Цитата Мяут-Настоящий @ 24.01.10, 16:12

Нет конечно же. Все эти игры с адаптерами из-за того, что DOS вообще никак графику не поддерживал. А X (графическая среда под *nix) тогда уже существовала. И сейчас существует. Насчет совместимости не знаю, но проблем в nix с графическими приложениями не было никогда.

Во-первых, на тогдашних "писюках" никаких иксов отродясь не было. Во-вторых, не было в те времена и толковых аппаратных стандартов для чего-то отличного от CGA/EGA/VGA (VESA пришла гораздо позже). Хотя... тебя поди и в планах не было, когда мы зачитывались Джорждейном и дрожащими руками отправляли цепочки замысловатых значений в порты видеоадаптера Дрожащими, потому как тогда совершенно реально было спалить монитор, ошибившись с частотой RAMDAC'а. Так что тебе не познать счастья выжимания графики 320x240x256 при стандартном 320x200x256 или, скажем, увеличения количества одновременно отображаемых на мониторе цветов, когда ты мониторишь ход луча и меняешь по ходу этого луча палитру DOS же, как всякая уважающая себе дисковая операционная система спокойно сидел на int21h и преимущественно занимался вопросами управления дисками, файлами, приложениями. Видео занимался тот, кто и должен был им заниматься - BIOS, который для этих целей узурпировал int13h. Только делал он это плохо, потому и приходилось изворачиваться и дос здесь вообще никаким боком.