Если файл доступен в /tmp или где-то в другом месте, это не значит что он уже на диске, иначе представьте как пришлось бы каждый раз ждать пока файл запишется на диск.

Зачем? Это все легко настраивается в любом дистре.

не очень важно, сколько именно вмещает байт атомарная операция свопинга. страницу, или слово. Или там линейку кеша. Не важно. Важно то, что это очень маленький кусочек, маленький по сравнению с памятью в 2011ом году.

И очевидно, что при полном заполнении памяти, мы сможем обменивать её лишь атомарными кусочками. Вот если у нас есть свободной скажем 100метров, то можно дать команду DMA-контроллеру, и он сам скинет на диск ненужные 100 мегабайт, и скачает оттуда нужные 100 мб. Почти всегда в памяти есть ненужный кеш, но вот в свопе кеша не бывает (ваш К.О.), вся память в свопе нужная. И там всегда должно быть свободное место. Причём не 4К, а МНОГО. Выделяя своп в 2 размера ОЗУ мы гарантированно выделяем там свободные куски, и ядро туда может ВСЕГДА скинуть сотни и тысячи мегабайт чего-нибудь, что сейчас не нужно, ну например упомянутую фотку в гимпе, которую юзверь вчера открыл. И забыл про неё сегодня. Удалять её нельзя, но и в памяти её держать тоже ненужно.

Да, если у вас всего одна задача, причём ей нужно 1025Мб, причём у вас всего 1024мб (как в описываемом вами случае), то эта задача будет жрать 1024Мб памяти, +1Мб кеша, и соответственно, работать со скорость HDD, т.е. в 100..1000 раз медленнее. Я знаю. У меня тоже часто такое. Однако, на десктопе решаются несколько другие задачи, во первых их много, во вторых, 90% из них можно легко положить в своп, ибо юзер их не видит, а ежели он их захочет увидеть, то задержку в 50мс он нам простит. Подождёт, пока его рюшечка скачается из свопа. Однако, что-бы рюшечка скачалась за 50мс, а не за 5000, необходимо, что-бы
1) было свободное место в памяти для рюшечки.
2) если п1 не выполнен, то место надо освободить, скинув в своп что-то ненужное (другую, невидимую рюшечку)
3) для выполнения п2 необходимо, что-бы в свопе была непрерывная и большая дыра

Ещё в середине прошлого века, Дональд Кнут доказал, что ЛЮБАЯ система распределения памяти будет тупить, если она заполнена почти целиком. Тогда дыры в ней будут меленькими, и новая информация станет сильно фрагментированной. Потому доступ к ней будет долгим. Тот-же Кнут рекомендует, для хранения N байт использовать 2*N байтовое устройство.

Особенно важно наличие свободного места и отсутствие фрагментации в том случае, если объём информации большой, "большой" по сравнению с атомом диска и памяти (4К), и по сравнению с одним цилиндром диска, и по сравнению с кешем диска. Если памяти больше 256М, то её МНОГО, она не влезет ни в какой кеш, и её придётся собирать по поверхности диска. Это ОЧЕНЬ ДОЛГО, если у вас не SSD. Потому важно, что-бы данные в свопе лежали едиными кусками, тогда задержки на свопирование станут незаметными для пользователя. Обычно, для достижения этого достаточно выделить двойной объём RAM.

НЕ БУДЕТ
ну кто вам такую глупость-то сказал?! даже если вы смонтируете tmp на флешке, то файл туда не попадёт, а потеряется, если вы эту влешку выдернете. Попробуйте сами. Только загрузите флешку работой, а то ядру будет нечего делать, и оно запишет туда временный файл. Файлы записываются на диск лишь при размонтировании ("безопасное извлечение" в венде). А вот если вы не размонтировали носитель, то данные туда НЕ ОБЯЗАНЫ записываться.

и кто мешает их использовать из дискового кеша? Вы лично?

подождите. сначала померьте скорость создания временного файла "на диске", а потом проверьте, сколько это займёт "в памяти". Я проверил - одинаково.

Я сначала отредактировал большой файл командой sed, а потом отредактировал его повторно. Второй раз редактирование происходило намного быстрее, ибо файл был в памяти(и результат тоже). При этом, красная лампочка HDD продолжала мигать ПОСЛЕ редактирования. Очевидно, ядро писало файл на диск, хотя для команды sed файл УЖЕ был записан.

угу. можно какой-то параметр сменить, что-бы так оно и было. sync-чё-то там. Не помню.

И тогда придётся каждый раз ждать, пока файл будет записан на диск. Операция сохранения ВНЕЗАПНО начнёт тормозить.

нет.
я вас как раз и предупреждаю об уголовной ответственности.

http://en.wikipedia.org/wiki/Comparison … w_managers

учтите, можно в любой Linux установить любой WM/DE.

(1) противоречит (2).

Я ставил Slackware 13 + IceWM - имхо лучше всего. Но таки настроить надо.

drBatty, ну вот Slitaz посмотри. По скриншотам вроде ничего так.

Судя по таблице KDE рулит.
drBatty спасибо. Вроде я определился - Ubuntu и КДЕ - осталось всё собрать с новым ядром (качнул с www.kernel.org - 2.6.38). И на четвертом пне все установить. Надеюсь не сильно будет тормозить.

в слаке не так. гном нормально работает. как и кеды

Wolfenberg, с кучей ОЗУ Вы загнули. Calculate 11.0, KDE 4.5.5 "искаропки", кушает около 700 Мб, половину из которых отжирает Опера с 30 вкладками (зачем так много - это уже другой вопрос) + открыты LibreOffice Writer и Kopete. ЧЯДНТ?

Ну Вы блин даёте. Возвращаясь к нашим баранам -так что же тогда ставить на P IV, 2,8ГГц и 1гиг памяти? Так ещё и видео - GF440MX (AGP).
P. S. Где то на просторах видел описание как записать новое ядро на CD, стартовать с него и поставить на машину. На сколько я понял у каждого ЛИНУХА своё ядро, тогда для кого ядра на официальном сайте www.kernel.org ? Или у меня каша в голове.
В борьбе за пользователя победит тот пакет который наиболее стабилен, а рюшечек и красатулечек в WIN7 полно. Так же в ОКОШкАХ - НЕСТАБИЛЬНОСТЬ, ЗАСИЛИЕ ВИРУСОВ, НЕОБХОДИМОСТЬ ПЕРЕСТАВЛЯТЬ ХОТЯ БЫ РАЗ В ГОД.
От Линукса требуется тоже самое, но с точностью на оборот...

угу. каша

Wolfenberg уже всё написал...

Итак:

* Линус написал ядро. Только ядро никому не нужно. К нему ещё кучу всего нужно. Начиная от простейших команд (coreutils, это в консоли, всякие cp, mv, ls, и т.д.), и заканчивая всякими графическими гуями.

* Летом 1993го года, почти одновременно, были созданы два дистрибутива с линукс ядром. Т.е. не только ядро, но и всё к нему, что-бы юзер мог это всё поставить на комп, без излишнего красноглазия. Называются эти дистрибутивы Slackware и Debian. Первую разрабатывает лично Патрег, второй дистр - целая команда т.н. маинтейнеров. Эти дистрибутивы развиваются до сих пор

* Многим не понравились слака и деб, точнее понравились, но не совсем. И народ решил их переделать под себя. Мало того-что переделал, так ещё и стал делится. Так появились Over9000 разных дистров. например в 2004ом слаку переделали на Руси и на Украине, и назвали её MOPS. В прошлом году проект закрыли, но он возродился, и теперь называется http://ru.wikipedia.org/wiki/AgiliaLinux

нет к сожалению. Ванильный (как у Линуса) ядра только в слаке. В других дистрах они обработаны напильником. А потому - НЕ совместимы. Впрочем, можно пересобрать, наложив кучу улучшальных патчей. Но это долго и муторно...

а это правильное впечатление. Просто программ, которые работают напрямую с ядром очень мало. Я вот на вскидку всего 3 вспомнил:
1) mkfs и прочее для ФС (mount, tune2fs...)
2) lsof (она правда только читает. Можно и так /proc почитать)
3) наша sysinfo (она просто заточена на любые ядра, ну в пределах разумного конечно).

А остальные работают не с ядром, а с какой-нить прокладкой. Консольные вроде stat & ls работают с glibc, в которой есть эта самая man 2 stat (стандартная функция C). Потому, можно взять бинарник ls, и он почти наверняка заработает с любой версией glibc (не младше. Если младше - то уверенности меньше).

Сама glibc работает прямо с ядром, и поменять её почти наверняка НЕ получится. А если получится - с кучей багов. Именно потому, glibc собирают специально для конкретного ядра (а не просто так).

Что касается гуёвых программ, то они тоже НЕ работают с ядром, а работают через прокладку, которая называется HAL. Естественно, это HAL нужно собирать тоже для данного конкретного ядра, иначе ничего не выйдет. За то, сама программа будет работать с любым HAL'ом, если конечно этот HAL опознает. Например XFCE до сих пор не научилась работать с новым HAL'ом, и потому ей требуется во первых старый HAL, а во вторых, она монтирует ФАТ с кракозябрами, ибо не понимает iocharset. Причём и не будет понимать, потому как старый HAL устарел и не поддерживается (правда арчевцы сами патч написали).

не так. Вы запустите программу, а она напишет: "не могу найти libastral.so версии >=6.66".

Это если вы плюнете на все предупреждения, и просто скопируете бинарник из одного дистра, в другой. Ядро тут как-бы и не причём, дело в библиотеках. Но библиотека прибита гвоздями к ядру. Как и в венде. Разница в том, что мы можем
1) поменять что-то в ядре
2) пересобрать нужные библиотеки под новое ядро
3) ?????
4) PROFIT.
Но просто так вытащить "хорошее" ядро, и сменить им "плохое" - НЕ получится. ОНО даже не загрузится.

На самом деле, юзера не должно это всё заботить - ему достаточно просто ставить ПО из дистра. Заботить это начинает юзера лишь при установке ПО с закрытыми исходниками. В этом случае создатель дистра не может запилить программу, и нам остаётся ждать, когда-же допилит сам автор. Что мы и наблюдаем и с sysinfo, и со всякими хромами.

картинка по запросу - "садись, пять!"
тут была не очень хорошая картинка (elve)

просто праздник. А что?