Почему Linux тормозит

потому, что линупс собран не компилером visual studio.

Именно так. Ведь там ядро BSD.

да это мегабакс был, и иже с ним. В споре о том, что «зачем ВСЁ то компилять?»

А ну все понятно

в венде компилять не получается — сырцов нет.

исходники на то и исхорники, что не зависят от системы и архитектуры .Другое дело, что более менее преемлемое ПО использует часто некроссплатформенные либы, и если это какой нибудь winapi то проще скомпилять по x86 x86_64 и кормить пользователя exeшками. Но то что так проще, не значит что по другому нельзя

Что там кроме emule можно скомпилять?

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

Так ты же говорил «простаивает». А сейчас говоришь, что работает.

к словам не надоело цепляться?

Чем упоролся? Ман у xz давно читал?

глазки подыми: я его даже процитировал.

У меня в роутере с 32 метрами ОЗУ rootfs запакована xz. Какие гигабайты?

и сколько там в твоей rootfs? Ясное дело, что контекстов не может быть намного больше, чем байтов в файле. Ибо это и есть байты в файле. И если байтов немного, то и контекстов тоже не много.

нет. Это действительно так.

нет, не так.

а Windows7 тормозит?

А что это такое?

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

Chromium, GIMP и многое другое.

интересно зачем, если в Win™ есть фотошоп, готовый гимп, и ещё Over9000 других редакторов? С хромиумом та же самая история.

исходники на то и исхорники, что не зависят от системы и архитектуры .

ты заблуждаешься, исходники очень сильно зависят от OS. Вот посмотри на код например какой-нить gnu sed - он весь утыкан #ifdef'ами, которые и определяют, в GNU мы сейчас, или в какой-нить венде, и нужно на каждый чих строить свой велосипед. И потому, кстати, вендовая sed втрое больше гнутой. И это простой текстовый фильтр, с нормальными программами всё намного плачевнее.

Другое дело, что более менее преемлемое ПО использует часто некроссплатформенные либы, и если это какой нибудь winapi то проще скомпилять по x86 x86_64 и кормить пользователя exeшками. Но то что так проще, не значит что по другому нельзя

дело не столько в некросплатформенных либах. В венде вообще никаких либ почти нет, только свои NIH, которые хоть и NIH, но ни с чем, кроме венды не совместимы. И надо тащить гнутые/свои, ибо это проще, чем юзать вендовые велосипеды.

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

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

Так ты же говорил «простаивает». А сейчас говоришь, что работает.

к словам не надоело цепляться?

Это диаметрально противоположные понятия. И это ты называешь цепляться к словам? Ты действительно не видишь разницы между «работает» и «простаивает»?

Чем упоролся? Ман у xz давно читал?

глазки подыми: я его даже процитировал.

Ну процитируй мне место про гигабайты при упаковке и сотни метров при распаковке. Может, пока ищешь, таки прочитаешь.

Это диаметрально противоположные понятия. И это ты называешь цепляться к словам? Ты действительно не видишь разницы между «работает» и «простаивает»?

всё относительно. И эти понятия — тоже относительны. С т.з. планировщика ядра, процесс работает, и имеет статус R. С т.з. выполненной работы - процесс НЕ работает. В точности так же, как грузчик, который нихрена не делает, и за это зарплату получает. Причём, этого грузчика нельзя отправить на другой склад, выполнять другую работу, ибо переброска работников тоже денег/времени стоит. Особенно это важно в нашем случае, когда другой работы просто нет, и надо выполнять эту. А эту выполнять не получается так быстро, как может(и даже хочет) наш грузчик.

Ну процитируй мне место про гигабайты при упаковке и сотни метров при распаковке.

Still, it is possible to have .xz files that require several gigabytes of memory to decompress.

Читать что-ли разучился? Тут написано про гигабайты на распаковке. И IRL оно действительно иногда так бывает - мне лично не хватало 512Mb RAM, и оно лезло в своп. Причём даже без всяких иксов и WM (т.е. там свободно было ~480Mb). И работало оно в свопе ОЧЕНЬ медленно, ибо доступ действительно рандомный(т.е. если в свопе половина нужной xz памяти, то половина доступов будет в своп).

всё относительно. И эти понятия — тоже относительны. С т.з. планировщика ядра, процесс работает, и имеет статус R. С т.з. выполненной работы - процесс НЕ работает.

Выкрутиться пытаешься, демагог?

Ну процитируй мне место про гигабайты при упаковке и сотни метров при распаковке.

Still, it is possible to have .xz files that require several gigabytes of memory to decompress.

Читать что-ли разучился? Тут написано про гигабайты на распаковке.

You can't into english, do you? Или у тебя проблемы с чтением вообще? Да, возможно создать .xz файл, который потребует нескольких гигов для распаковки, спецификация позволяет. Но максимальное, что сейчас требуется: 65 MiB. Точно так же можно создать реализацию deflate с окном в пять гигов, и оно будет требовать при распаковке пять гигов. По умолчанию xz вообще создаёт файлы, которые «decompressible even on systems with only 16 MiB RAM».

И IRL оно действительно иногда так бывает - мне лично не хватало 512Mb RAM, и оно лезло в своп.

У тебя всё перемешалось в голове. Ни один созданный обычным xz архив не требует столько памяти для распаковки.

всё относительно. И эти понятия — тоже относительны. С т.з. планировщика ядра, процесс работает, и имеет статус R. С т.з. выполненной работы - процесс НЕ работает.

Выкрутиться пытаешься, демагог?

я с самого начала это говорил. Иди, перечитай.

You can't into english, do you? Или у тебя проблемы с чтением вообще? Да, возможно создать .xz файл, который потребует нескольких гигов для распаковки, спецификация позволяет.

тут не написано «возможно создать», тут написано «возможно будет такой файл». При желании можно хоть на 100500 гигов сделать, это не слишком и сложно.

Но максимальное, что сейчас требуется: 65 MiB.

я вчера сырцы ядра распаковывал, 74Мб надо было. Т.ч. ты врёшь.

По умолчанию xz вообще создаёт файлы, которые «decompressible even on systems with only 16 MiB RAM».

ага, щаз! По умолчанию там --best compression стоит, какие 16Мб?

У тебя всё перемешалось в голове. Ни один созданный обычным xz архив не требует столько памяти для распаковки.

у меня ничего не перемешивалось. Учи матчасть. Я для кого ман цитирую-то?

Да и даже если ты прав, то и 65Мб ни в какой кеш не влезет. У меня например всего 3Мб кеша. Очевидно, что и с 65, и даже с 16ю мб тебе придётся ждать десятки и сотни тактов, пока оно получит доступ к нужным контекстам. Что и происходит IRL.

Так изначальная фраза как раз и была в стиле «Можно, но зачем?».

я с самого начала это говорил. Иди, перечитай.

Да, с самого начала ты бросаешься из крайности в крайность: то он у тебя «работает», то «простаивает».

я вчера сырцы ядра распаковывал, 74Мб надо было. Т.ч. ты врёшь.

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

При желании можно хоть на 100500 гигов сделать, это не слишком и сложно.

Ты не сможешь :) Это ведь не языком трепаться, это код писать надо. Ах, да, там же есть «при желании», которого у тебя естественно нет.

ага, щаз! По умолчанию там --best compression стоит, какие 16Мб?

Если ты поставил себе --best по умолчанию, это не означает, что так стоит у всех. Я ничего не менял и у меня без параметров сжимает с 6.

У тебя всё перемешалось в голове. Ни один созданный обычным xz архив не требует столько памяти для распаковки.

у меня ничего не перемешивалось. Учи матчасть. Я для кого ман цитирую-то?

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

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

Да и даже если ты прав

А я прав :)

то и 65Мб ни в какой кеш не влезет

Ну ты явно ман-то не читал, только grep'ал.

согласен.

Да, с самого начала ты бросаешься из крайности в крайность: то он у тебя «работает», то «простаивает».

ну правильно - смотря как посмотреть. Тебя что волнует, шашечки или ехать?

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

74 virt из них 66500K RES, если ты так настаиваешь в точности, хотя самому проверить не судьба. Файл называется linux-3.8.4.tar.xz. Это по твоему какой-то особый случай?

Ты не сможешь

я уже делал. Потому-то так уверен.

Если ты поставил себе --best по умолчанию, это не означает, что так стоит у всех. Я ничего не менял и у меня без параметров сжимает с 6.

Ну ладно, сделали у xz сейчас -6 по дефолту, раньше было -9 ЕМНИП. Что совсем не отменяет во первых требования 9Мб памяти, которая всё равно в кеш не лезет, и во вторых, те же сырцы ядра пакуют с -9, а вовсе не -6 как у тебя. Иди к Линусу, попроси его сменить ключ на -1, дабы память влезла-бы в кеш, и я оказался-бы не прав.

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

очевидно, надо использовать много больших контекстов, вынуждая xz их сохранять в своём словаре. Но дело-то не в этом, а втом, что там всё равно куча промахов кеша, даже если у тебя -6 степень сжатия. Очевидно, что 9Мб физически невозможно всунуть в L3, и даже если можно, то и L3 - не самая быстрая штука. Всё равно CPU будет ждать множество тактов, и делать вид, что «работает». Но ты и в L3 не воткнёшь. Даже в мой. Даже со средним сжатием.

Ну ты явно ман-то не читал, только grep'ал.

и что я там не заметил?

ну правильно - смотря как посмотреть. Тебя что волнует, шашечки или ехать?

Жжёшь. Я вижу, что ты так в лёгкую сможешь доказать, что чёрное — это белое, на примере зебры. Мастер демагогии.

74 virt из них 66500K RES, если ты так настаиваешь в точности, хотя самому проверить не судьба. Файл называется linux-3.8.4.tar.xz. Это по твоему какой-то особый случай?

66500 KiB это меньше 65 MiB. И уж значительно меньше обещанных тобой гигабайт.

я уже делал. Потому-то так уверен.

Ну так повтори, раз делал. Повторить же ещё проще?

Что совсем не отменяет во первых требования 9Мб памяти, которая всё равно в кеш не лезет

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

и что я там не заметил?

Содержимое.

Жжёшь. Я вижу, что ты так в лёгкую сможешь доказать, что чёрное — это белое, на примере зебры. Мастер демагогии.

При чём тут зебра? Я с самого начала говорил о том, что процессор ничего не делает, и это считается как 100% загрузки. И объяснял почему так: ибо ждёт память, которая снаружи, и работает на частотах в разы ниже, чем внутри CPU. Такая ерунда началась ещё в ZX Spectrum, там тоже были штрафные такты, сейчас их просто стало на порядок больше. К счастью не всегда, а только в некоторых задачах, например xz(ибо в большинстве случаев либо память не является бутылочным горлом, либо доступ последовательный, и можно заниматься предвыборкой, либо памяти нужно немного, и хватает кешей).

66500 KiB это меньше 65 MiB. И уж значительно меньше обещанных тобой гигабайт.

во первых я говорил о сотнях М, а не о гигабайтах. О ггигабайтах написано в мане. Не передёргивай. Во вторых я говорил о _возможности_ существования таких файлов. Но даже если файл вполне обычный, чуть-ли не первый попавшийся, то как видишь, он всё равно не лезет в кеши. А стало быть всё сказанное мною — правда.

Ну так повтори, раз делал. Повторить же ещё проще?

нет. Повторить сложнее, ибо в первый раз у меня так произошло случайно, и это был баг, а не фича. Повторять такое я не желаю. К тому же я не понимаю, зачем это надо. Ни твой, ни мой CPU не закешируют вполне реальные 64Мб, и даже обещанные тобой виртуальные 9Мб.

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

я ИЗНАЧАЛЬНО говорил о кеше. «Много» в моём контексте - по сравнению с кешем. Я его не приплетал. Кеш у меня сейчас 3Мб. Туда не влезает. Много. Что непонятного-то?

Заметил, что со временем Linux начинает тормозить все больше и мне интересно почему.

Как ты это измерил?

На Windows тормоза понятны - загаживание и фрагментация реестра.

Это не влияет на скорость в Windows.

Так с чем связано замедление системы?

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

Также хотел спросить советов по оптимизации - как ускорить систему?

Купи процессор и память.

Я читал, что даже в той же Ubuntu можно пересобрать ядро.

Можно.

ускорение получится незначительным?

Да.

И еще вопрос: если в дистрах типа Ubuntu, Fedora можно пересобирать ядро и ставить программы из исходников, то в чем преимущество Gentoo, если там ты тоже пересобираешь ядро и ставишь программы из исходников.

Разные подходы.

Я читал, что Gentoo быстрее, но за счет чего?

За счёт оптимизации ПО под конкретный процессор, за счёт исключения ненужных зависимостей и сокращения размеров бинарников.

Каждый раз, читая такие статьи, ловлю себя на мысли - а не запустить ли msconfig?

Я с самого начала говорил о том, что процессор ничего не делает, и это считается как 100% загрузки.

Ты сказал: «CPU при этом действительно простаивает». Может ты там что-то другое имел в виду, но большинство людей, с которыми я общался, под простоем понимают нулевую загрузку.

во первых я говорил о сотнях М, а не о гигабайтах. О ггигабайтах написано в мане. Не передёргивай.

Ну да, а сотни мегабайт — это меньше 65 MiB, ага.

А стало быть всё сказанное мною — правда.

Нет. Ты, кстати, говорил, что

При желании можно хоть на 100500 гигов сделать, это не слишком и сложно.

но так и не сделал. Только сплошные домыслы.

я ИЗНАЧАЛЬНО говорил о кеше. «Много» в моём контексте - по сравнению с кешем. Я его не приплетал. Кеш у меня сейчас 3Мб. Туда не влезает. Много. Что непонятного-то?

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

Я прошу тебя привести конкретный пример, в котором файл, созданный штатным xz, при распаковке требует сотни мегабайт. Что получаю в ответ? Пустую болтовню.

Ни твой, ни мой CPU не закешируют вполне реальные 64Мб, и даже обещанные тобой виртуальные 9Мб.

Вместо спекуляций, измерил бы промахи.

Юзал xfwm4 на нвидии блобе и нуво, а также на интеле - никакого тиринга. Как его добиться?

На первом месте выбор прог, начиная с wm. Все остальное паллиативы, дающие 1-5% выигрыша, который заметить чаще всего просто невозможно.

Ты сказал: «CPU при этом действительно простаивает». Может ты там что-то другое имел в виду, но большинство людей, с которыми я общался, под простоем понимают нулевую загрузку.

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

но так и не сделал. Только сплошные домыслы.

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

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

в мане написано про несколько гигабайт, которые _могут_ потребоваться. Все вопросы к tukaani. Я лишь говорил о сотнях мегабайт, которые лично сам наблюдал. Посему tukaani не врёт.

Вместо спекуляций, измерил бы промахи.

иди и мерь. Не вижу в этом никакого смысла. И вообще - я устал доказывать очевидное.

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

занят. Если он не может ничего другого делать, значит занят.

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

Ты же сказал, это легко, а сейчас — голову в песок.

в мане написано про несколько гигабайт, которые _могут_ потребоваться. Все вопросы к tukaani.

а ты абзац полностью прочитай, там написано: текущие версии делают архивы, требующие максимум 65 MiB.

иди и мерь. Не вижу в этом никакого смысла.

ты и это не можешь? Есть хоть что-то, в чём ты разбираешься? :)

И вообще - я устал доказывать очевидное.

Все твои доказательства сводятся к жонглированию словами. И так все замеры делаю я.

занят. Если он не может ничего другого делать, значит занят.

пусть будет «занят».

Ты же сказал, это легко, а сейчас — голову в песок.

легко. Я рассказал как. Мне вез день с этим трахаться предлагаешь?

а ты абзац полностью прочитай, там написано: текущие версии делают архивы, требующие максимум 65 MiB.

это если с ключом -9. Там куча других ключей, дабы сделать словарь побольше, глубину контекстов и много чего ещё. Поиграйся с ними, если тебе это интересно. Даже LZ77/78 можно по разному настраивать, не только 123456789, эти цифры - всего-лишь пресеты, а не настройки.

ты и это не можешь? Есть хоть что-то, в чём ты разбираешься? :)

может тебе ещё и пруфвидео выслать, что я в потолок плеваться умею? ☺

Все твои доказательства сводятся к жонглированию словами. И так все замеры делаю я.

ага. Например здесь: Почему Linux тормозит (комментарий)

и маны тоже ты цитируешь, как например здесь: Почему Linux тормозит (комментарий)

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

Как его добиться?

Включить просмотр видео или запустить opengl приложение.

легко. Я рассказал как. Мне вез день с этим трахаться предлагаешь?

Назвался груздем, полезай в кузов.

это если с ключом -9. Там куча других ключей, дабы сделать словарь побольше, глубину контекстов и много чего ещё

Хорошо, лично ты можешь выстрелить себе в ногу. Но я не зря упомянул слово «обычный». А обычное использование — цифровые профили.

может тебе ещё и пруфвидео выслать, что я в потолок плеваться умею?

Почему бы и нет, вдруг это предмет гордости. Может ты там фигуры вырисовываешь — это было бы круто.

ага. Например здесь: Почему Linux тормозит (комментарий)

Нет, здесь: Почему Linux тормозит (комментарий)

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

и маны тоже ты цитируешь, как например здесь

Ты гордишься цитированием манов?!

ты - балоболка,

Прямое оскорбление. Пытаешься брызгами из лужи меня достать?

ибо никаких замеров, пруфов, и ссылок от тебя нет и не было.

Было, смотри выше, я привёл ссылку. (Даже учёт погрешностей :)

Только от меня.

Измерил virt и res у процесса. И то, только после того как я ткнул тебя в разницу между virt и res. Постыдился бы.

Но я не зря упомянул слово «обычный». А обычное использование — цифровые профили.

а я сказал «много, иногда может и сотни метров». Так оно и есть IRL, а обычно - десятки. Это тоже *много*.

Нет, здесь: Почему Linux тормозит (комментарий)

ок. 13 и 14 секунд - это для тебя две большие разницы. Для меня - это ДОЛГО. Причём одинаково ДОЛГО для запуска. Неприемлемо долго. Эти твои результаты мне не интересны.

В данном случае вопрос в другом, в потреблении памяти. И в промахах кеша. Промахи кеша будут при рандомном использовании БОЛЬШОГО количества памяти. 64М - это много. Ибо кеш у меня на много меньше(3М). С чем ты споришь? Что будет не сотни метров, а десятки? Какая разница? Всё равно процессор будет простаивать (прости, «ждать», а не простаивать).

Ты гордишься цитированием манов?!

нет. Меня расстраивает, что ты их не читаешь.

Было, смотри выше, я привёл ссылку. (Даже учёт погрешностей :)

во первых результат не по теме.

во вторых - такую разницу я не замечу. Для меня её нет. О чём я и писал. А вот запускать какой-то дефрагментатор - лишнее движение. И негодно для экономии жалкой четырнадцатой секунды.

Измерил virt и res у процесса. И то, только после того как я ткнул тебя в разницу между virt и res. Постыдился бы.

так там и нет особой разницы между virt и res, как и должно быть при рандомном использовании всего словаря. Тыкай/не тыкай - результат один и тот же. Мелкая разница ни на что качественно не влияет. Ещё одна четырнадцатая никому ненужная секунда тормозов.

ок. 13 и 14 секунд - это для тебя две большие разницы

Если разница больше погрешности, значит она есть. Всё решает погрешность измерений. Не забыл ещё первый курс?

В данном случае вопрос в другом, в потреблении памяти.

Ты меня спутал с другим собеседником.

С чем ты споришь? Что будет не сотни метров, а десятки?

О, наконец-то ты понял. Именно этот факт я и оспаривал. И только его.

во первых результат не по теме.

Результат именно по теме, я проверял твоё утверждение. И опроверг его.

во вторых - такую разницу я не замечу. Для меня её нет.

Ты много чего не замечаешь, ты просто ешь еду, пьёшь воду. Ты не заметишь, чистая вода, или в ней есть примеси; можно её пить, или не стоит. Но существуют методики экспериментального определения состава. И там рулят погрешности.

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

Ты просто завидуешь :)

так там и нет особой разницы между virt и res

Это не помешало тебе придраться к утверждению «меньше 65 MiB». Привёл значение в 74 virt и радовался, пока я не спросил про res. А теперь, оказывается разницы нет. Чего ж ты тогда возражал?

Мелкая разница ни на что качественно не влияет. Ещё одна четырнадцатая никому ненужная секунда тормозов.

мелкая она, потому что я довольно часто дефрагментацию запускаю. А так она может стать значительной. Просто я не могу ждать полгода-год.

ок. 13 и 14 секунд - это для тебя две большие разницы. Для меня - это ДОЛГО.

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

Если разница больше погрешности, значит она есть. Всё решает погрешность измерений. Не забыл ещё первый курс?

мы тут не танчики клеим. Разницы между 13ю и 14ю секундами для пользователя нет. Разницу для сервера ты не обосновал (с учётом простоя сервера на время дефрагментации).

О, наконец-то ты понял. Именно этот факт я и оспаривал. И только его.

а! ну тогда ты победил. В данном контексте для меня (и для xz) нет никакой разницы.

Результат именно по теме, я проверял твоё утверждение. И опроверг его.

молодец. Можно запустить дефрагментатор, и умеьшить время запуска с 14и до 13и секунд. А я говорил: хрен редьки не слаще. Проблема не в этом, и это не поможет. Если ты знаешь юзеров, для которых 13 сек приемлемо, а 14 уже нет - ты им поможешь. Но я таких не встречал.

Ты просто завидуешь

чему тут завидовать? Запускай. Можешь и антивирус ещё поставить.

Это не помешало тебе придраться к утверждению «меньше 65 MiB». Привёл значение в 74 virt и радовался, пока я не спросил про res. А теперь, оказывается разницы нет. Чего ж ты тогда возражал?

Ещё раз повторяю: время простоя CPU не сильно зависит от того, 65 или там 50Мб памяти используется. Это в данном случае принципиально только для демагогов.

мелкая она, потому что я довольно часто дефрагментацию запускаю. А так она может стать значительной. Просто я не могу ждать полгода-год.

ну а я вот её не запускаю полгода-год. А потом, иной раз, всё накатываю по новой. И не замечаю никакого существенного ускорения. Да, может не 14 сек, а 13. Может даже 12. Мне это не заметно. Это в любом случае — тормоза, и проблема не в фрагментации. Её по другому решать нужно.

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

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

ну покажи мне пользователя, для которого твой результат имеет значение. Я не думал, что ты вспомнишь о своём же результате, который доказывает, что ты не прав.

ну покажи мне пользователя, для которого твой результат имеет значение. Я не думал, что ты вспомнишь о своём же результате, который доказывает, что ты не прав.

Похоже, ты просто не способен понимать объективную реальность. Спорить с результатом эксперимента, намеренно приплетая субъективную оценку... Мне тебя жаль.

Похоже, ты просто не способен понимать объективную реальность. Спорить с результатом эксперимента, намеренно приплетая субъективную оценку...

давай-ка ты перестанешь балоболить, и посмотришь, как эта тема называется. О какой «объективности» ты говоришь? Думаешь, кроме тебя, кто-то замеряет время запуска чего-то с секундомером в руках?

Давай в рамках темы держаться. Если я сказал «тормозит одинаково», то это действительно так, и твой опыт это только подтверждает. Вот если-бы после дефрагментации было-бы 1 сек, против 14 - то да, годно. А так - никакой разницы.

Повторяю: мы не танчики клеим, это там, если ты отрежешь 14см вместо 13см, то получится кривой танчик. Объективно. Здесь иная ситуация.

Ну грубо говоря, никто не будет заморачиваться с дефрагментацией, если она снижает тормоза с 14 до 13и секунд. Не в коня корм.

Мне тебя жаль.

а мне тебя. Ты в плену своих придуманных рамок, цифирек, и объективных оценок. Реального мира ты похоже не видишь.

Реален только мир, который видишь ты? «Циферки» — единственный способ конструктивного общения, придуманный человечеством.

Предпочитаешь быть одним из семи слепых мудрецов? :)

«Циферки» — единственный способ конструктивного общения, придуманный человечеством.

объективная оценка ничего не стоит, без аналогичного субъективного понимания.

Вот просто пример «у меня на 100руб больше, чем у тебя». О чём это говорит? Да ни о чём, если для нас 100руб - просто 100руб. Пара пачек сигарет или несколько буханок хлеба. Но вот если мы - два алкоголика с похмелья, и у тебя 100руб, а у меня 200руб — это ДРАМА. Ибо с 1го января у тебя на бутылку не хватит, а у меня — хватит. А значит, ты будешь страдать, а я - радоваться ☺

Возвращаясь к нашему примеру, могу объективно сказать, что для подавляющего большинства пользователей, разницы между 13ю и 14ю секундами просто НЕТ. Как для нас(я надеюсь) нет разницы в 100р. Это для меня вполне очевидно, и не требует никаких доказательств.

Для тебя не очевидно? Ну либо ты демагог, который цепляется к незначительным деталям, либо у тебя какой-то особый юзкейс(как у алкоголиков). Вот про свой особый юзкейс ты ничего не сказал. А стало быть - ты демагог.

btrfs как раз тормозит хуже некуда, плохой совет.

Лучше сделать дефрагментацию с помощью e4defrag, если ТС так ее боится.

Нет.

Подобное есть только в оболочке MacOS X, но ставить ее не советую )

Что-то не заметил.

Видимо имел в виду видеокарты AMD.

2ГБ ОЗУ

Вот и ответ.

Там Intel и nvidia (блоб и нуво. Последний в 2D таки лучше)

На линуксе? Никогда этого не делал!