Здравствуйте, eqw, Вы писали:

N>>Читать выход гугла — как пить из включенного брандспойта — не напьёшься, но весь промокнешь. Ни по одной из ссылок из первых двух экранов я не увидел ни одного внятного объяснения явления
eqw>Ну сами ссылки-то вы увидели? Проблема присутствует и является довольно популярной,

Проблемы *торможения* фактически нет. Есть проблема менее... мнэээ... дуракоустойчивого выбора драйверов. (И то — пока я на 7ку не поставил драйвера с диска от материнки, фичи видео за пределами 2D не были доступны, а сама она догадаться, чем реализовывать встроенное видео на SandyBridge процессоре, была не в состоянии.) При наличии и установке адекватного драйвера проблема исчезает. А в адекватных дистрибутивах выбор драйвера решается адекватно.

eqw> универсального решения ее не предлагается. Проблемы "почему в windows интерфейс медленнее чем в linux", например, на форумах в том же количествве не наблюдается.

Зато есть куча жалоб типа "какой идиот делал этот интерфейс Windows". И что, это лучше? Я вообще не вижу суровой необходимости гонки за скоростью видео, всё равно она практически для всего достаточна при любом выборе из двух. В отличие от тараканов Windows. Вот почему во всех версиях по 7ку включительно любое существенное изменение в экранной обстановке (например, всплыло новое окно) вызывает сброс выбора текущей иерархии меню (и можно в результате ткнуть совсем не туда, куда хотел, потому что меню вдруг пропало)? А как мне настроить без дополнительных тулзей, чтобы новопоявившееся окно приложения не получало фокус, и вообще сидело тихо внизу, пока я его не попрошу? Или, как альтернативный вариант, почему не давать самому разместить новое окно, как в twm? А почему нельзя без дополнительных средств сделать переключение языка клавиатуры по CapsLock? А почему нельзя один раз выбрать, например, французскую раскладку, не проходя нудное добавление её в список выбора для ввода (а потом удаляя, ибо нахрен не нужна)? Вот это, IMHO, реальные проблемы интерфейса, а не "окно отрисовалось медленнее на 0.001сек" или "левый дистрибутив не сумел поставить драйвер".

eqw>В качестве упражнения попробуйте обьяснить, почему в Linux нет работающего аналога виндового remote desktop (который с приличной же скоростью работает на 56k модемных соединениях) и почему VNC под линуксом работает существенно медленнее, чем под виндами.

А при чём тут remote desktop и VNC? Это задачи уже совсем другого плана, Вы тему-то не меняйте на переправе.
А так — я могу объяснить: оно реально нахрен никому настолько не нужно, потому что в отличие от Windows в случае Linux нет ограничения удалённым управлением через графику (или через адские RPC), при наличии минимального опыта основные задачи лучше всего решаются через SSH. (А теперь встречный вопрос: почему в Windows до сих пор нет адекватного аналога удалённого шелла, которому не надо подымать графику? И чтобы все штатные средства управления могли обходиться без графики?)
Соответственно, rdesktop есть, но реализован ровно настолько, чтобы можно было рулить виндами в локалке.

>>Несколько случаев типа "замени старый кривой драйвер на новый", после чего проблема исчезает.
eqw>И еще тонна случаев, когда замена драйвера не помогает и предлагается не сравивать GUI в windows и Linux, потому что они совсем по-разному спроектированы .

Например?

N>>Так мы дождёмся объяснения, что именно из гуя "лежит в юзерспейсе" и как это мешает?
eqw>О боги, как же это скучно. Мне сейчас вам рассказывать очевидные вещи о том, как спроектирован X и как взаимодействуют меду собой X window server и X window client? Какая часть этого взаимодействия идет через юзерспейс? Я не буду этого делать, мне лень. Хотите доказать, что этого не происходит — вперед, доказывайте, будет интересно почитать.

Не надо рассказывать банальности, они известны. Расскажите, какой вывод Вы делаете из этих банальностей, и насколько результаты того сравнения существенны.
Я вот знаю, что за пределами тех же удалённых графических столов (которые по факту не нужны) всё, что является суровой спецификой X-сервера, настолько лёгкое, что делается оно через сокет или напрямую через сисколлы — без разницы. А то, где есть разница (OpenGL, отображение видео и т.д.) — вместо сокетов используются прямые механизмы. Соответственно, на них разницы нет. И что мне после этого с того факта, что задача типа "отобразить букву в окне" требует дополнительного маршаллинга и прогона через сокет, если это копейки по сравнению с затратами на растеризацию той буквы?

eqw>>>>>Wayland является убогой попыткой сделать это более эффективно,
N>>>>Уже сразу и "убогой".
eqw>>>Ну а как её ещё назвать? Костыль на костыле.
N>>Где именно костыли? Расшифруй.
eqw>Мне слишком скучно обьяснять очевидные вещи. Если вы про wayland знаете только из википедии и не понимаете, в чем там костыли, что задаете такой вопрос, скучно вдвойне.

Иначе, как слив, я это интерпретировать не могу.

N>>Вы отвечали на реплику: "Надо бы сперва gdi вынести из ring0 с его ограничением 16K дескрипторов."
N>>Так что жду ответа на вопрос.
eqw>Вы русский язык понимаете? В реплике не было вопроса.

Но Вы на неё ответили. Так что, кто тут не понимает какой язык и почему, ещё надо уточнить.

eqw>Повторяю еще раз — если вынести GDI из ring0, упадет перформанс GDI и как следствие GUI будет тормозить. Прямо как в линуксе.

Жаль, что мы так и не заслушали начальника транспортного цеха осмысленных аргументов.

Здравствуйте, fin_81, Вы писали:

_>>>Дополню про gdi в ядре (ring0)

_>>>Хабр — Как уронить windows
_>>>http://habrahabr.ru/post/179543/

_>>>Не проверял, говорят работает

N>>А вот это уже камень в сторону Intel. Потому что генерировать прерывание из *DIV без явного на то запроса — их глупость.

_>Глупость — не глупость, но это документированное поведение.

Есть такая штука, как POLA. Соответствие ей обеспечивает минимизацию ошибок при применении, и, наоборот, нарушение, с созданием неожиданных препятствий там, где они противоречат общей логике — увеличивает и усиливает ошибки. Никакое документирование не может быть основанием для нарушения POLA. Intel же грубо его нарушил. Мне здесь пофиг, насколько они первые в этом решении или нет (конечно, нет — безусловное прерывание от переполнения при делении было ещё на S/360), важно, что это ошибка, которая не должна распространяться. Арифметические операции должны выполняться по единообразным правилам, и переполнение при сложении, когда в int16_t 20000 + 20000 == -25536, ничуть не менее проблемно, чем "переполнение" от деления на 0. Или включен, грубо говоря, checked режим, что они оба вызывают прерывание, или он не включен, тогда задача кодера — вставить проверки там, где нужно.

В случае IDIV и переполнения в нём ситуация усугубляется тем, что документация по команде переполнена разными тонкостями, связанными с выбором регистров, защитой памяти и прочей бла-бла-бла, но ни слова не сказано, что элементарно нарваться на выход за пределы представления при делении на -1. Соответственно, то, что это "документировано", не более чем отмазка... помнишь начало "Автостопом по Галактике"? "Объявление висело на Альфе Центавра, и не наша вина, что вы его не читали." Ситуация ровно такая же. И практика показывает, что масса средств, которые выполняют операции, заданные пользователем, умеют отлавливать случай делителя, равного 0, но не случай, когда он равен -1. Конечно, их сейчас начнут массово править, но проблема-то давно была... и именно тут я не вижу причины винить именно Microsoft за то, что уровень их программистов всего лишь равен среднему по отрасли.

_>Глупость то, что "ядерные кодеры" используют опасную операцию деления, кидающая исключение "деление на ноль".

Ну, во-первых, не деление на ноль, а #DE (Divide Error), в терминах Intel. В Unix оно вообще транслируется в SIGFPE (дословно, floating-point error). Во-вторых, а что ещё им использовать? Вычитание в цикле? Так это не лучше.

Деление, даже такое — безопасная операция, если к ней подойти с опытом (то есть памятью о набитых шишках). Явной проверке подлежат 2 случая n/d — d==0 при любом n, и d==-1 при n==INT_MIN. Наверняка первый сейчас проверяется, а второй — нет. Ну, значит, скоро добавят... вот насколько скоро, посмотрим.

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

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

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, eqw, Вы писали:

N>>>Читать выход гугла — как пить из включенного брандспойта — не напьёшься, но весь промокнешь. Ни по одной из ссылок из первых двух экранов я не увидел ни одного внятного объяснения явления
eqw>>Ну сами ссылки-то вы увидели? Проблема присутствует и является довольно популярной,

N>Проблемы *торможения* фактически нет. Есть проблема менее... мнэээ... дуракоустойчивого выбора драйверов.
Это вы широкую проблему подменяете боле узкой и заявляете что более узкая проболема имеет решение. Помимо драйверов есть еще архитектурные проблемы X window, которые никуда не деваются.

eqw>> универсального решения ее не предлагается. Проблемы "почему в windows интерфейс медленнее чем в linux", например, на форумах в том же количествве не наблюдается.

N>Зато есть куча жалоб типа "какой идиот делал этот интерфейс Windows".
Это неконструктивная жалоба. Аналогичных жалоб "какой идиот делал последний интерфейс Gnome" полно.
Обсуждаем мы вполне существующие тормоза, а не сложноизмеримые степени идиотизма авторов GUI.

>И что, это лучше? Я вообще не вижу суровой необходимости гонки за скоростью видео, всё равно она практически для всего достаточна при любом выборе из двух.
А, ну наконец-то, старая песенка линуксоидов "XXX ненужен".

> В отличие от тараканов Windows. Вот почему
> А как мне
> Или, как альтернативный вариант, почему не давать самому разместить новое окно, как в twm?
> А почему нельзя без дополнительных средств сделать переключение языка клавиатуры по CapsLock?
> А почему нельзя

Мы не обсуждаем дизайн интерфейса. Мы обсуждаем тормоза.

eqw>>В качестве упражнения попробуйте обьяснить, почему в Linux нет работающего аналога виндового remote desktop (который с приличной же скоростью работает на 56k модемных соединениях) и почему VNC под линуксом работает существенно медленнее, чем под виндами.

N>А при чём тут remote desktop и VNC?
А причем тут ваши "а как мне сделать в windows интерфейс как в линуксе"?
Remote desktop и VNC относятся к обсуждаемому вопросу производительности GUI.

>Это задачи уже совсем другого плана, Вы тему-то не меняйте на переправе.
Уж кто бы говорил про смену темы.

N>А так — я могу объяснить: оно реально нахрен никому настолько не нужно, потому что в отличие от Windows в случае Linux нет ограничения удалённым управлением через графику (или через адские RPC), при наличии минимального опыта основные задачи лучше всего решаются через SSH.
Ага, конечно. То-то X window весь из себя задизайнен с network transparency, (которую никто не может использовать, потому что тормозит).
Впрочем, Linux никогда не станет десктопной системой для домохозяек пока доинирует подход "XXX ненужен".

>(А теперь встречный вопрос: почему в Windows до сих пор нет адекватного аналога удалённого шелла, которому не надо подымать графику? И чтобы все штатные средства управления могли обходиться без графики?)
С добрым утром. Есть Powershell, есть Windows Server Core.

>>>Несколько случаев типа "замени старый кривой драйвер на новый", после чего проблема исчезает.
eqw>>И еще тонна случаев, когда замена драйвера не помогает и предлагается не сравивать GUI в windows и Linux, потому что они совсем по-разному спроектированы .
N>Например?
В гугле забанили? Я уже запрос для поиска давал.

N>Я вот знаю, что за пределами тех же удалённых графических столов (которые по факту не нужны) всё, что является суровой спецификой X-сервера, настолько лёгкое, что делается оно через сокет или напрямую через сисколлы — без разницы.
Ну вот что вы там знаете и что там без разницы — не очень интересно. Иксы медленнее работают на

>А то, где есть разница (OpenGL, отображение видео и т.д.)
Господи, ну сколько можно. Мы начали с GDI. Причем тут вообще OpenGL и отображение видео? Это обычное рисование кнопочек, списков, и прокрутка окон.

>задача типа "отобразить букву в окне" требует дополнительного маршаллинга и прогона через сокет, если это копейки по сравнению с затратами на растеризацию той буквы?
Так вот эти ваши "копейки" выливаются в то, что по сравнению с GDI, иксы тормозят на этих простых операциях.


eqw>>Мне слишком скучно обьяснять очевидные вещи. Если вы про wayland знаете только из википедии и не понимаете, в чем там костыли, что задаете такой вопрос, скучно вдвойне.
N>Иначе, как слив, я это интерпретировать не могу.
Печально. Интерпретируйте как угодно.

N>Но Вы на неё ответили. Так что, кто тут не понимает какой язык и почему, ещё надо уточнить.

eqw>>Повторяю еще раз — если вынести GDI из ring0, упадет перформанс GDI и как следствие GUI будет тормозить. Прямо как в линуксе.

N>Жаль, что мы так и не заслушали начальника транспортного цеха осмысленных аргументов.
Аргументы какие-то зачем-то понадобились вам для подтверждения очевидной вещи — если GUI вынести из ring0 он начнет работать медлннее и того, что GUI в линуксе работает медленнее. Оба утверждения банальны и доказывать их при наличии у собеседника гугла и головы на плечах совершенно не нужно.

Здравствуйте, eqw, Вы писали:

N>>Жаль, что мы так и не заслушали начальника транспортного цеха осмысленных аргументов.
eqw>Аргументы какие-то зачем-то понадобились вам для подтверждения очевидной вещи — если GUI вынести из ring0 он начнет работать медлннее и того, что GUI в линуксе работает медленнее. Оба утверждения банальны и доказывать их при наличии у собеседника гугла и головы на плечах совершенно не нужно.

Если принять второе в виде "GUI нормально настроенного линукса работает на 0.1% медленнее", то я принципиально откажусь спорить с этим. Пусть оно медленнее, фиг с ним. Мне качество системы в целом и удобство работы с ней во всех аспектах для решения моих задач — важнее, чем даже 10%, а эта вероятная выгода Windows в одном конкретном аспекте, соответственно, слабее общей тенденции.
Более того, я долго сидел на комбинации FreeBSD с VESA драйвером, который по сравнению с "родным" для карточки даёт вообще дикие тормоза, фактически на порядок — и ничего, только мелкие неудобства.

Первое же ничуть не банально и требует рассмотрения. Размещение части (какой именно?) GUI в ring0 (говорить тут "в ядре" не совсем корректно) может оказать как положительный эффект, так и отрицательный (например, из-за переключений контекста). Сравнивать можно только в предположении, что у каждой из сторон выбрана оптимальная комбинация. Но мы видим, что это не так, хотя бы на примере соседнего субтреда про деление на -1, а ранее — про эксплойты чтения метафайлов.

>>И что, это лучше? Я вообще не вижу суровой необходимости гонки за скоростью видео, всё равно она практически для всего достаточна при любом выборе из двух.
eqw>А, ну наконец-то, старая песенка линуксоидов "XXX ненужен".

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

Если вспоминать тот же rdesktop, я слышал про несколько попыток осовременить сжатие. Кстати, в последних версиях это уже есть.

N>>Зато есть куча жалоб типа "какой идиот делал этот интерфейс Windows".
eqw>Это неконструктивная жалоба. Аналогичных жалоб "какой идиот делал последний интерфейс Gnome" полно.

С этим я согласен полностью, Gnome идёт в том же бредовом направлении, что Win8 (а частично и предшествующие). Но:

N>>А так — я могу объяснить: оно реально нахрен никому настолько не нужно, потому что в отличие от Windows в случае Linux нет ограничения удалённым управлением через графику (или через адские RPC), при наличии минимального опыта основные задачи лучше всего решаются через SSH.
eqw>Ага, конечно. То-то X window весь из себя задизайнен с network transparency, (которую никто не может использовать, потому что тормозит).

Ну почему же никто? Если не использовать, например, просмотр фильмов, то даже для 10Mbit/s его тормоза практически незаметны. Я работал достаточное время в таком режиме, чтобы оценить.

eqw>Впрочем, Linux никогда не станет десктопной системой для домохозяек пока доинирует подход "XXX ненужен".

Ну винда-то стала? Это при таком подходе и NIH на каждом шагу в разы сильнее, чем в Linux. Возможность стать системой для домохозяек зависит совсем не от 0.1% скорости графики.

>>(А теперь встречный вопрос: почему в Windows до сих пор нет адекватного аналога удалённого шелла, которому не надо подымать графику? И чтобы все штатные средства управления могли обходиться без графики?)
eqw>С добрым утром. Есть Powershell, есть Windows Server Core.

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

>>>>Несколько случаев типа "замени старый кривой драйвер на новый", после чего проблема исчезает.
eqw>>>И еще тонна случаев, когда замена драйвера не помогает и предлагается не сравивать GUI в windows и Linux, потому что они совсем по-разному спроектированы .
N>>Например?
eqw>В гугле забанили? Я уже запрос для поиска давал.

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

N>>Я вот знаю, что за пределами тех же удалённых графических столов (которые по факту не нужны) всё, что является суровой спецификой X-сервера, настолько лёгкое, что делается оно через сокет или напрямую через сисколлы — без разницы.
eqw>Ну вот что вы там знаете и что там без разницы — не очень интересно. Иксы медленнее работают на

Что-то недописано.

>>А то, где есть разница (OpenGL, отображение видео и т.д.)
eqw>Господи, ну сколько можно. Мы начали с GDI. Причем тут вообще OpenGL и отображение видео? Это обычное рисование кнопочек, списков, и прокрутка окон.
>>задача типа "отобразить букву в окне" требует дополнительного маршаллинга и прогона через сокет, если это копейки по сравнению с затратами на растеризацию той буквы?
eqw>Так вот эти ваши "копейки" выливаются в то, что по сравнению с GDI, иксы тормозят на этих простых операциях.

Насколько? Я не вижу никаких тормозов на средствах, хоть как-то похожих на современные. (Более того, Windows больше тормозит по умолчанию, то есть пока не выключишь всяких транжир процессора, вроде Aero.) Даже на технике уровня 486/50 уже не было тормозов в иксах — это то, с чем я начал с иксами работать. Какое должно быть железо, чтобы эти "тормоза" стали заметны?

eqw>>>Мне слишком скучно обьяснять очевидные вещи. Если вы про wayland знаете только из википедии и не понимаете, в чем там костыли, что задаете такой вопрос, скучно вдвойне.
N>>Иначе, как слив, я это интерпретировать не могу.
eqw>Печально. Интерпретируйте как угодно.

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

Здравствуйте, netch80, Вы писали:

_>>Глупость то, что "ядерные кодеры" используют опасную операцию деления, кидающая исключение "деление на ноль".

N>Ну, во-первых, не деление на ноль, а #DE (Divide Error), в терминах Intel. В Unix оно вообще транслируется в SIGFPE (дословно, floating-point error). Во-вторых, а что ещё им использовать? Вычитание в цикле? Так это не лучше.

Насколько помню защищенный режим x86, исключение "деление на ноль" не простое и при наложении с другими исключениями/прерываниями кидается невосстановимое исключение. Скорее всего это и наблюдается в этом бсоде.

N>Деление, даже такое — безопасная операция, если к ней подойти с опытом (то есть памятью о набитых шишках). Явной проверке подлежат 2 случая n/d — d==0 при любом n, и d==-1 при n==INT_MIN. Наверняка первый сейчас проверяется, а второй — нет. Ну, значит, скоро добавят... вот насколько скоро, посмотрим.

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

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

N>Это тоже, но это независимый фактор. Вон линуковцы долго закрывались от включения криптографии в ядро. Но пришлось...

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

А gdi в ядре не нужен, для современной 2д графики в ядре необходимо и достаточно установки графических режимов, блитинг битмапов, и переключение буферов отображения.

Скоро придется перелезать на qnx/minix/l4

Здравствуйте, tbasic1, Вы писали:

T>Более того, в ней гораздо лучше работает своппинг

Ой, да що ви говорите!! В винде лучше работает свопинг?! Вот так новость. В лялихе у меня в свопе ноль байт, если достаточно свободной RAM. А вот про венду я такого сказать не могу: пока вообще своп-файл в ней не отключишь, она будет ковырять его постоянно, даже если сводобной RAM 8 гиг.

Здравствуйте, eqw, Вы писали:

eqw>У меня он не тормозит, он тормозит у линуксоидов.

Давай ты не будешь говорить за линуксоидов?

Здравствуйте, Ночной Смотрящий, Вы писали:

D>>Боюсь, твой SSD подохнет втрое раньше под восьмёркой, чем под лялихом.

НС>SSD от частого чтения не дохнут, не переживай.

Есть мнение, что если бы там ограничивалось только чтением, он за то время, которое он "читает", успел бы 1000 раз забить всю свободную RAM. А так-то я не переживаю: у меня лялих.

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, tbasic1, Вы писали:

T>>Более того, в ней гораздо лучше работает своппинг

D>Ой, да що ви говорите!! В винде лучше работает свопинг?! Вот так новость. В лялихе у меня в свопе ноль байт, если достаточно свободной RAM. А вот про венду я такого сказать не могу: пока вообще своп-файл в ней не отключишь, она будет ковырять его постоянно, даже если сводобной RAM 8 гиг.
зато когда ее не хватает.... линукс оказывает в полной жопе посравнению с нормальными осями.

Здравствуйте, fin_81, Вы писали:

_>Насколько помню защищенный режим x86, исключение "деление на ноль" не простое и при наложении с другими исключениями/прерываниями кидается невосстановимое исключение. Скорее всего это и наблюдается в этом бсоде.

А зачем наложение на другое? Оно срабатывает в данном случае само по себе. Я сильно сомневаюсь, что тут невосстановимая ошибка. Скорее, просто такая, к которой ядро не готово. Что странно, учитывая существование ядерного SEH — проблему можно было тривиально обработать через последнее.

_>Если этот баг так долго существует (виста, семь, восемь), то это небезопасное деление размазано ровным слоем по всему ядру, что так просто его не исправить.

Верно. Будет не одно место, а несколько сотен. Но хотя бы одно самое открытое известное уже полечат. А за остальное — бить Intel ногами, долго и с наслаждением.

_>А gdi в ядре не нужен, для современной 2д графики в ядре необходимо и достаточно установки графических режимов, блитинг битмапов, и переключение буферов отображения.

Согласен полностью.

_>Скоро придется перелезать на qnx/minix/l4

Здравствуйте, tbasic1, Вы писали:

D>>Ой, да що ви говорите!! В винде лучше работает свопинг?! Вот так новость. В лялихе у меня в свопе ноль байт, если достаточно свободной RAM. А вот про венду я такого сказать не могу: пока вообще своп-файл в ней не отключишь, она будет ковырять его постоянно, даже если сводобной RAM 8 гиг.
T>зато когда ее не хватает.... линукс оказывает в полной жопе посравнению с нормальными осями.

Если с нормальными — это BSD, то я в принципе согласен (для поддержания цеховой солидарности, и вообще, VM в ней немного умнее). Если с Windows — то увы и ах. Случай именно нехватки "отрабатывается" в ней обычно параличом всех, в отличие от Linux, который эффективно отстреливает наиболее вредных.

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

Здравствуйте, eqw, Вы писали:

eqw>Ну сами ссылки-то вы увидели? Проблема присутствует и является довольно популярной, универсального решения ее не предлагается. Проблемы "почему в windows интерфейс медленнее чем в linux", например, на форумах в том же количествве не наблюдается.

А объясните мне, пожалуйста, что значит тормозит? Вот у меня есть линукс с гномом, окошки отрисовываются нормально, кино показывается, как понять, что у меня гуй тормозит?

Здравствуйте, netch80, Вы писали:

>>>(А теперь встречный вопрос: почему в Windows до сих пор нет адекватного аналога удалённого шелла, которому не надо подымать графику? И чтобы все штатные средства управления могли обходиться без графики?)
eqw>>С добрым утром. Есть Powershell, есть Windows Server Core.

N>Да-да, про них рассказывают каждый раз на такие вопросы.

Видимо, потому что это ответ на них.

N> Но никто не показал реального примера интерактивного использования этих средств админом

А как ты видишь такой пример? PS+WinRM реально используются реальными админами, а Windows Core сейчас является вариантом установки по умолчанию.

Здравствуйте, Roman Odaisky, Вы писали:

RO>Если оно не осилит писать на флешку большими кусками, а станет делать по операции записи на каждый файл, то будет.
Ядру вообще то по барабану. Его попросила FS сделать write through с подтверждением что оно записалось — ядро как попросили, так и сделает.

RO>В моем понимании очень даже ядро, потому что нулевое кольцо, ядерное API и ядерный же планировщик. Что же, по-твоему, ядро, если ты не включаешь туда ФС?
Т.е. по твоему любой драйвер который в ring0 крутится автоматически относится к ядру ОС?

Здравствуйте, Roman Odaisky, Вы писали:

RO>Отправил миллион файлов на копирование, ждешь завершения миллиона операций записи.
RO>Или отправил миллион файлов, ядро буферизовало запись и ты ждешь завершения тысячи операций записи. Файлов в секунду будет больше.
А persistence там как обеспечивается? Если посреди этой операции power off венику устроить, что будет на диске?

НС>>То есть у тебя, чтобы писать на флешку большими кусками, это ядро надо править?
RO>А кто, по-твоему, должен буферизовать запись, пользователь, что ли?
Оно и не на флешку будет метадату писать сразу на диск, ибо fault tolerance надо как то делать.

Здравствуйте, hattab, Вы писали:

n>> А он снова запускается, сколько ни убивай. И жрёт 99% CPU, работать невозможно, простейшее действие тормозило на минуты.

H>В таких случаях помогает принудительное выставление минимального приоритета. Я для этих целей использовал TaskManager Extension, он запоминает какому процессу выставляется какой приоритет.
В таких случаях помогает sc delete <service name>
Это WPF говно я выношу как только оно появляется. А появляется оно с каким нить богомерзским .NET Framework update.
Судя по тому, что без него всё отлично работает — сервис этот суть бесполезное говноподелие

Здравствуйте, tbasic1, Вы писали:

T>зато когда ее не хватает.... линукс оказывает в полной жопе посравнению с нормальными осями.

Что-то я не помню, когда в последний раз добирался до этого "зато" (но смутно помню, это была отладка глюка в моей программе, когда она забивала всю свободную память). Так что аргумент твой — извините, тянет только на пук в лужу: мол, наша тачка едет медленно и бензином в салоне воняет, но зато у нас подушка безопасности круче.

Здравствуйте, fin_81, Вы писали:

_>Здравствуйте, netch80, Вы писали:

_>>>Дополню про gdi в ядре (ring0)

_>>>Хабр — Как уронить windows
_>>>http://habrahabr.ru/post/179543/

N>>А вот это уже камень в сторону Intel. Потому что генерировать прерывание из *DIV без явного на то запроса — их глупость.

_>Глупость — не глупость, но это документированное поведение.

Здравствуйте, Ночной Смотрящий, Вы писали:

>>>>(А теперь встречный вопрос: почему в Windows до сих пор нет адекватного аналога удалённого шелла, которому не надо подымать графику? И чтобы все штатные средства управления могли обходиться без графики?)
eqw>>>С добрым утром. Есть Powershell, есть Windows Server Core.
N>>Да-да, про них рассказывают каждый раз на такие вопросы.
НС>Видимо, потому что это ответ на них.

Видимо, нет.

N>> Но никто не показал реального примера интерактивного использования этих средств админом

НС>А как ты видишь такой пример? PS+WinRM реально используются реальными админами, а Windows Core сейчас является вариантом установки по умолчанию.

Ну что, сложно написать пример? Лучше в стиле хабра (то есть сплошной конструктив, даже если без картинок).

Здравствуйте, CreatorCray, Вы писали:

CC> n>> А он снова запускается, сколько ни убивай. И жрёт 99% CPU, работать невозможно, простейшее действие тормозило на минуты.

CC> H>В таких случаях помогает принудительное выставление минимального приоритета. Я для этих целей использовал TaskManager Extension, он запоминает какому процессу выставляется какой приоритет.

CC> В таких случаях помогает sc delete <service name>

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

CC> Это WPF говно я выношу как только оно появляется. А появляется оно с каким нить богомерзским .NET Framework update.
CC> Судя по тому, что без него всё отлично работает — сервис этот суть бесполезное говноподелие

Видимо все отлично от того, что ты WPF-софтом не пользуешься