Бывают ситуации, когда все нужные модули вкомпилируются в ядро и функция подгрузки модулей отключается. Это делают на тех системах, на которых не будут менять ни конфигурацию оборудования, ни файловые системы. Создается что-то типа бастиона, невозможно ничего не загрузить, ни выгрузить. Согласно этой политике повышается безопасность, т.к. невозможно загрузить какой либо вредоносный код в ядро. Но я с таким встречался только один раз, когда знакомый админ таким образом настроил внутренний шлюз. Он работал отлично, маршрутизировал довольно много трафика и держал аптаймы до нескольких лет. Но когда на маме сдохли конденсаторы и пришлось ее заменить — пришлось пересобирать ядро, т.к. таких матерей уже в продаже давно нет.
Смысл вкомпилировать только некоторые модули есть тогда, когда вы уверены, что это оборудование или файловая система будет у вас всегда, но опять же прироста в производительности это не даст. Я так поступаю чисто для удобства на домашней системе: вкомпилирую модули поддержки корневой файловой системы и контроллера жесткого диска в ядро, чтобы не использовать initrd. Других преимуществ я не вижу. Может быть кто нибудь еще просветит.
uname -r — это подстановка. Пишется в кавычках, которые находятся на русской букве «ё». А '*.ko' пишется в обычных одинарных кавычках. Подстановку можно, кстати, написать по другому:
find /lib/modules/$(uname -r) -name '*.ko'
А не одно и то же? Монолитное ядро по сути один большой процесс, выполняющийся в рамках одного адресного пространства. Все службы ядра существуют и выполняются в одном большом адресном пространстве ядра.
«Автоматически» — имелось ввиду, что не нужно все делать руками, есть специальные механизмы определения зависимостей и их разрешения.
О да! По Роберту Лаву я учился писать модули ядра. Автор не только рассказывает как писать модули, но и передает некую философию, руководствуясь которой можно избежать многих ошибок проектирования и правильно программировать в условиях пространства ядра.
В принципе согласен, но опять же, я пишу с разных компьютеров, форматирую в процессе написания, орфографию проверяет браузер. Просто мне так удобно, больше никаких побуждений нет. Но насчет гугл докс вы правы, наверное при отсутствии автосохранения здесь — это оптимальный для меня вариант, буду писать там, а потом переносить сюда, и форматировать уже здесь.
Я пишу статью по кусочкам, все таки работать нужно, отрывают часто и т.д. При чем я пишу не за одним компьютером, и не всегда за своим. Google docs, dropbox, конечно, варианты, но зачем извращаться, если это можно сделать здесь?
Согласен. Я слишком громко сказал «ничего нельзя было восстановить». В этом случае я имел ввиду спец. софт, которые народ качает с торрентов.
Если говорить более серьезно, то даже Б. Шнайер в своей книге упоминал об этом. Он говорил о том, что данные на диске нужно перезаписывать несколько раз: единицами, нулями, затем случайными данными, сгенерированные криптографически стойким алгоритмом. И то он там же пишет о том, что с использованием каких-то микроскопов даже этот метод окажется не эффективным. Книга за 1994 год, за 17 лет, уверен, многое изменилось.
Читал давно, написал по памяти, может где-то неточность допустил, но в книгу лезть уже нет сил…
Да, можно и так, не только сети будет легче, еще и процу, спасибо за комментарий. Просто ssh во первых обеспечит шифрование, во вторых — легче автоматизировать.
Да и безопасность ниже, если интерфейс не изолирован: какое нибудь чудо присосется к порту, на котором слушает nc, и тапки: может залить столько, сколько на винт вместится.
Да, я ведь об этом написал :) Реально видел статью, авторы которой на барахолке набрали винтов и восстановили данные. Писали даже, что нашли среди них винт со старого банкомата, в котором хранились номера кредитных карточек. Слабо верится, но если списывать на то, что это было давно — все возможно.
На сайте dreamspark сказано, что в Prometric нужно будет принести студенческий, для препода нужно удостоверение сотрудника ВУЗа? И вообще, в Украине это же тоже работает?
Спасибо, с моделью опечатался, и HACMP тоже заменил на PowerHA. Разбираться с ним времени не было, как прочитал в документации — так и написал, но, судя по всему, там была устаревшая информация.
Да, было бы интересно почитать о vSphere, никак руки не дойдут посмотреть.
А по поводу LVM — я даже не знаю кто кого куда портировал, кто придумал и где он впервые появился. Вот например названия команд управления LVM в Linux очень схожи на аналоги в HP-UX: там те же pvdisplay, pvcreate и т.д., что наталкивает на мысль о том, что он или портировался из linux в hp-ux, или из hp-ux в linux, а IBM, как всегда, выпендрились и обозвали команды в своем стиле.
Хотя, думаю, очень логично имя команды создания объекта начинать на «mk», как это делается в AIX: mkuser, mkvg, а команды получения списка начинать на «ls»: lspv, lsuser и т.д., просто для линуксоидов это непривычно. Но если непривычно и лень привыкать — в AIX всегда есть SMIT :-)
Смысл вкомпилировать только некоторые модули есть тогда, когда вы уверены, что это оборудование или файловая система будет у вас всегда, но опять же прироста в производительности это не даст. Я так поступаю чисто для удобства на домашней системе: вкомпилирую модули поддержки корневой файловой системы и контроллера жесткого диска в ядро, чтобы не использовать initrd. Других преимуществ я не вижу. Может быть кто нибудь еще просветит.
find /lib/modules/$(uname -r) -name '*.ko'
«Автоматически» — имелось ввиду, что не нужно все делать руками, есть специальные механизмы определения зависимостей и их разрешения.
Распаковать ISO-образ «image.iso» в папку «/home/root/exISO»:
dd if=image.iso of=/home/root/exISO/
Я чего-то не понимаю, или это ошибка?
Если говорить более серьезно, то даже Б. Шнайер в своей книге упоминал об этом. Он говорил о том, что данные на диске нужно перезаписывать несколько раз: единицами, нулями, затем случайными данными, сгенерированные криптографически стойким алгоритмом. И то он там же пишет о том, что с использованием каких-то микроскопов даже этот метод окажется не эффективным. Книга за 1994 год, за 17 лет, уверен, многое изменилось.
Читал давно, написал по памяти, может где-то неточность допустил, но в книгу лезть уже нет сил…
Да и безопасность ниже, если интерфейс не изолирован: какое нибудь чудо присосется к порту, на котором слушает nc, и тапки: может залить столько, сколько на винт вместится.
А по поводу LVM — я даже не знаю кто кого куда портировал, кто придумал и где он впервые появился. Вот например названия команд управления LVM в Linux очень схожи на аналоги в HP-UX: там те же pvdisplay, pvcreate и т.д., что наталкивает на мысль о том, что он или портировался из linux в hp-ux, или из hp-ux в linux, а IBM, как всегда, выпендрились и обозвали команды в своем стиле.
Хотя, думаю, очень логично имя команды создания объекта начинать на «mk», как это делается в AIX: mkuser, mkvg, а команды получения списка начинать на «ls»: lspv, lsuser и т.д., просто для линуксоидов это непривычно. Но если непривычно и лень привыкать — в AIX всегда есть SMIT :-)
— «Здравствуйте, я из Донецка!
— Ой, да что ж вы прямо так с порога то угрожаете??»
есть доля шутки, а все остальное правда =D