Linux и FreeBSD

кому что нравится - тот пусть то и использует
на десктопе, на серваках, на унитазе ;).

дело вкуса.

сам для десктопа выбрал линух.
хмм. только что задумался почему я выбрал линух...
и задумался на долго :)...
взвесил все за и против
вроде и в линухе и во фре есть все что мне нужно:
локаль
hardware opengl
sound
офис (openoffice)
inet (само собой разумеется)
quake3 :) (чтобы рзвлечься)
однако только недавно nVidia (это слово тебует уважения)
поправила ситуацию с hardware opengl во фре.
именно то, что когда я выбирал систему для десктопа
фришные дрова были 32.03 (самые первые) а возможности качнуть
новую фрю (когда вышли 43.65) не было к сожалению.
вот и начал качать LFS (110 метров против 650).

для серваков фря (порты и cvsup - удобно однака).
хотя теперь уже можно попробовать и фрю на десктопе.
хотя и линух меня устраивает (пока, надеюсь и будет).

если у кого наоборот
или что-то одно и на десктопе и серваках - хорошо.

захотелось Федорчуку погреться в лучах славы UNIX
(сам то он небось лицезреет Windows XP на своем десктопе)
пускай себе пишет статьи про UNIX-десктоп.

десктоп должен быть UNIX-based - а это Linux || *BSD || Solaris
(хотя solaris наверное редкий случай, сам я даже не видел не разу).

Даешь UNIX-based desktop!

еще про настройки VM

> И всё равно находятся тут люди, говорящие, "что за г-но - у меня фря (винда) в своп лезет".

Все-таки, умольчальные настройки VM в NT уж слишком дуракоустойчивы... (Да еще и не слишком хорошо задокументированы). Это крайность, но уже противоположная...

Умолчальная политика должна подходить большинству. И она подходит: в большей части случаев прибивать надо именно самого жадного. Для расчетных задач это разумеется не подходит, и было бы желательно иметь ручку для крутить. С .24 такая ручка есть...
Надеяться же, что программа получив отказ в mmap() что-то придумает сама и попросит меньше памяти -- наивно. Для 99,9{n}% задач это не так (естественно).

Удивительно видеть от Вас такой подход -- "не подходит мне значит плохо". Просто оно Вам не подходило. Сейчас -- будет подходить и Вам тоже.

2 миллиарда леммингов не могут ошибаться

> И она подходит: в большей части случаев прибивать надо именно самого жадного.

Ага, а на мнение юзверя(админа) по этому поводу можно спокойно забить.

> Для расчетных задач это разумеется не подходит

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

> Надеяться же, что программа получив отказ в mmap() что-то придумает сама и попросит меньше памяти -- наивно.

Я сам ее писал, потому не наивно. Под другими *NIX работает.

> Удивительно видеть от Вас такой подход -- "не подходит мне значит плохо"

1) Плохо в основном не то, что оно не подходит, а то, что нет (не было) возможности это настроить.

2) Может, кое-кому надо почитать man mmap для начала? (Не столько Вам, сколько г-ну Торвальдсу).

>Ага, а на мнение юзверя(админа) по этому поводу можно спокойно забить.

Ну, теперь можно выбирать. Что хорошо.

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

В моих условиях (веб, веб...) один процесс, сжирающий очень много памяти -- это сбой персонально его, этого процесса. Если один из чилдов httpd или MTA много ест -- с ним что-то не так. Разумеется, для части машин это неверно (а именно для тех, где крутятся базы под все вышеперечисленное)

>Я сам ее писал, потому не наивно. Под другими *NIX работает.

У меня например есть ощущение, что из того, что крутится на моих машинах, что-то придумать не сможет никто (хотя за sybase я не поручусь -- надо у DBA спрашивать)

>1) Плохо в основном не то, что оно не подходит, а то, что нет (не было) возможности это настроить.

ну это уже поправлено... *серьезный вопрос* а есть ли возможность подкрутить подобную ручку в solaris или win?

>2) Может, кое-кому надо почитать man mmap для начала? (Не столько Вам, сколько г-ну Торвальдсу).

Возможно. Согласно man mmap должен вернуть или ENOMEM, или EINVAL в случае если памяти не хватает. А что -- не возвращает?

>В те времена, когда по умолчанию был включен OOM-killer

Если я ничего не путаю, в rh ядрах он до сих пор включен.

>потому как ядро, зараза, убивало задачку (которая уже недели три считалась) -- просто потому, что она больше всего памяти занимала

У меня убивала малонеактивные. Что касается нехватки памяти - проверял последнее ядро от fc1 - просто не запускает новые задачи.

>Под нее был CacheMan. Он только кофе не умел варить...

Ааа. Такая прога у меня есть. Она вроде и под двухтонником работала.

Я думал, ты ссылку на параметры реестра дашь. ;)

>1. ФБСД легче настраивается и логичнее устроено...

Дык наврал - они обе логичные, ибо линукс unix-подобная, frebsd - unix.

Что значит "более логичная" - или логичная или нет.

>Автор имеет право на "ИМХО"

В конце, отдельной строкой. Потому что статья претендует на звание "объективной", а на деле получается одно "ИМХО автора".

> Возможно. Согласно man mmap должен вернуть или ENOMEM, или EINVAL в случае если памяти не хватает. А что -- не возвращает?

Нет. Радостно (оптимистично) говорит, что память есть, но при попытка ее использовать, задача прибивается. Т.е. именно прибивается, без шансов что-то узнать и подчистить. А все потому, что для "ускорения" память физически выделяется только при использовании, а не в момент, когда попросили.

> А все потому, что для "ускорения" память физически выделяется только при использовании, а не в момент, когда попросили.

Не важно, когда она выделяется. Важно, что не делается проверка, а можно ли столько выделить.

> Если я ничего не путаю, в rh ядрах он до сих пор включен.

Если я ничего не путаю, я не пользую RH :)

> Не важно, когда она выделяется.

Важно. Если сразу не зарезервировать, потом ничто не спасет.

> Важно, что не делается проверка, а можно ли столько выделить.

Проверить-то хорошо, но на момент использования памяти может уже и не быть. Кстати, именно поэтому на голом mmap Linux так сильно опережает FreeBSD, а вот если после mmap хотя бы по одному байтику туда писать, все не так уж радужно.

> *серьезный вопрос* а есть ли возможность подкрутить подобную ручку в solaris или win?

1) OOM вообще не может быть -- если mmap успешно завершился, значит памяти хватит, так что такие "ручки" (костыли, я бы сказал) не нужны.

2) Рулить ресурсами можно с помощью plimit, ulimit

Это для справки.

таки не важно

> Важно. Если сразу не зарезервировать, потом ничто не спасет.

Важно именно _зарезервировать_ (может, Вы именно это и называете "выделить"?).

> Проверить-то хорошо, но на момент использования памяти может уже и не быть.

Не может не быть. При каждом mmap'-е проверяем, хватит ли на всех памяти. (т.е., кому-то отказываем, даже если в данный момент есть ничем не занятая память, которую уже зарезервировали).

> Кстати, именно поэтому на голом mmap Linux так сильно опережает FreeBSD, а вот если после mmap хотя бы по одному байтику туда писать, все не так уж радужно.

Понимаете ли, хорошее ядро -- необходимое условие хорошей ОС, но отнюдь не достаточное. См. Windows.

>Дык наврал - они обе логичные, ибо линукс unix-подобная, frebsd - unix. >Что значит "более логичная" - или логичная или нет.

Хорошо. Скажем более стройная... Это я не автора выгораживаю. Если считаешь что все едино считай :) Но мне показалось что в Гентуу многое сделано более понятно чем в РХ. я имею ввиду всякие конфиги

> Важно именно _зарезервировать_ (может, Вы именно это и называете "выделить"?).

"выделить программе Х мегабайт" и "зарезервировать за программой Х мегабайт" для меня в данном случае синонимы.

> При каждом mmap'-е проверяем, хватит ли на всех памяти. (т.е., кому-то отказываем, даже если в данный момент есть ничем не занятая память, которую уже зарезервировали).

Именно так.

> Понимаете ли, хорошее ядро -- необходимое условие хорошей ОС, но отнюдь не достаточное. См. Windows.

Я с Вами абсолютно согласен. Хороший юзерленд -- необходимое условие хорошей ОС, но отнюдь не достаточное. См. [подставить по вкусу].

>4) готовые пакеты собираются весьма нерегулярно.

А именно с выпуском новой версии GRP (Gentoo Reference Platform), что обычно совпадает с выпуском нового релиза дистра.

> Когда-то, я помню, он обильно писал наивные обзоры про Linux и печатал их в журнале Byte RE..

Ага, у меня как раз пара таких журналов в столе лежит :)

Где-то за 2000/2001 год

>Вывод Федорчук и Дж.Буш БРАТЬЯ НА ВЕК!
Сильно :-) Дж.Буш наверное пока не в курсе :-)

Я, помнится, тоже увлекался установкой то Линукса, то БСД. Конечно, составил определённое мнение о работе той или иной системы. В обоих ОСах есть свои фишки и заморочки. В целом я считаю, что пользы от подобного рода статей немного, больше вреда. Авторы желая того или нет, вносят диссонанс. Ребята! Окститесь! Обе системы - это его величество UNIX. И этим всё сказано. И как можно сравнивать, предположим, Жигули 10-ой и 13-ой моделей?

Гонит чувак... Сам говорит про использование чисто настольное, а сравнивает в основном работу в консоли... А по сути надо глядеть именно sysinstall vs инсталляторы юзер-ориентированных дистров типа Мандрака ведь когда дело дойдет до нормальной, спокойной работы в том же КДЕ, то действительно, совершенно все равно, какая система...

>совершенно все равно, какая система...
Gonich, chuvak.
Ty na komercheskix UNIX porabotai. Togda tebe ne vse ravno stanet. Poimeesh gemoroi tot echo.

>Но мне показалось

Я и говорю - "кажется". Субъективное впечатление. У редхат есть система по которой укладываются глобальные конфиги. У gentoo она другая. Когда что-то кажется, это означает, что ты не полностью понимаешь систему. Только и всего.

А Федорчук уже и до коммерческих систем добрался?

>Ty na komercheskix UNIX porabotai

Ну-ну...это мы коммерческий Юникс на десетоп ставить собираемся?

Ага, "солярка" или QNX на десктопе - это полный руль для маньяков-извращенцев...

>Фишка в том, что если процессу было бы отказано в выделении памяти, программа это отлавливала и просила меньше памяти (и занималась сбрасывала на диск некий кусок промежуточного выражения, изврат, но по-другому никак -- не держать же swap partition ~ 10Gb). Linux же _всегда_ радостно говорит, что память есть, а потом убивает... Когда до победного конца осталось совсем немного... :(

>В те времена, когда по умолчанию был включен OOM-killer и выдрать его было тяжко(до 2.4.23), вообще все было печально. Стремно было лишний xterm пустить, потому как ядро, зараза, убивало задачку (которая уже недели три считалась) -- просто потому, что она больше всего памяти занимала -- вместо того, чтоб прибить xterm, или там демона какого...

Помнится кто-то лет несколько назад писал патч к ядру FreeBSD на эту тему. Там при нехватке памяти процессу посылался соотв. сигнал.

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

Как я понял, идея развития не получила.