http://habrahabr.ru/post/179333/

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

M>http://habrahabr.ru/post/179333/

Опередил Какой наброс хороший. Добавлю только цитату

Причина проблем, по словам сотрудника Microsoft, социальная. Дело в том, что разработчики не вносят в ядро таких оптимизаций, которые мы видим в мире Linux. В компании Microsoft никто не будет хвалить программиста, если он оптимизировал какой-то процесс на 5%, если это не входит в сферу его основных обязанностей. Такая оптимизация никому не интересна. Только в случае какого-то очень существенного прогресса работу программиста могут заметить в соседних командах разработки, что положительно отразиться на его карьере. Но это скорее исключение, чем правило. Нет никакого стимула принимать изменения из-за пределов своей команды разработки.

и есть конкретные примеры, вроде

«Нам нельзя трогать именованные каналы. Лучше добавим %INTERNAL_NOTIFICATION_SYSTEM%! И пусть она будет несовместима с почти всеми другими именованными примитивами NT.

Мы не можем показывать %INTERNAL_NOTIFICATION_SYSTEM% остальному миру, потому что не хотим заниматься бумажной работой и терять продажи, ведь сейчас публично доступны только интерфейса Win32 APIs эпохи 90-х.

Мы не можем трогать DCOM. Так что создадим ещё один %C#_REMOTING_FLAVOR_OF_THE_WEEK%!

и другое.

По ссылкам на хабре нашел не менее вкусное, хотя и устаревшее. Письмо самого Билл Гейтса в котором он негодует насчет юзабельности винды как прямо какой красноглазый. Описывает свой жесткий квест в попытках поставить Movie Maker.

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

Какая жесть:

Именно в этом причина появления PowerShell: многие хотели улучшить cmd.exe, но не имели возможности.
...
Нельзя трогать Source Depot, так что давайте вместе хакнем SDX (Secure Document Exchange)!
Нельзя трогать SDX, так что давайте притворяться в течение четырёх релизов, что мы переходим на TFS (Team Foundation Server), а сами ничего не будем менять!

Какой то малолетний дурачок.

НС>Какой то малолетний дурачок

Они там в мс все похоже, те кто процессом рулит, такие

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

M>http://habrahabr.ru/post/179333/

Простите, о какой низкой производительности идёт речь? WinXP стоит даже на древних целеронах-800.

У любого разработчика есть менеджер, который ставит ему задачи, которые он должен выполнять. И никому не интересно, что разработчику хотелось бы заняться оптимизацией или другими интересными лично ему вещами.
Если разработчику такой порядок вещей не нравится, то ему нужно не статьи писать и ныть, а увольняться.
Почему разработчик думает, что кому-то будет лучше от того, что он оптимизирует производительность чего-то процентов на 10? Или даже на 100? На современных машинах и то, и другое скорее всего будет незаметно вообще.

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

M>http://habrahabr.ru/post/179333/

А тут "разработчик С++" объяснил причины кривого дизайна языка: http://www.getinfo.ru/article40.html

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

M>http://habrahabr.ru/post/179333/

Так вот почему у меня голая восьмёрка грузится раза в три дольше лялиха, на котором демонов навешано по самое немогу!

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

M>По ссылкам на хабре нашел не менее вкусное, хотя и устаревшее. Письмо самого Билл Гейтса в котором он негодует насчет юзабельности винды как прямо какой красноглазый. Описывает свой жесткий квест в попытках поставить Movie Maker.

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

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

M>>http://habrahabr.ru/post/179333/
T>А тут "разработчик С++" объяснил причины кривого дизайна языка: http://www.getinfo.ru/article40.html

Скажите, а это случайно не старая первоапрельская шутка?
Так похоже на правду, так похоже на правду

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

Здравствуйте, matfei.

Один из программистов компании Microsoft анонимно выступил на форуме Hacker News и
выдал интересные подробности о процессе разработки ядра NT.

Разве анонимки кому-то интересны ?

O>Разве анонимки кому-то интересны ?

на minimsft вроде большинство анонимно постили, однако интерес был немалый..

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

LC>Скажите, а это случайно не старая первоапрельская шутка?
LC>Так похоже на правду, так похоже на правду

Да, это действительно оказывается общеизвестный фейк

я то когда ковырял ядро восьмерки не мог понять, нафига они изобрели WNF (я расшифровываю это как Windows Notification Framework) и почему у него такой убогий API. Теперь понятно. Впрочем давно об этом догадывался, в ядре (и не только) винды в последнее время очень дофига видел сомнительных нововведений, вместо которых достаточно было аккуратненько допилить\пофиксить имеющийся функционал.

Господи, код NTFS — это багровый роман ужасов, написанный под опиумом в средневековье, где используются глобальные рекурсивные блокировки и управление потоком выполнения программы при помощи структурной обработкой исключений (SEH). Давайте вместо неё напишем ReFs. (И да, начнем с копипаста исходников NTFS и удаления половины функциональности! Теперь добавим контрольные суммы, потому что контрольные суммы это круто, и с контрольными суммами мы почти так же круты, как ZFS, верно? И вообще, кому нужны квоты?)

mwhaha.. именно так я это себе и представлял

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

M>Ты бы уж тогда ссылку привел, раз упомянул, может кому интересно.

Извиняюсь, забыл ссылку дать: http://habrahabr.ru/post/31623/

при этом про ядро NT:

https://neosmart.net/blog/2008/shipping-seven-is-a-fraud/comment-page-1/#comment-160264

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

D>Простите, о какой низкой производительности идёт речь? WinXP стоит даже на древних целеронах-800.

А то самое ядро восьмерки, которое ваще ужасно, стоит на Lumia 520 с ее гигагерцовым армом, которому до целерона как до пекина раком.

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

D>Так вот почему у меня голая восьмёрка грузится раза в три дольше лялиха, на котором демонов навешано по самое немогу!

Обычно в этом виноваты драйвера.

O>mwhaha.. именно так я это себе и представлял
из комментов:

Недавно вляпались в замечательный сбой новой модной файловой системы ReFS. Симптоматика, оказывается, известна. Убер-устойчивая новейшая ФС, которую разрабатывали 7 лет, дохнет от ребута так, что её нельзя восстановить штатными способами.

M>при этом про ядро NT:
M>https://neosmart.net/blog/2008/shipping-seven-is-a-fraud/comment-page-1/#comment-160264
Все правда, но в последних версиях NT микрософт закачивает в эту бочку меда все больше д.... Вообще у меня сложилось впечатление, что до ХР в микрософте было две толпы девелоперов — куча кармических индокодеров, штук так 10000 — они занимались шеллом, а так же ядром 9х как водицца — с песнями, плясками, в перерывах обрабатывая огород за кампусом при помощи волов. А еще в микрософте было штук 100 суровых бородатых мужиков, которые аккуратненько двигали ядро и низкоуровневые части NT тщательно обдумывая все архитектурные вещи по вечерам, попивая пивко в пабе. Потом 9х выпилили и всех девелоперов перемешали...

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

D>>Так вот почему у меня голая восьмёрка грузится раза в три дольше лялиха, на котором демонов навешано по самое немогу!

НС>Обычно в этом виноваты драйвера.

Я хз что там виндовато, но эта дрянь и после загрузки винтами шуршать не перестаёт битых полчаса. Оно заявлено что якобы временно перестаёт, если какое-то приложение запускаешь, но во-первых, ни хрена, а во-вторых, что там можно столько времени делать?!

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

НС>Здравствуйте, matfei, Вы писали:

НС>Какая жесть:
НС>

НС>Именно в этом причина появления PowerShell: многие хотели улучшить cmd.exe, но не имели возможности.
НС>...
НС>Нельзя трогать Source Depot, так что давайте вместе хакнем SDX (Secure Document Exchange)!
НС>Нельзя трогать SDX, так что давайте притворяться в течение четырёх релизов, что мы переходим на TFS (Team Foundation Server), а сами ничего не будем менять!

НС>Какой то малолетний дурачок.

Я в виндах не разбираюсь, можно пояснить тезис?

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

M>при этом про ядро NT:

M>https://neosmart.net/blog/2008/shipping-seven-is-a-fraud/comment-page-1/#comment-160264

Похвала ядру NT тут ещё как-то понятна (хотя и там есть подозрительные моменты), но сравнение с Linux в виде критики последнего явно за пределами адеквата. Нужно понимать, что поддержка старого ядерного API (речь не про userland) в Linux не применяется принципиально. Если бы была нужна — там бы сделали и достаточный аналог того же XPDM.
Ну а сказки про отрываемость WinAPI мы слышим уже лет 15. Сама возможность устранить поддержку вызовов не означает отрываемости API, если это API вносит свои принципиальные особенности в ядро. Вспомнить хотя бы \ в качестве разделителя частей пути — на уровне UNC уже допусти только он. А почему, ведь для Posix это нормальный символ имени?
Или рассказ, что, мол, HAL до сих пор несчастные 256KB. Ну да, если туда не вносить ACPICA, то запросто можно и меньше получить

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

MTD>Я в виндах не разбираюсь, можно пояснить тезис?

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

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

D>Я хз что там виндовато, но эта дрянь и после загрузки винтами шуршать не перестаёт битых полчаса.

Ну и пусть шуршит, тебе то что?

DD>а во-вторых, что там можно столько времени делать?!

Вирусы, к примеру, искать, или спекулятивно код подгружать, или сборки ngen'ить.

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

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

Для общего развития, если не сложно, как ты определил, что он не разбирается?

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

MTD>Для общего развития, если не сложно, как ты определил, что он не разбирается?

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

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

НС>По тем цитатам что я привел. Потому что я в предмете немножко разбираюсь.

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

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

НС>С возрастом такое обычно проходит.

Влепить что ли -1...

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

НС>Ну и пусть шуршит, тебе то что?

Да я в общем-то написал, что мне. Продолжает шуршать даже при запущенных приложениях. В результате, к примеру, DVD сразу после загрузки системы не посмотреть — лагает. Приходится ждать, пока эта дрянь закончит шуршать.

НС>Вирусы, к примеру, искать,

Антивируса нет. Дефрагментацию поставил на раз в месяц (хотя по-хорошему её вообще отрубить надо — у меня там только сейвы скайрима и перезаписываются). Но там ещё полтора миллиарда разных фоновых задач в настройках прописано — что есть полный @#&*^@* пределами добра и зла.

НС>или спекулятивно код подгружать, или сборки ngen'ить.

Что, каждый раз заново ngen-ить те же самые сборки? Почему у меня лялих ничего не ngen-ит, и сразу после старта иксов система полностью готова и idle?

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

D>Да я в общем-то написал, что мне. Продолжает шуршать даже при запущенных приложениях. В результате, к примеру, DVD сразу после загрузки системы не посмотреть — лагает. Приходится ждать, пока эта дрянь закончит шуршать.

1. Procmon или монитор ресурсов, ищем виноватого, убиваем.
2. SSD + сэкономленные нервы.
3. Холивар ещё на N страниц.

Выбирайте

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

D>В результате, к примеру, DVD сразу после загрузки системы не посмотреть — лагает. Приходится ждать, пока эта дрянь закончит шуршать.

Это уже не нормально. У меня не лагает.

НС>>Вирусы, к примеру, искать,

D>Антивируса нет.

Он в восьмерке встроенный.

НС>>или спекулятивно код подгружать, или сборки ngen'ить.
D>Что, каждый раз заново ngen-ить те же самые сборки?

Не те же самые. Сборок много, статистика использования меняется, особенно на свежепоставленной системе.

D> Почему у меня лялих ничего не ngen-ит

Потому что не умеет

D>и сразу после старта иксов система полностью готова и idle?

У меня тоже восьмерка сразу после старта готова, а возможные обращения к системному винту меня не колышат, особенно с учетом SSD.

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

D>>Простите, о какой низкой производительности идёт речь? WinXP стоит даже на древних целеронах-800.

НС>А то самое ядро восьмерки, которое ваще ужасно, стоит на Lumia 520 с ее гигагерцовым армом, которому до целерона как до пекина раком.

Это вопрос производительности юзерленда, не ядра.

В ядро упираются файловые операции, если их много, или сетевое взаимодействие. Вот реальный use case — копирование кучи мелких файлов с диска на флешку. Создай папку, создай в ней (гулять, так гулять) миллион файлов по 100 байт, скопируй папку на флешку. Сколько времени заняло?

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

RO>В ядро упираются файловые операции, если их много, или сетевое взаимодействие.

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

RO>Создай папку, создай в ней (гулять, так гулять) миллион файлов по 100 байт, скопируй папку на флешку. Сколько времени заняло?

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

P.S. ФС это не ядро, если что.

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

RO>>В ядро упираются файловые операции, если их много, или сетевое взаимодействие.
НС>Крута, че. В операциях где типичная латентность — десятки и сотни миллисекунд у нас оказывается важен перформанс ядра.

Т. е. для, например, фотохостинга приемлемо десятками—сотнями миллисекунд рыскать по ФС в поисках каждой из сотни миниатюр для фоточек из альбома? Веб-серверу достаточно порядка 0,1 мс, чтобы отдать маленький файл, и значительная часть этого времени приходится на системные вызовы. А в случае, как с флешкой, вопрос уже не в латентности, а в пропускной способности.

RO>>Создай папку, создай в ней (гулять, так гулять) миллион файлов по 100 байт, скопируй папку на флешку. Сколько времени заняло?
НС>И в этом, конечно, будет виновато ядро, а не то что организация флешки очень не любит кучу микроскопических записей.

Если оно не осилит писать на флешку большими кусками, а станет делать по операции записи на каждый файл, то будет.

НС>P.S. ФС это не ядро, если что.

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

Здравствуйте, Roman Odaisky, Вы писали:
RO>>>Создай папку, создай в ней (гулять, так гулять) миллион файлов по 100 байт, скопируй папку на флешку. Сколько времени заняло?
НС>>И в этом, конечно, будет виновато ядро, а не то что организация флешки очень не любит кучу микроскопических записей.
RO>Если оно не осилит писать на флешку большими кусками, а станет делать по операции записи на каждый файл, то будет.
А причем тут ядро вообще? Оно очень даже умеет(если дрова используемого накопителя позволяют). Проблема в криворуких писателях софта — Небось все эти файлы создавались при помощи синхронных дисковых функций в одном потоке?

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

RO>Т. е. для, например, фотохостинга приемлемо десятками—сотнями миллисекунд рыскать по ФС в поисках каждой из сотни миниатюр для фоточек из альбома?

При чем тут фотохостинг? У фотохостинга 100500 серверов для работы.

RO>А в случае, как с флешкой, вопрос уже не в латентности, а в пропускной способности.

Это ты так шутишь?

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

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

RO>В моем понимании очень даже ядро

А, ну понятно.

RO>, потому что нулевое кольцо

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

RO>Что же, по-твоему, ядро, если ты не включаешь туда ФС?

http://en.wikipedia.org/wiki/Microkernel например.

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

НС>Как то уж сильно тебя линукс покусал, монолитная какашка — не единственный вариант дизайна.

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

Здравствуйте, MTD, Вы писали:
MTD>Ну по крайней мере Линукс не удаляет часами много мелких файлов и не виснет намертво когда память закончилась, в отличии от гибридной какашки.
Да ладно
регулярно наблюдаю, как линук жутко тупил по несколько минут, когда унего заканчивается память и начинает свопиться.

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

RO>>Т. е. для, например, фотохостинга приемлемо десятками—сотнями миллисекунд рыскать по ФС в поисках каждой из сотни миниатюр для фоточек из альбома?
НС>При чем тут фотохостинг? У фотохостинга 100500 серверов для работы.
Они, думаю, не откажутся выкинуть их и поставить 1050 с более быстрой ОС :-)

RO>>А в случае, как с флешкой, вопрос уже не в латентности, а в пропускной способности.
НС>Это ты так шутишь?

Отправил миллион файлов на копирование, ждешь завершения миллиона операций записи.
Или отправил миллион файлов, ядро буферизовало запись и ты ждешь завершения тысячи операций записи. Файлов в секунду будет больше.

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

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

RO>>В моем понимании очень даже ядро
НС>А, ну понятно.
RO>>, потому что нулевое кольцо
НС>Все что в нулевом кольце у тебя ядро? Как то уж сильно тебя линукс покусал, монолитная какашка — не единственный вариант дизайна.

Единственный практически работоспособный пока что.

RO>>Что же, по-твоему, ядро, если ты не включаешь туда ФС?
НС>http://en.wikipedia.org/wiki/Microkernel например.

И какое отношение микроядра имеют к предмету обсуждения? Так можно дойти до того, что ни NTFS, ни WinAPI, ни 90% прочих технологий оттуда не являются частью ядра, и назвать оставшиеся 512 байт кода шедевром ядростроения. (Я знаю, что в некотором смысле все эти вещи и в самом деле отделены от ядра, но если NTFS тормозит, и WinAPI тормозит, и соответственно, программы тормозят, то много ли счастья от восхваления самой серединки NT-шного ядра?)

Кстати, к вопросу об ФС и микро/мегаядрах. В монолитном Линуксе можно сделать rmmod fat, а как выгрузить драйвер FAT из Windows?

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

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

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

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

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

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

MTD>Я не регулярно, но наблюдал это, при этом мог прибить процесс отожравжий память и продолжить нормально работать, в отличии от винды которой в такой ситуации только ресет помогает.
Счего вы взяли этот бред? Вней точно также можно спокойно убить прожорливый процесс. Более того, в ней гораздо лучше работает своппинг и от одного прожорливого до памяти процесса вся система не впадает в ступор, в отличии от линукса...

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

T>Счего вы взяли этот бред? Вней точно также можно спокойно убить прожорливый процесс. Более того, в ней гораздо лучше работает своппинг и от одного прожорливого до памяти процесса вся система не впадает в ступор, в отличии от линукса...

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

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

S>1. Procmon или монитор ресурсов, ищем виноватого, убиваем.
S>2. SSD + сэкономленные нервы.
S>3. Холивар ещё на N страниц.

S>Выбирайте

4. Винда не нужна.

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

НС>>Как то уж сильно тебя линукс покусал, монолитная какашка — не единственный вариант дизайна.

MTD>Ну по крайней мере Линукс не удаляет часами много мелких файлов

Зато большой файл удаляет минутами — один.

RO>Отправил миллион файлов на копирование, ждешь завершения миллиона операций записи.
это потому что запись на флэшку (почти) не буферизуется по дефолту, а не буферизуется она — потому что винда по дефолту считает юзера идиотом, который не знает про safe removal. Если вы не идиот — пересоберите ядро погуглите и включите кэширование записи флэшек.

RO>Кстати, к вопросу об ФС и микро/мегаядрах. В монолитном Линуксе можно сделать rmmod fat, а как выгрузить драйвер FAT из Windows?
ну в винде драйвер fastfat не загружен изначально если нет дисков с фат'ом, можно ли выгрузить его (sc stop fastfat) если отмонтировать все fat'овые диски — хз, но не вижу причин почему бы и нет

НС>>Как то уж сильно тебя линукс покусал, монолитная какашка — не единственный вариант дизайна.
MTD>Ну по крайней мере Линукс не удаляет часами много мелких файлов и не виснет намертво когда память закончилась, в отличии от гибридной какашки.
Винда тоже не виснет намертво. А вот кривые 3rd party дрова — они запросто и зависнуть могут и бсоднуцца.

Здравствуйте, MTD, Вы писали:
MTD>Свежо предание, да верится с трудом. Несколько лет назад я писал тулзы кушавшие память с целью тестирования в неблагоприятных условиях, так что про то как себя ведет винда знаю хорошо.
Я не сомниваюсь, что если задаться целью подвесить ось — можно написать утилиту, которая будет грузить её так, что все приложения будут тупить и почти не реагировать на действия пользователя. С другой стороны — я линукс не стараюсь уронить, но темнемение он временами начинает нереально тупить при нормальном обычном использовании.

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

T>С другой стороны — я линукс не стараюсь уронить, но темнемение он временами начинает нереально тупить при нормальном обычном использовании.

Он может тупить ровно в одном случае, как и другие ОС — битый винт. У меня обычная Ubuntu Server 8 годами работает на железках 450 МГц и 128 Мб ОЗУ.

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

MTD>>Ну по крайней мере Линукс не удаляет часами много мелких файлов

S>Зато большой файл удаляет минутами — один.

И не краснеет же

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

RO>Они, думаю, не откажутся выкинуть их и поставить 1050 с более быстрой ОС

ОС тут не поможет.

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

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

НС>>Все что в нулевом кольце у тебя ядро? Как то уж сильно тебя линукс покусал, монолитная какашка — не единственный вариант дизайна.
RO>Единственный практически работоспособный пока что.

Ха ха.

RO>И какое отношение микроядра имеют к предмету обсуждения?

Довольно близкое. Ядро NT конечно гибридное, но NTшный HAL недалеко от микрокернела ушел.

RO>Так можно дойти до того, что ни NTFS, ни WinAPI, ни 90% прочих технологий оттуда не являются частью ядра

Так и есть. Вот в WP8 ни NTFS, ни WinAPI, ни кучи других технологий нет, а ядро есть. Я ж говорю, не все ОС представляют собой монолитную какашку.

RO>Кстати, к вопросу об ФС и микро/мегаядрах. В монолитном Линуксе можно сделать rmmod fat, а как выгрузить драйвер FAT из Windows?

http://en.kioskea.net/faq/1886-enable-disable-a-device-from-the-command-line

Когда ставят "-1" и не пишут с чем именно не согласны, то это означает "он чертовски прав, но подо мной горит стул" .

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

T>Счего вы взяли этот бред? Вней точно также можно спокойно убить прожорливый процесс. Более того, в ней гораздо лучше работает своппинг и от одного прожорливого до памяти процесса вся система не впадает в ступор, в отличии от линукса...

Ты не путаешь систему и графическую подсистему? Те два раза — за последние 10 лет, что у меня тупил линукс — это были Х-ы, ctrl+alt+f2 — убиваем иксы. Все остальное работает. Впрочем XP или 7-а нормальные системы — но в их случае помогал только ресет. На серверах — у меня X нет. Вроде последние виндовые — тоже можно ставить без гуя.

Здравствуйте, pzhy, Вы писали:
P>Ты не путаешь систему и графическую подсистему? Те два раза — за последние 10 лет, что у меня тупил линукс — это были Х-ы, ctrl+alt+f2 — убиваем иксы. Все остальное работает. Впрочем XP или 7-а нормальные системы — но в их случае помогал только ресет. На серверах — у меня X нет. Вроде последние виндовые — тоже можно ставить без гуя.
Нет, не путаю. Да, висли иксы. Но какая нафиг рабочая станция или домашний комп без ГУИ? Если в линуксе нет нормального роботающего ГУИ — это ось для серверов, для десктопов это говноось, место которой на помоичке. Именно поэтому я расматриваю линукс вместе с иксами, потому что насколько бы надежным он небыл без иксов — он нафиг такой ненужен.

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

RO>>И какое отношение микроядра имеют к предмету обсуждения?
НС>Довольно близкое. Ядро NT конечно гибридное, но NTшный HAL недалеко от микрокернела ушел.

Именно HAL? От микроядра? Признайся, что пошутил.

RO>>Так можно дойти до того, что ни NTFS, ни WinAPI, ни 90% прочих технологий оттуда не являются частью ядра

НС>Так и есть. Вот в WP8 ни NTFS, ни WinAPI, ни кучи других технологий нет, а ядро есть. Я ж говорю, не все ОС представляют собой монолитную какашку.

И где же в Windows отделённые, сидящие за пределами ring0, драйверы внешних устройств? Приведи хотя бы два примера активно используемых таких драйверов.
А без таких примеров ядро NT та же "монолитная какашка".

RO>>Кстати, к вопросу об ФС и микро/мегаядрах. В монолитном Линуксе можно сделать rmmod fat, а как выгрузить драйвер FAT из Windows?

НС>http://en.kioskea.net/faq/1886-enable-disable-a-device-from-the-command-line

Что-то ни слова не видно про выгрузку собственно драйвера.

P.S. В благословенных 90-х тред в RU.OS.CMP под сабжектом "Динамическая выгрузка драйверов в NT?" продолжался более года и набрал несколько тысяч сообщений

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

T>>С другой стороны — я линукс не стараюсь уронить, но темнемение он временами начинает нереально тупить при нормальном обычном использовании.

MTD>Он может тупить ровно в одном случае, как и другие ОС — битый винт.

Или 12309, извините за банальность. А нарваться на него тривиально, сильно легче, чем в Windows (и тем более в *BSD, в которых его не бывало никогда).

MTD> У меня обычная Ubuntu Server 8 годами работает на железках 450 МГц и 128 Мб ОЗУ.

Верю, но там явно не те задачи.

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

N>И где же в Windows отделённые, сидящие за пределами ring0, драйверы внешних устройств?

Принтеры, сканеры.

N>А без таких примеров ядро NT та же "монолитная какашка".

Та, да не та.

N>Что-то ни слова не видно про выгрузку собственно драйвера.

Disable драйвера в винде эквивалентен его выгрузке.

N>P.S. В благословенных 90-х тред в RU.OS.CMP под сабжектом "Динамическая выгрузка драйверов в NT?" продолжался более года и набрал несколько тысяч сообщений

Ну вот и не раздувай.

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

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

N>>И где же в Windows отделённые, сидящие за пределами ring0, драйверы внешних устройств?

НС>Принтеры, сканеры.

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

N>>А без таких примеров ядро NT та же "монолитная какашка".
НС>Та, да не та.

И в чём разница? Прошу всё-таки раскрыть подробнее.

N>>Что-то ни слова не видно про выгрузку собственно драйвера.
НС>Disable драйвера в винде эквивалентен его выгрузке.

Он при этом физически удаляется из памяти? И уверен ли ты в этом для случая драйвера FAT?

N>>P.S. В благословенных 90-х тред в RU.OS.CMP под сабжектом "Динамическая выгрузка драйверов в NT?" продолжался более года и набрал несколько тысяч сообщений
НС>Ну вот и не раздувай.

А я и не раздуваю.

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

RO>>Отправил миллион файлов на копирование, ждешь завершения миллиона операций записи.
O>это потому что запись на флэшку (почти) не буферизуется по дефолту, а не буферизуется она — потому что винда по дефолту считает юзера идиотом, который не знает про safe removal. Если вы не идиот — пересоберите ядро погуглите и включите кэширование записи флэшек.

Что только люди не сделают, чтобы не сделать Softupdates в драйвере, который прямо напрашивается на это...

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

N>Несерьёзно.

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

N> Вынеси видеодрайвер (в версиях начиная с NT4) или драйвер сетевухи

Выносить из ядра критичные к перформансу вещи — вряд ли имеет смысл. Да и суть не в том, что в каком кольце выполняется, а в модульности.

N>>>Что-то ни слова не видно про выгрузку собственно драйвера.
НС>>Disable драйвера в винде эквивалентен его выгрузке.

N>Он при этом физически удаляется из памяти?

Да.

N> И уверен ли ты в этом для случая драйвера FAT?

На 100% нет и пробовать лень, но, как тут уже сказали, при отсутствии FAT дисков он таки выгружается автоматично, так что не думаю что будут проблемы.

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

N>> Вынеси видеодрайвер (в версиях начиная с NT4) или драйвер сетевухи
НС>Выносить из ядра критичные к перформансу вещи — вряд ли имеет смысл. Да и суть не в том, что в каком кольце выполняется, а в модульности.

Твоё понимание явно не соответствует стандартному определению микроядра, для которого явно сказано:

If the hardware provides multiple rings or CPU modes, the microkernel is the only software executing at the most privileged level

Traditional operating system functions, such as device drivers, protocol stacks and file systems, are removed from the microkernel to run in user space.

Заменять это понятие на возможность собираемости из мелких модулей плохо, потому что
1) Противоречит принятому
2) Если его принять, то Linux (мы ведь с ним сравниваем?) ничем не будет отличаться. Самые тяжёлые части всё равно не HAL, его бессмысленно приводить в пример, а всякие Executive. И чтобы собрать целевую систему под какой-нибудь embedded, пилить компоненты на части, производя художественную резку лобзиком, придётся по любому. Но в Linux для этого есть готовое средство в виде конфигурации ядра, в которой можно убрать практически всё, а для Windows придётся таки резать сорцы. А драйвера идут практически все модулями, и ненужные не будут грузиться.

Кстати, классический SysV подход ещё показательнее в этом смысле — там при старте системы работал динамический линкер, который собирал ядро в памяти из отдельных модулей. Модульность современных юниксов в этом смысле — возврат к SysV, а не ориентация на другие системы, как тот же Windows.

N>>>>Что-то ни слова не видно про выгрузку собственно драйвера.
НС>>>Disable драйвера в винде эквивалентен его выгрузке.
N>>Он при этом физически удаляется из памяти?
НС>Да.
N>> И уверен ли ты в этом для случая драйвера FAT?
НС>На 100% нет и пробовать лень, но, как тут уже сказали, при отсутствии FAT дисков он таки выгружается автоматично, так что не думаю что будут проблемы.

Хотелось бы посмотреть на отчёт соответствующего инструмента.

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

D>>Да я в общем-то написал, что мне. Продолжает шуршать даже при запущенных приложениях. В результате, к примеру, DVD сразу после загрузки системы не посмотреть — лагает. Приходится ждать, пока эта дрянь закончит шуршать.
S>1. Procmon или монитор ресурсов, ищем виноватого, убиваем.

А он снова запускается, сколько ни убивай. И жрёт 99% CPU, работать невозможно, простейшее действие тормозило на минуты.
Называлась эта дрянь как-то похоже на WPF Font Cache Updater, проявлялось на XP. Причём была в двух версиях (3 и 4), приходилось раздельно каждую выключать в сервисах.
Да, это я не про Windows 8. Но случай аналогичный.

S>2. SSD + сэкономленные нервы.

SSD тут не помог бы, да и жалко его, если кто-то активно пишет ерунду вместо полезных данных.

S>3. Холивар ещё на N страниц.
S>Выбирайте

Тут за меня уже предложили самый правильный вариант пункта 4

O>Винда тоже не виснет намертво. А вот кривые 3rd party дрова — они запросто и зависнуть могут и бсоднуцца.
Мне иногда кажется, что они специально позволили дровам делать что угодно и не защитили систему от их неправильного функционирования чтобы в случае чего было на кого валить. Oтсутствие индикации, понятной обычному пользователю, о том какие именно дрова подвесили машину — тоже большой плюс

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

T>Нет, не путаю. Да, висли иксы. Но какая нафиг рабочая станция или домашний комп без ГУИ? Если в линуксе нет нормального роботающего ГУИ — это ось для серверов, для десктопов это говноось, место которой на помоичке. Именно поэтому я расматриваю линукс вместе с иксами, потому что насколько бы надежным он небыл без иксов — он нафиг такой ненужен.

Тупление Х у меня — было всегда связано с видео драйверами. С одной стороны — технически это не проблемма линукса — с другой, пользователей на ней не будет пока так. Впрочем в последние два года я ничего подобного не наблюдал(драйвер интела). Но линукс — это еще и мобильная ось, и встроенных систем.

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

O>>Винда тоже не виснет намертво. А вот кривые 3rd party дрова — они запросто и зависнуть могут и бсоднуцца.
Q>Мне иногда кажется, что они специально позволили дровам делать что угодно и не защитили систему от их неправильного функционирования чтобы в случае чего было на кого валить. Oтсутствие индикации, понятной обычному пользователю, о том какие именно дрова подвесили машину — тоже большой плюс

Гм... а почему ты думаешь, что такая индикация в принципе возможна? Если можно идентифицировать, кто виноват, то понятно, и в чём он виноват, а тогда можно и исправить его последствия.
Вот представь себе, что драйвер принял строку как указатель и намутил чего-то в левом (для него) куске памяти, который принадлежит другому драйверу. Тот второй драйвер от этого упал. И как ты выяснишь, кто виноват?

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

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

N>Несерьёзно. Вынеси видеодрайвер (в версиях начиная с NT4) или драйвер сетевухи, вот тогда можно будет частично приблизиться к понятию микроядра.

Надо бы сперва gdi вынести из ring0 с его ограничением 16K дескрипторов.

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

D>> Почему у меня лялих ничего не ngen-ит

НС>Потому что не умеет

Нет, скорее потому что ему это не надо.

НС>У меня тоже восьмерка сразу после старта готова, а возможные обращения к системному винту меня не колышат, особенно с учетом SSD.

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

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

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

N>>Несерьёзно. Вынеси видеодрайвер (в версиях начиная с NT4) или драйвер сетевухи, вот тогда можно будет частично приблизиться к понятию микроядра.

_>Надо бы сперва gdi вынести из ring0 с его ограничением 16K дескрипторов.

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

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

S>>Зато большой файл удаляет минутами — один.
MTD>И не краснеет же

В общем, так и есть (было).
Вот замечательная история: http://www.depesz.com/2010/04/04/how-to-remove-backups/
100G файл удаляется 8 минут! Это типичное поведение ext3 из-за долбанутой системы косвенного маппинга дисковых блоков, которое иногда может достигать 3-х уровней.
В итоге админ нашел костыль. Он отрезал файл по частям с помощью truncate() с засыпаниями в промежутках, что позволило избежать слишком уж резких провалов, но растягивало удаление на оооочень долго.

ext4 изменил ситуацию к лучшему, потому что там (наконец!) появились extents, а поддержка косвенной адресации осталась для совместимости для файлов, мигрировавших из ext3/ext2.

Но даже в ext4 удаление 60G файла хавало примерно 8 секунд процессорного времени на MIPS машине. 4 секунды на сам вызов unlink() и 4 секунды съедал jbd2 во время коммита транзакции. Беда в том, что серваки обычно поставляются с невытесняющим ядром, а значит эти два этапа намертво вывешивают ядро процессора 2 раза несколько секунд каждый. На одноядернике, например в каком-нибудь простеньком армовом NAS — это пичалька.
Фиксы вышли в 3.7 для unlink() части, и в 3.11 для jbd2 части. (оптимизация по cpu на два-три порядка).

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

N>>>Несерьёзно. Вынеси видеодрайвер (в версиях начиная с NT4) или драйвер сетевухи, вот тогда можно будет частично приблизиться к понятию микроядра.
_>>Надо бы сперва gdi вынести из ring0 с его ограничением 16K дескрипторов.
eqw>и получить такой же тормозящй гуй, как в линуксе? Спасибо, не надо.

Ты даже приблизительно не знаешь, где и почему у тебя тормозит гуй, раз пишешь такое. Hint: почитай про Wayland.

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

S>>>Зато большой файл удаляет минутами — один.
MTD>>И не краснеет же
AD>В общем, так и есть (было).
AD>Вот замечательная история: http://www.depesz.com/2010/04/04/how-to-remove-backups/
AD>100G файл удаляется 8 минут! Это типичное поведение ext3 из-за долбанутой системы косвенного маппинга дисковых блоков, которое иногда может достигать 3-х уровней.

Что за чушь? При чём тут косвенные блоки? Во-первых, косвенные блоки существовали ещё в V6 Unix, и с тех пор существуют практически во всех юниксовых FS. Во-вторых, с ними подобное освобождение крупных ресурсов проходит значительно быстрее. И FS, где они есть, ведут себя очень по-разному (например, таких задержек нет на UFS, хотя там те же косвенные блоки).
Я понял, что статью Вы не читали, ограничившись проездом по первому, что взбрело в голову. А там, между прочим, сказано:

ext3, when freeing disk space is doing some kind of defragmentation, which moves some data around to maximize continuous free disk space.

К косвенным блокам этот механизм не имеет ни малейшего отношения.

AD>В итоге админ нашел костыль. Он отрезал файл по частям с помощью truncate() с засыпаниями в промежутках, что позволило избежать слишком уж резких провалов, но растягивало удаление на оооочень долго.

AD>ext4 изменил ситуацию к лучшему, потому что там (наконец!) появились extents, а поддержка косвенной адресации осталась для совместимости для файлов, мигрировавших из ext3/ext2.

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

AD>Но даже в ext4 удаление 60G файла хавало примерно 8 секунд процессорного времени на MIPS машине.

Простите, а что Вы ещё хотели? И журнал чего-то стоит, и запись факта свободного места в таблицы распределения, и обновление суммарных данных — это всё чего-то стоит.

AD> 4 секунды на сам вызов unlink() и 4 секунды съедал jbd2 во время коммита транзакции. Беда в том, что серваки обычно поставляются с невытесняющим ядром, а значит эти два этапа намертво вывешивают ядро процессора 2 раза несколько секунд каждый. На одноядернике, например в каком-нибудь простеньком армовом NAS — это пичалька.
AD>Фиксы вышли в 3.7 для unlink() части, и в 3.11 для jbd2 части. (оптимизация по cpu на два-три порядка).

3.11 чего, простите? На сейчас последнее доступное ядро — 3.10-rc1. У Вас машина времени?
Про недоработки в ядре в плане оптимизации этих операций — верю. Но "невытесняющее" ядро есть сильно шире, чем только на NASах.

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

НС>Какой то малолетний дурачок.

Увы, уровень аргументации не очень умного человека.

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

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

N>>>>Несерьёзно. Вынеси видеодрайвер (в версиях начиная с NT4) или драйвер сетевухи, вот тогда можно будет частично приблизиться к понятию микроядра.
_>>>Надо бы сперва gdi вынести из ring0 с его ограничением 16K дескрипторов.
eqw>>и получить такой же тормозящй гуй, как в линуксе? Спасибо, не надо.

N>Ты даже приблизительно не знаешь, где и почему у тебя тормозит гуй, раз пишешь такое. Hint: почитай про Wayland.
У меня он не тормозит, он тормозит у линуксоидов. И тормозит в том числе потому, что графическая подсистема там сделана «правильно» (овердмзайн иксов) и не засунута в ядро.
Wayland является убогой попыткой сделать это более эффективно, но находится в зачаточном состоянии и неизвестно когда будет в состоянии заменить иксы

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


AD>>100G файл удаляется 8 минут! Это типичное поведение ext3 из-за долбанутой системы косвенного маппинга дисковых блоков, которое иногда может достигать 3-х уровней.

N>Что за чушь? При чём тут косвенные блоки? Во-первых, косвенные блоки существовали ещё в V6 Unix, и с тех пор существуют практически во всех юниксовых FS. Во-вторых, с ними подобное освобождение крупных ресурсов проходит значительно быстрее. И FS, где они есть, ведут себя очень по-разному (например, таких задержек нет на UFS, хотя там те же косвенные блоки).

60G — это третий уровень косвенности. Ты представляешь каковы накладные расходы на то, чтобы пробраться через три уровня, собрать все (вполне вероятно) разбросанные по группам оконечные листья и сами косвенные блоки, зажурналировать и освободить все это дело???
Если на каких-то системах с косвенной адресацией удаление 60G файла не тормозит, то только потому, что реальное освобождение отложено во времени, либо выполнялось в фоне.
Все современные и даже не очень ФС (ext4, jfs, xfs, ntfs, hfs) используют экстенты, потому что косвенная адресация сосет на больших файлах.

N>Я понял, что статью Вы не читали, ограничившись проездом по первому, что взбрело в голову. А там, между прочим, сказано:
N>

ext3, when freeing disk space is doing some kind of defragmentation, which moves some data around to maximize continuous free disk space.

N>К косвенным блокам этот механизм не имеет ни малейшего отношения.
Статью я читал. Дефрагментация — это заблуждение автора статьи, который где-то что-то слышал.
Тормоза из-за косвенной адресации и фрагментации.

AD>>ext4 изменил ситуацию к лучшему, потому что там (наконец!) появились extents, а поддержка косвенной адресации осталась для совместимости для файлов, мигрировавших из ext3/ext2.
N>Если ext4 это улучшил, то только потому, что изменил политику отношения к фрагментации. Политика в ext3 действительно была примером не вполне понятного подхода.

Что есть "политика отношения к фрагментации"?
ext4 стал гораздо быстрее из-за поддержки экстентов (т.е. отсутствия косвенности), multi-block аллокатора (в ext3 место выделяется поблочно, даже если запросить стопицот мегабайт сразу), и delalloc (отложенное выделение места, чтоб снизить фрагментацию).

AD>>Но даже в ext4 удаление 60G файла хавало примерно 8 секунд процессорного времени на MIPS машине.
N>Простите, а что Вы ещё хотели? И журнал чего-то стоит, и запись факта свободного места в таблицы распределения, и обновление суммарных данных — это всё чего-то стоит.
В случае ext4 это был пузырек, который я заменил на quick sort.

N>3.11 чего, простите? На сейчас последнее доступное ядро — 3.10-rc1. У Вас машина времени?
3.10, опечатался.

Здравствуйте, netch80, Вы писали:
AD>>Но даже в ext4 удаление 60G файла хавало примерно 8 секунд процессорного времени на MIPS машине.

N>Простите, а что Вы ещё хотели? И журнал чего-то стоит, и запись факта свободного места в таблицы распределения, и обновление суммарных данных — это всё чего-то стоит.

Почему мелкософт еще 20 лет назад смогла сделать надежную быструю ФС, не страдающую подобными проблемами, а линукс досихпор не может родить что-нить юзабельное?

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

T>Почему мелкософт еще 20 лет назад смогла сделать надежную быструю ФС, не страдающую подобными проблемами, а линукс досихпор не может родить что-нить юзабельное?

Это какая?

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

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

T>>Почему мелкософт еще 20 лет назад смогла сделать надежную быструю ФС, не страдающую подобными проблемами, а линукс досихпор не может родить что-нить юзабельное?

MTD>Это какая?
NTFS

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

T>Здравствуйте, netch80, Вы писали:
AD>>>Но даже в ext4 удаление 60G файла хавало примерно 8 секунд процессорного времени на MIPS машине.

N>>Простите, а что Вы ещё хотели? И журнал чего-то стоит, и запись факта свободного места в таблицы распределения, и обновление суммарных данных — это всё чего-то стоит.

T>Почему мелкософт еще 20 лет назад смогла сделать надежную быструю ФС, не страдающую подобными проблемами, а линукс досихпор не может родить что-нить юзабельное?

У Вас есть опыт использования NTFS на MIPS машине средней производительности с файлами по 60GB?
Если да — поделитесь. Если нет — Вашим утверждениям и Вашему пафосу цена ноль целых хер десятых.

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

AD>>>100G файл удаляется 8 минут! Это типичное поведение ext3 из-за долбанутой системы косвенного маппинга дисковых блоков, которое иногда может достигать 3-х уровней.
N>>Что за чушь? При чём тут косвенные блоки? Во-первых, косвенные блоки существовали ещё в V6 Unix, и с тех пор существуют практически во всех юниксовых FS. Во-вторых, с ними подобное освобождение крупных ресурсов проходит значительно быстрее. И FS, где они есть, ведут себя очень по-разному (например, таких задержек нет на UFS, хотя там те же косвенные блоки).
AD>60G — это третий уровень косвенности. Ты представляешь каковы накладные расходы на то, чтобы пробраться через три уровня, собрать все (вполне вероятно) разбросанные по группам оконечные листья и сами косвенные блоки, зажурналировать и освободить все это дело???

Представляю, чего тут не представлять. Предположим 1KB блок (сейчас такое редко увидишь, но пусть). 60 миллионов блоков данных — 240 тысяч косвенных блоков (для простоты, уровни дальше последнего не считаем), а в общем случае это 4/1024 == 1/256 от всех занятых блоков, то есть меньше процента — можно их не учитывать. Теперь в таблицах занятости надо поставить признаки свободности всех этих блоков. Предположим, что это всё битовые карты. Тогда они потратят 8000 блоков этих самых карт. Теперь оценим, сколько займут 1) 240000 чтений блоков, 2) 8000 чтений и записей блоков? Даже такое дорогое чтение это пара секунд. Запись свободных — ещё быстрее.

Я не против экстентов, я против взваливания проблем ext3 на механизм, который не способен их обеспечить. Ещё на UFS1 (FreeBSD) у нас были файлы ну не по 100, но по 10GB. По-Вашему они должны были удаляться около минуты, потому что идёт очень много возни с косвенными блоками? А на практике файл удалялся практически мгновенно (задержка не замечалась человеком). Разумеется, часть затрат сокращалась за счёт более разумного размера блока (8KB по умолчанию), но даже это не сократило бы время менее чем до 10 секунд, если бы Ваши оценки источников затрат были адекватными.

Так что болезни ext3 в чём-то другом. Например, в неадекватной работе с журналом или, в общем случае, в чрезмерной грануляции операций.

AD>Если на каких-то системах с косвенной адресацией удаление 60G файла не тормозит, то только потому, что реальное освобождение отложено во времени, либо выполнялось в фоне.
AD>Все современные и даже не очень ФС (ext4, jfs, xfs, ntfs, hfs) используют экстенты, потому что косвенная адресация сосет на больших файлах.

Ещё раз: что значит "тормозит"? Удалять такой (60, 100GB), файл пусть даже 10 секунд — я согласен, накладные расходы хоть как-то, но связаны именно с косвенными блоками. 8 минут — нет, ищите причину в другом.

N>>Я понял, что статью Вы не читали, ограничившись проездом по первому, что взбрело в голову. А там, между прочим, сказано:
N>>

ext3, when freeing disk space is doing some kind of defragmentation, which moves some data around to maximize continuous free disk space.

N>>К косвенным блокам этот механизм не имеет ни малейшего отношения.
AD>Статью я читал. Дефрагментация — это заблуждение автора статьи, который где-то что-то слышал.

Пусть так.

AD>Тормоза из-за косвенной адресации и фрагментации.

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

AD>>>ext4 изменил ситуацию к лучшему, потому что там (наконец!) появились extents, а поддержка косвенной адресации осталась для совместимости для файлов, мигрировавших из ext3/ext2.
N>>Если ext4 это улучшил, то только потому, что изменил политику отношения к фрагментации. Политика в ext3 действительно была примером не вполне понятного подхода.
AD>Что есть "политика отношения к фрагментации"?

Насколько она считается допустимой и какие методы борьбы применяются. Какая политика распределения файлов по диску, хотя бы в том, какие зазоры между файлами считаются нормальными. Какая средняя длина связного фрагмента (экстента, если он явно представлен). Применяется ли намеренное фрагментирование, и если да, то как именно и при каких условиях. (Если помните, та же UFS1 старается выделять одному файлу не более половины полосы — и это практически помогает сократить фрагментацию.) Возможные операции по перегруппировке размещения данных, насколько они применяются при каких операциях.

AD>ext4 стал гораздо быстрее из-за поддержки экстентов (т.е. отсутствия косвенности), multi-block аллокатора (в ext3 место выделяется поблочно, даже если запросить стопицот мегабайт сразу), и delalloc (отложенное выделение места, чтоб снизить фрагментацию).

AD>>>Но даже в ext4 удаление 60G файла хавало примерно 8 секунд процессорного времени на MIPS машине.
N>>Простите, а что Вы ещё хотели? И журнал чего-то стоит, и запись факта свободного места в таблицы распределения, и обновление суммарных данных — это всё чего-то стоит.
AD>В случае ext4 это был пузырек, который я заменил на quick sort.

Ну я бы не сказал, что пузырёк был жёстко обусловлен использованием концепций ext3.

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

N>>>>>Несерьёзно. Вынеси видеодрайвер (в версиях начиная с NT4) или драйвер сетевухи, вот тогда можно будет частично приблизиться к понятию микроядра.
_>>>>Надо бы сперва gdi вынести из ring0 с его ограничением 16K дескрипторов.
eqw>>>и получить такой же тормозящй гуй, как в линуксе? Спасибо, не надо.
N>>Ты даже приблизительно не знаешь, где и почему у тебя тормозит гуй, раз пишешь такое. Hint: почитай про Wayland.
eqw>У меня он не тормозит, он тормозит у линуксоидов.

Факты в студию. Где тормозит, на чём, какая разница в скорости, при каких условиях.

eqw> И тормозит в том числе потому, что графическая подсистема там сделана «правильно» (овердмзайн иксов) и не засунута в ядро.

Ага, отмазался — этим "в том числе". То есть причины якобы есть, но объяснить их ты не можешь.

eqw>Wayland является убогой попыткой сделать это более эффективно,

Уже сразу и "убогой".

eqw> но находится в зачаточном состоянии и неизвестно когда будет в состоянии заменить иксы

От вопроса, нужен ли собственно GDI (а не видеодрайвер) в ядре, ты благополучно ушёл.

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

MTD>Увы, уровень аргументации не очень умного человека.

А уж твой то — обозвал дураком и типа все доказал.

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

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

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

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

MTD>>Увы, уровень аргументации не очень умного человека.

НС>А уж твой то — обозвал дураком и типа все доказал.

В отличии от тебя я так никого не называл, а вежливо попросил объяснить: здесь

Автор: MTD
Дата: 13.05.13

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

MTD>>>Увы, уровень аргументации не очень умного человека.

НС>>А уж твой то — обозвал дураком и типа все доказал.

MTD>В отличии от тебя я так никого не называл

См. выделенное.

MTD>, а вежливо попросил объяснить: здесь

Автор: MTD
Дата: 13.05.13

Мне, честно говоря, лень.

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

НС>Здравствуйте, MTD, Вы писали:

MTD>>>>Увы, уровень аргументации не очень умного человека.

НС>>>А уж твой то — обозвал дураком и типа все доказал.

MTD>>В отличии от тебя я так никого не называл

НС>См. выделенное.

Там не конкретно про тебя, а про уровень твоей аргументации.

MTD>>, а вежливо попросил объяснить: здесь

Автор: MTD
Дата: 13.05.13

НС>Мне, честно говоря, лень.

Почитав твои сообщения в теме, сильно сомневаюсь, что просто лень

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

MTD>Там не конкретно про тебя, а про уровень твоей аргументации.

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

MTD>>>, а вежливо попросил объяснить: здесь

Автор: MTD
Дата: 13.05.13

НС>>Мне, честно говоря, лень.
MTD>Почитав твои сообщения в теме, сильно сомневаюсь, что просто лень

Да ради бога.

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

_>Надо бы сперва gdi вынести из ring0 с его ограничением 16K дескрипторов.

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

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

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

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

n> S>1. Procmon или монитор ресурсов, ищем виноватого, убиваем.

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

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

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

НС>Ну тогда у тебя "уровень аргументации откровенно тупого человека", так можно сказать? Я ж не про тебя, а про уровень твоей аргументации.

Ну если тебе от этого полегчает — на здоровье!

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

N>Представляю, чего тут не представлять. Предположим 1KB блок (сейчас такое редко увидишь, но пусть). 60 миллионов блоков данных — 240 тысяч косвенных блоков (для простоты, уровни дальше последнего не считаем), а в общем случае это 4/1024 == 1/256 от всех занятых блоков, то есть меньше процента — можно их не учитывать. Теперь в таблицах занятости надо поставить признаки свободности всех этих блоков. Предположим, что это всё битовые карты. Тогда они потратят 8000 блоков этих самых карт. Теперь оценим, сколько займут 1) 240000 чтений блоков, 2) 8000 чтений и записей блоков? Даже такое дорогое чтение это пара секунд. Запись свободных — ещё быстрее.

240000 блоков — это 240 мегабайт данных. Современные жесткие диски в принципе способны прочитать 240 метров за две секунды, если данные распологаются последовательно.
Во-первых, такое количество блоков скорее всего разбросаны по диску, так что ни о каких 2 секундах речи быть не может.
Во-вторых, все косвенные блоки — это метаданные, а значит должны пройти через журнал. С этим беда.

N>Я не против экстентов, я против взваливания проблем ext3 на механизм, который не способен их обеспечить. Ещё на UFS1 (FreeBSD) у нас были файлы ну не по 100, но по 10GB. По-Вашему они должны были удаляться около минуты, потому что идёт очень много возни с косвенными блоками? А на практике файл удалялся практически мгновенно (задержка не замечалась человеком). Разумеется, часть затрат сокращалась за счёт более разумного размера блока (8KB по умолчанию), но даже это не сократило бы время менее чем до 10 секунд, если бы Ваши оценки источников затрат были адекватными.

С FreeBSD/UFS я не работал. UFS журналирует метаданные? Полностью?
По крайней мере на Solaris он удаляет в фоне.
http://ptgmedia.pearsoncmg.com/images/0131482092/samplechapter/mcdougall_ch15.pdf

Delete queue. Is active if UFS logging is enabled and consists of inodes that
are unlinked or deleted (v_count equals 1 and i_nlink is less than or equal
to 0). This queue is a performance enhancer for file systems with logging
turned on and observing heavy deletion activity. The delete queue is handled
by the per-file system delete thread, which queues the inodes to be deleted by
the ufs_delete() thread. This significantly boosts response times for
removal of large amounts of data. If logging is not enabled, ufs_delete()
is called immediately. ufs_delete() calls VN_RELE() after it has finished
processing, which causes the inode to once again be processed by ufs_
inactive, which this time puts it on the idle queue. While on the delete
queue, the inode’s i_freef and i_freeb point to the inode itself since the
inodes are not free yet.

http://osdir.com/ml/os.solaris.opensolaris.ufs/2007-10/msg00000.html

It's on Solaris 10 u4. UFS on a single internal disk is used with default mount
options. When deteting about 1000 files (rm -fr *), whose size varies from 10MB
to 2GB in random, and 300GB in total, Solaris takes about 10 to 15 minutes to
complete disk I/O although rm is returned immediately after it's issued. iostat
continuously shows approximately 400 w/s with 7000 kw/s on the UFS affected.
During that period of time, creating and writing new files on that UFS is very
slow. io provider of DTrace shows that it's the sched who is related to the
disk I/O, but DTrace script didn't give the name of the file related to the
I/O. Please help explain why it behaved like that, and how to improve the
performance.

N>Так что болезни ext3 в чём-то другом. Например, в неадекватной работе с журналом или, в общем случае, в чрезмерной грануляции операций.
Как раз в ext3 транзакции группируются в другие транзакции, чтоб было быстрее.


AD>>Тормоза из-за косвенной адресации и фрагментации.
N>Первое мы уже разобрали и я с ним не соглашусь. Второе — что Вы имеете в виду под фрагментацией? То, что файл разбросан по диску, или что-то другое?
Да, косвенные блоки и сам файл. Система конечно пытается группировать их, но косвенность подразумевает как минимум пару перемещений головок для доступа к данным. Со временем все становится совсем плохо, если не дефрагментировать.

Здравствуйте, netch80, Вы писали:
N>У Вас есть опыт использования NTFS на MIPS машине средней производительности с файлами по 60GB?
причем тут твой MIPS, когда мы говорим про применение ФС на десктопах с IA32 и IA/AMD64?
N>Если да — поделитесь. Если нет — Вашим утверждениям и Вашему пафосу цена ноль целых хер десятых.
Цена ноль вашим неуместным выпадам и передергиваниям Можешь сколь угодно придумывать синтетические специфические ситуации, когда ext3 выигрывает NTFS, но в практических юзкейсах, обсуждаемых тут, она конретно сливает

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

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

N>>>>>>Несерьёзно. Вынеси видеодрайвер (в версиях начиная с NT4) или драйвер сетевухи, вот тогда можно будет частично приблизиться к понятию микроядра.
_>>>>>Надо бы сперва gdi вынести из ring0 с его ограничением 16K дескрипторов.
eqw>>>>и получить такой же тормозящй гуй, как в линуксе? Спасибо, не надо.
N>>>Ты даже приблизительно не знаешь, где и почему у тебя тормозит гуй, раз пишешь такое. Hint: почитай про Wayland.
eqw>>У меня он не тормозит, он тормозит у линуксоидов.

N>Факты в студию. Где тормозит, на чём, какая разница в скорости, при каких условиях.

Google- [Linux gui is slower than windows]. Запрос весьма популярный, даже в садджеcте есть.

eqw>> И тормозит в том числе потому, что графическая подсистема там сделана «правильно» (овердмзайн иксов) и не засунута в ядро.

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

eqw>>Wayland является убогой попыткой сделать это более эффективно,

N>Уже сразу и "убогой".
Ну а как её ещё назвать? Костыль на костыле.

eqw>> но находится в зачаточном состоянии и неизвестно когда будет в состоянии заменить иксы

N>От вопроса, нужен ли собственно GDI (а не видеодрайвер) в ядре, ты благополучно ушёл.
Вы его мне не задавали.

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

T>Здравствуйте, netch80, Вы писали:
N>>У Вас есть опыт использования NTFS на MIPS машине средней производительности с файлами по 60GB?
T>причем тут твой MIPS, когда мы говорим про применение ФС на десктопах с IA32 и IA/AMD64?

Потому что Вы отвечали на реплику, в которой говорилось про скорость на машине с MIPS.

N>>Если да — поделитесь. Если нет — Вашим утверждениям и Вашему пафосу цена ноль целых хер десятых.
T>Цена ноль вашим неуместным выпадам и передергиваниям Можешь сколь угодно придумывать синтетические специфические ситуации, когда ext3 выигрывает NTFS, но в практических юзкейсах, обсуждаемых тут, она конретно сливает

Голые слова без единого факта.

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

_>>Надо бы сперва gdi вынести из ring0 с его ограничением 16K дескрипторов.

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

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

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

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

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

N>>>>Ты даже приблизительно не знаешь, где и почему у тебя тормозит гуй, раз пишешь такое. Hint: почитай про Wayland.
eqw>>>У меня он не тормозит, он тормозит у линуксоидов.

N>>Факты в студию. Где тормозит, на чём, какая разница в скорости, при каких условиях.

eqw>Google- [Linux gui is slower than windows]. Запрос весьма популярный, даже в садджеcте есть.

Читать выход гугла — как пить из включенного брандспойта — не напьёшься, но весь промокнешь. Ни по одной из ссылок из первых двух экранов я не увидел ни одного внятного объяснения явления, цифр сравнения и разбора причин. Несколько случаев типа "замени старый кривой драйвер на новый", после чего проблема исчезает.

eqw>>> И тормозит в том числе потому, что графическая подсистема там сделана «правильно» (овердмзайн иксов) и не засунута в ядро.
N>>Ага, отмазался — этим "в том числе". То есть причины якобы есть, но объяснить их ты не можешь.
eqw>Причин много и одна из них — кривой дизайн, по которому гуй лежит в юзерспейсе

Так мы дождёмся объяснения, что именно из гуя "лежит в юзерспейсе" и как это мешает?

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

Где именно костыли? Расшифруй.

eqw>>> но находится в зачаточном состоянии и неизвестно когда будет в состоянии заменить иксы
N>>От вопроса, нужен ли собственно GDI (а не видеодрайвер) в ядре, ты благополучно ушёл.
eqw>Вы его мне не задавали.

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

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

N>Потому что Вы отвечали на реплику, в которой говорилось про скорость на машине с MIPS.
я в плоском виде читаю форум, там не видно иерархии.

N>>>Если да — поделитесь. Если нет — Вашим утверждениям и Вашему пафосу цена ноль целых хер десятых.
T>>Цена ноль вашим неуместным выпадам и передергиваниям Можешь сколь угодно придумывать синтетические специфические ситуации, когда ext3 выигрывает NTFS, но в практических юзкейсах, обсуждаемых тут, она конретно сливает

N>Голые слова без единого факта.
читайте эту тему, тут приводили факты

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

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

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

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

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

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

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


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

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

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

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

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

N>Вы отвечали на реплику: "Надо бы сперва gdi вынести из ring0 с его ограничением 16K дескрипторов."
N>Так что жду ответа на вопрос.
Вы русский язык понимаете? В реплике не было вопроса.
Повторяю еще раз — если вынести GDI из ring0, упадет перформанс GDI и как следствие GUI будет тормозить. Прямо как в линуксе.

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

T>Здравствуйте, netch80, Вы писали:
N>>У Вас есть опыт использования NTFS на MIPS машине средней производительности с файлами по 60GB?
T>причем тут твой MIPS, когда мы говорим про применение ФС на десктопах с IA32 и IA/AMD64?

Это Windows привязана к x86 и amd64, а мы говорим о ФС в принципе.

T>Цена ноль вашим неуместным выпадам и передергиваниям Можешь сколь угодно придумывать синтетические специфические ситуации, когда ext3 выигрывает NTFS, но в практических юзкейсах, обсуждаемых тут, она конретно сливает

ext3 — это лишь один из возможных вариантов, тогда как кроме NTFS на win больше ничего и нет.
NTFS опережала многих на момент выхода, но она не была единственной. Почему ext2/ext3 получили такую массовость для меня до сих пор загадка. Возможно, для своих задач они были вполне хороши, а может из-за обратной совместимости, но более быстрые альтернативы были.

Здравствуйте, 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-софтом не пользуешься

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

n> Даже такое дорогое чтение это пара секунд. Запись свободных — ещё быстрее.

Я тут исключительно из любви к археологии (т.к. EXT3 давно не использую) решил проверить как оно на практике. Исходные данные:

Диски : 2 x GB0500C8046 (LVM over mdadm RAID-1), lifetime ~23200 часов
RAM   : 256MB
CPU   : 1 ядро Xeon X3220@2.40GHz
Ядро  : Debian Squeeze, 2.6.32-5-xen-amd64 (DOM-0, XEN Hypervisor)

Последовательность шагов:

# lvcreate -L 150GB -n test data
# mkfs -t ext3 /dev/data/test

Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
9830400 inodes, 39321600 blocks
1966080 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
1200 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group

# mount -o noatime,nodiratime /dev/data/test /mnt
# time dd if=/dev/zero of=/mnt/test.tmp bs=100M count=1000
1000+0 записей считано
1000+0 записей написано
 скопировано 104857600000 байт (105 GB), 6974.72 c, 15.0 MB/c

real    116m15.623s
user    0m0.012s
sys    5m44.322s

# time rm -f /mnt/test.tmp

real    5m11.263s
user    0m0.000s
sys    0m5.004s

Теперь то же самое с EXT4:

# time dd if=/dev/zero of=/mnt/test.tmp bs=100M count=1000
1000+0 записей считано
1000+0 записей написано
 скопировано 104857600000 байт (105 GB), 7260.36 c, 14.4 MB/c

real    121m1.076s
user    0m0.020s
sys    4m24.521s

# time rm -f /mnt/test.tmp

real    0m5.595s
user    0m0.000s
sys    0m2.248s

Т.е. таки да, для EXT3 в условиях ограниченных ресурсов счет идет на минуты и все это время система что-то делает с диском.

НС>>Обычно в этом виноваты драйвера.
D>Я хз что там виндовато, но эта дрянь и после загрузки винтами шуршать не перестаёт битых полчаса. Оно заявлено что якобы временно перестаёт, если какое-то приложение запускаешь, но во-первых, ни хрена, а во-вторых, что там можно столько времени делать?!
дык это явно superfetch

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

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

Видимо да.

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

Пример чего? Как настроить и использовать WinRM? Тебя в гугле забанили? http://ss64.com/nt/winrm.html

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

Про хабр ты сделал мне смешно.

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

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

ping. pong. ping...

НС>>>А как ты видишь такой пример? PS+WinRM реально используются реальными админами, а Windows Core сейчас является вариантом установки по умолчанию.
N>>Ну что, сложно написать пример?
НС>Пример чего? Как настроить и использовать WinRM? Тебя в гугле забанили? http://ss64.com/nt/winrm.html
N>> Лучше в стиле хабра (то есть сплошной конструктив, даже если без картинок).
НС>Про хабр ты сделал мне смешно.

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