Comments 71
sic!
класс. обожаю читать тонны исходников. это вы типа топик написали?
Угу. Это я типа и скрипты написал, и топик, и подход альтернативный к процессу продемонстрировал. А насчёт тонн исходников - понимаю Ваше возмущение, и даже разделяю, но... весь смысл этого топика как раз в том, чтобы предоставить новичкам довольно простой способ разобраться в процессе загрузки - а для этого нужно вычитать эти исходники, благо их объём и стиль написания делает это не сложным. Так что в данном случае исходники в топике полностью оправданы - они и есть основной контент и основная ценность в данном случае.
=\ мдя, тру линуксойд больше даже сказать нечего ... остается только завидовать и ковырять собственную генту.
Тяжелая статья. Понимаю что материал не самый простой, но ведь статья видимо для тех, кто еще не разбирался в процессе загрузки? Я прочитал, и так ни черта и не понял
Вы меня, конечно, простите, но может быть, просто статья не для вас? Мне лично очень понравилось, с некоторыми добавками и изменениями я применил у себя. Плюс у автора в первых абзацах чёткая мотивация что и для чего он делает.
UFO just landed and posted this here
любой материал нужно подавать постепенно. в школе же не начинают в первом классе мат.анализ преподавать (хотят разобраться - разберутся :) ) Вот и здесь также
Скорее всего меня ввело в заблуждение название статьи, подумалось что это для новичков. Хотя и автор в одном из комментов говорит что для новичков статья. Странно вобщем. Видимо я еще меньший новичок, чем те, для которых статья написана )
Скорее всего меня ввело в заблуждение название статьи, подумалось что это для новичков. Хотя и автор в одном из комментов говорит что для новичков статья. Странно вобщем. Видимо я еще меньший новичок, чем те, для которых статья написана )
UFO just landed and posted this here
"весь смысл этого топика как раз в том, чтобы предоставить новичкам довольно простой способ разобраться в процессе загрузки"
Я - новичок. Статья - для новичков. Связь чувствуете?
В моем посте не написано что матанализ не надо преподавать вобще. Надо. Но не в первом классе.
Я - новичок. Статья - для новичков. Связь чувствуете?
В моем посте не написано что матанализ не надо преподавать вобще. Надо. Но не в первом классе.
UFO just landed and posted this here
Ребята, давайте жить дружно. Для вас, не для вас - глупости это всё. Я тоже новичок, есть немало гораздо более продвинутых товарисчей. И вообще, чем больше знаешь, тем лучше понимаешь как много ты ещё не знаешь.
Статья расчитана на "новичков", которые хотят разобраться в процессе загрузки Linux, но либо ниасилили чтение загрузочных скриптов своего дистрибутива, либо осилили но им этот процесс очень не понравился и цельной картины у них в голове не сложилось.
Статья расчитана на "новичков", которые хотят разобраться в процессе загрузки Linux, но либо ниасилили чтение загрузочных скриптов своего дистрибутива, либо осилили но им этот процесс очень не понравился и цельной картины у них в голове не сложилось.
скилл линукса у меня ещё не настолько прокачан чтобы осилить статью ) Зато оформилось желание изучить загрузочные скрипты своего дебиана, а потом заново прочесть это, чтоб почерпнуть идеи об оптимизации процесса. Только тогда у меня появится чёткое представление о процессе загрузки. Т.е. будет с чем сравнивать
свасибо за проделаную работу. Обязательно ознакомлюсь на досуге.
Спасибо большое за труд.
Возможно сам дорасту до подобных вещей, но пока это сильно круто для меня. :(
Возможно сам дорасту до подобных вещей, но пока это сильно круто для меня. :(
классно )))
спасибо )))
/etc/iptables
лежит там где надо)
будемс пробовать)
спасибо )))
/etc/iptables
лежит там где надо)
будемс пробовать)
Исходники хороши и понятны. Хотя заголовок, наверное, должен был быть "Как загружается мой Linux".
Нет. Фокус в том, что загрузочные скрипты того же Gentoo выполняют абсолютно те же самые операции при загрузке, плюс кучу лишних действий. Я когда-то специально разработал жуткую штуку, которая встроилась в Gentoo-шные загрузочные скрипты, и вывела лог всего, что они реально делали при загрузке. Так вот, они делали на 95% то же самое. Только объём их не 316 строк, как у меня, а порядка 5000-8000 строк (всего там кода на 23500 строк, но он не весь используется при загрузке).
Не соглашусь. Чтобы знать "как загружается Linux", нужно, во-первых, иметь представление об организации железа и операционной системы, и, во-вторых, понимать процесс на уровне абстрактции boot loader -> linux -> init.
А насчет инитскриптов - по-моему, имеет смысл разве что рассказать, что от них вообще нужно, и дать книжку про sh. И перед тем, как кому-то пригодится написание своих инитскриптов, ему пригодится знакомство с rc.d или sysvinit.
Ввиду вышеизложенного считаю более правильным заголовок "как работает runit при загрузке моего Линукса" ;)
А насчет инитскриптов - по-моему, имеет смысл разве что рассказать, что от них вообще нужно, и дать книжку про sh. И перед тем, как кому-то пригодится написание своих инитскриптов, ему пригодится знакомство с rc.d или sysvinit.
Ввиду вышеизложенного считаю более правильным заголовок "как работает runit при загрузке моего Линукса" ;)
Вы привели неплохой пример разницы между поверхностным и фундаментальным образованием и пониманием.
Да, совершенно не обязательно знать как именно устроены инитскрипты в конкретном дистрибутиве, но хороший админ обязан понимать что именно они делают (и ещё желательно понимать почему и зачем)! И приведённые мной в топике скрипты - это квинтэссенция именно того, что они делают, без лишнего мусора, значительно упрощающая изучение этого вопроса.
Не буду спорить относительно правильности заголовка, но с Вашим подходом к познанию системы я категорически не согласен — так только админов-эникейщиков воспитать можно.
Да, совершенно не обязательно знать как именно устроены инитскрипты в конкретном дистрибутиве, но хороший админ обязан понимать что именно они делают (и ещё желательно понимать почему и зачем)! И приведённые мной в топике скрипты - это квинтэссенция именно того, что они делают, без лишнего мусора, значительно упрощающая изучение этого вопроса.
Не буду спорить относительно правильности заголовка, но с Вашим подходом к познанию системы я категорически не согласен — так только админов-эникейщиков воспитать можно.
Думаю, вы меня не так поняли.
Речь не о том, что должен знать или уметь хороший админ - об админах и речи нигде не было.
Я просто хотел сказать, что знание `subj` не исчерпывается тем, что описано в статье (с точки зрения админа - почти; разработчик ядра же, к примеру, ожидает совсем другой ответ), и нигде не указывал, чем оно исчерпывается.
Моя критика относится не к статье, а к заголовку. Я также выразил свои соображения насчет подачи материала новичкам. Им не следует рассказывать, что загрузка linux - это инитскрипт. Может быть, кому-то будет легче понять, как они работают, исходя из предложенного кода, но и в таком случае поймут они это не здесь. И значительного упрощения процесса я здесь не вижу.
Новичкам я бы все-таки рекомендовал вникнуть в rc.d тех же slackware (лучше документированных скриптов пока не видел) или arch.
А подход runit интересный, спасибо за статью :)
Речь не о том, что должен знать или уметь хороший админ - об админах и речи нигде не было.
Я просто хотел сказать, что знание `subj` не исчерпывается тем, что описано в статье (с точки зрения админа - почти; разработчик ядра же, к примеру, ожидает совсем другой ответ), и нигде не указывал, чем оно исчерпывается.
Моя критика относится не к статье, а к заголовку. Я также выразил свои соображения насчет подачи материала новичкам. Им не следует рассказывать, что загрузка linux - это инитскрипт. Может быть, кому-то будет легче понять, как они работают, исходя из предложенного кода, но и в таком случае поймут они это не здесь. И значительного упрощения процесса я здесь не вижу.
Новичкам я бы все-таки рекомендовал вникнуть в rc.d тех же slackware (лучше документированных скриптов пока не видел) или arch.
А подход runit интересный, спасибо за статью :)
> Например, я не использую RAID и LVM
Странно, что такие вещи не используются на серверах.
Странно, что такие вещи не используются на серверах.
Вы знаете, бывают разные случаи. Совать RAID и LVM везде по умолчанию - не самая классная идея. На моих проектах винт не является узким местом - всё сильно заоптимизированно и 98% инфы существует только в памяти.
Хм. Под RAID здесь, нутром чую, имеется в виду Software RAID - который даже на сервере (а скорее, именно на сервере) не особо нужен. Да и LVM имеет смысл только тогда, когда нужно динамически менять таблицу разделов и производить тому подобные извращения. Что на сервере (да и на обычной машине) должно производиться максимально редко. Так что отсутствие RAID и LVM лично я считаю оправданным.
А вообще, ставить такое для сервера.. С одной стороны, меньше кода - меньше места для ошибки. С другой стороны - код init-скриптов выверяли сотни человек - а этот код прочитают единицы. Но - интересно.
А вообще, ставить такое для сервера.. С одной стороны, меньше кода - меньше места для ошибки. С другой стороны - код init-скриптов выверяли сотни человек - а этот код прочитают единицы. Но - интересно.
А что плохого в software raid для небрендовых сервером, скажем? Очень даже адекватное решение, на мой взгляд.
Другое дело, какой-нибудь HP Management Server, который заранее предупредит, что винт скоро умрет, меняйте.
Но в бюджетных случаях Software RAID себя очень даже оправдывает.
Другое дело, какой-нибудь HP Management Server, который заранее предупредит, что винт скоро умрет, меняйте.
Но в бюджетных случаях Software RAID себя очень даже оправдывает.
Я обычно предпочитаю sw raid железным решениям. Так что - кому очень, кому нет.
инфра-красноглазие...
Хоть бы мне не пришлось в этом всем копаться. Смотрю и страшно становится.
А как будет выглядеть аналог, скажем,
/etc/init.d/squid reload?
# sv t squidНо это не относится к загрузочным скриптам, это сервисы. Почитайте документацию на daemontools и runit, там много любопытного. Если коротко о главном — для каждого сервиса запущен отдельный процесс-супервизор, который при умирании сервиса гарантированно и моментально получает SIGCHLD и перезапускает сервис. Это избавляет от принципиально ненадёжной возьни с
/var/run/*.pid-файликами.Если у Вас возник напрашивающийся вопрос, отвечаю: за супервизорами следит супервизор супервизоров. :) А за ним следит процесс N1. По сути этот супервизор супервизоров запускается через exec в файле
/etc/runit/2, и его выход для процесса N1 означает что пора вызывать /etc/runit/3 и перегружаться. Так что за каждым распоследним сервисом бдит цепочка процессов вплоть до процесса N1! Ничего надёжнее сделать нельзя в принципе.
Статья полезная, интересно. Для облегченных заточенных систем подходит отлично. А у себя на десктопе я вижу 30с загрузку раз в несколько дней, поэтому лень даже шевелиться, единственное скоро перейду на baselayout2.
Да, ускорять загрузку смысла нет. Эти скрипты хороши для обучения, и для тех, кто старается избегать избыточно сложных систем — простые вещи работают надёжнее, и даже если unthinkable happens их намного проще понять и пофиксить. Лично для меня большим плюсом является то, что не надо разыскивать в странных местах какую переменную в какое значение выставить чтобы настроить нужную функциональность — можно пойти в один конкретный файл и подстучать обычные параметры стандартной утилиты.
Если мне изредка приходится что-то править в стандартных дистрибутивах — это просто мука! Наворочено столько, что понять где что нужно прописать для, например, поднятия алиаса на интерфейс или хитрой настройки роутинга — приходится сначала grep-ом находить скрипты вызывающие ifconfig/route, смотреть какие переменные они им передают параметрами, потом искать в каких конфигах эти переменные объявляются, потом разбираться с форматом значений этих переменных (который далеко не всегда тривиален, т.к. они иногда пытаются с помощью одной переменной управлять разными вещами). К простоте очень быстро привыкаешь, и теряешь навык (и желание) работать спереусложнёнными обычными системами. :(
Если мне изредка приходится что-то править в стандартных дистрибутивах — это просто мука! Наворочено столько, что понять где что нужно прописать для, например, поднятия алиаса на интерфейс или хитрой настройки роутинга — приходится сначала grep-ом находить скрипты вызывающие ifconfig/route, смотреть какие переменные они им передают параметрами, потом искать в каких конфигах эти переменные объявляются, потом разбираться с форматом значений этих переменных (который далеко не всегда тривиален, т.к. они иногда пытаются с помощью одной переменной управлять разными вещами). К простоте очень быстро привыкаешь, и теряешь навык (и желание) работать с
Очень, очень жаль, что Вы забросили поддержку своего дистрибутива. Вам бы, с такими идеями, наоборот, собрать команду и заняться его разработкой. ;-) Или написанием скрипта, который пересаживал бы пользователей на вашу схему загрузки =)
Вообщем, решение очень на самом деле интересное, спасибо за статью.
Вообщем, решение очень на самом деле интересное, спасибо за статью.
Лучше бы автор описал все процессы во время загрузки, все равно его скрипты никто использовать не будет.
ну, не обобщайте :)
Использую, и весьма активно.
Использую, и весьма активно.
Ладно, погорячился... Скажем так - мало кто ;) Просто хотелось об основах прочитать, матчасть вобщем.
Ммм. Основы :
- на большинстве систем стартует бутлодер, который позволяет выбрать, с какого раздела и какое ядро грузить дальше. А также передать какие-нить параметры для ядра. Этого шага может не быть и ядро может быть прописано намертво.
Читать например howto по Grub.
- Начинает выполняться ядро. Инициализируется, инициализирует девайсы и тд.
Хардкорный уровень. Читать например в Linux kernel Hacking или в исходниках ядра :)
- после того, как ядро закончит инициализироваться (в процессе загрузки после фразы "Freeing kernel memory") грузится первый userspace процесс (процесс с pid 1) - по умолчанию /sbin/init. Все остальные процессы порождены (отфоркнуты) первым.
- init запускает на выполнение инициализационные скрипты.
- и вот начиная с этой точки у Алекса и расписано.
Соответственно, у powerman и у меня bootloader - Grub. Ядро - linux. Как инит процесс используется runit.
А дальше собсно скрипты :)
- на большинстве систем стартует бутлодер, который позволяет выбрать, с какого раздела и какое ядро грузить дальше. А также передать какие-нить параметры для ядра. Этого шага может не быть и ядро может быть прописано намертво.
Читать например howto по Grub.
- Начинает выполняться ядро. Инициализируется, инициализирует девайсы и тд.
Хардкорный уровень. Читать например в Linux kernel Hacking или в исходниках ядра :)
- после того, как ядро закончит инициализироваться (в процессе загрузки после фразы "Freeing kernel memory") грузится первый userspace процесс (процесс с pid 1) - по умолчанию /sbin/init. Все остальные процессы порождены (отфоркнуты) первым.
- init запускает на выполнение инициализационные скрипты.
- и вот начиная с этой точки у Алекса и расписано.
Соответственно, у powerman и у меня bootloader - Grub. Ядро - linux. Как инит процесс используется runit.
А дальше собсно скрипты :)
что автор хотел, то и написал; "процессы" пускай другие описывают, вот вы например .. заместо комментария :)
Хорошее чтиво!
Народ, если для вас эти скрипты кажуться сложными, попробуйте попрограммировать в баше, хотя-б с недельку. Написать несколько оберток для массовой конвертации музыки и фоток ну и прочую нужную дребедень. Займитесь автоматизацией своей рутины =)
Когда начнет получаться с башем, эти скрипты покажуться простыми, как газетная статейка =), а уж когда консоль станет удобным и частым инструментом, то... =)
Ничего страшного в скриптах и консоли нет.
Народ, если для вас эти скрипты кажуться сложными, попробуйте попрограммировать в баше, хотя-б с недельку. Написать несколько оберток для массовой конвертации музыки и фоток ну и прочую нужную дребедень. Займитесь автоматизацией своей рутины =)
Когда начнет получаться с башем, эти скрипты покажуться простыми, как газетная статейка =), а уж когда консоль станет удобным и частым инструментом, то... =)
Ничего страшного в скриптах и консоли нет.
статья весьма познавательна для многих, но всё же попахивает некоторым хардкором. Я на своих пяти линуксовых инсталляциях (2 деба, арч, рхел и генту) не стал бы такого делать. Нет, я, в своё время, как и автор, заинтересовался процессом загрузки, разобрался, что и как, но писать свои сукрипты не стал, хотя бы потому, что если мои сервера придётся поддерживать кому-то другому, как он будет разбираться в нестандартном стартапе системы?
Есть такой момент. Но эти скрипты — лишь небольшая часть отличий моих систем от типовых дистрибутивов. У меня:
- все сервисы работают под супервизорами (runsv из runit, аналог supervise из daemontools);
- практически все логи (включая apache и mysql, которые для этого изначально вообще не приспособлены) ведутся через svlogd из runit (аналог multilog из daemontools);
- в качестве syslog и klog используется socklog;
- на каждом сервере поднят djbdns;
- etc...
Если учесть тот факт, что далеко не все знают про существование этих утилит, а работать с ними нормально умеет только часть тех, кто о них слышал...
Получается, что умея неплохо админить какую-нить традиционный rpm-based дистрибутив, средний админ на моём сервере вообще ничего с ходу не поймёт: асболютно всё, к чему он привык делается совершенно иначе. Другие приложения-сервера, другой механизм работы с сервисами, другой принцип работы с логами... ну и старторые скрипты тоже другие. :) И самое главное - все эти утилиты принципиально отличаются от всего к чему он привык не только названием и параметрами, а идеологией, философией и подходом к решению проблем. Поэтому маны ему придётся курить достаточно долго, пока он в это въедет.
Плохо ли это? Я так не думаю. На то есть целый ряд причин:- Все эти отличия вызваны не скукой или желанием сделать никому не понятную систему. Такая система получается значительно более надёжной, безопасной, эффективной, лёгкой и простой. Стоит ли отказываться от этих преимуществ?
- Замена админа на NIX-сервере который настраивали после инсталляции — это всегда сложная операция. Новый админ будет ещё много месяцев наступать на разные грабли из-за неожиданных для него настроек сделанных предыдущим админом. (Бывают, конечно, исключения, когда все настройки либо хорошо задокументированны, либо все сервера типовые и настроены идентично.) Поэтому чаще всего на практике новый админ либо этот сервер старается не трогать, и в его настройки особо не вникать; либо переустанавливает систему с нуля.
- Разобраться с описанными мной утилитами и их философией очень полезно и способствует профессиональному росту админа. :)
Основная причина, безусловно, первая. IMHO лучше новому админу научиться работать с такими, более совершенными системами, чем соглашаться на использование типовых систем с кучей недостатков исключительно ради того, чтобы всё было привычно и не нужно было ничего учить.
- Все эти отличия вызваны не скукой или желанием сделать никому не понятную систему. Такая система получается значительно более надёжной, безопасной, эффективной, лёгкой и простой. Стоит ли отказываться от этих преимуществ?
Лучшее — враг хорошего.
Да, RHEL на мой взгляд (да и не только на мой) — не самая удачная система, но она стандарт, как это ни печально. И oracle тот же поддерживает только её в качестве варианта линуксовой системы. Да и хозяева серверов, как правило, с большим подозрением относятся к новым системам, потому что как бы хороша и идеологически верна новая система ни была - её надо поддерживать, а такую инсталляцию поддержать (т.е. разобраться с ней) сможет далеко не каждый, и не потому что система запредельно сложна или нестандартна, а потому что просто людей с головой мало в отрасли.
Поэтому же, кстати, и пишется софт не пойми на чём, точнее, понятно на чём — пхп, цпп, ява. Потому что чем писать всё впятеро меньшей командой за вдесятеро меньшие сроки на коммон лисп скажем, люди предпочитают использовать те технологии, которые доступны широкой массе, чтобы случае чего было возможно найти человека который хоть что-то понимает в написаном.
Заказчики, кстати, придерживаются примерно такой же идеологии, им не нужны более совершенные в технологическом плане, но отходящие от industry standards решения.
А система ваша да, интересная. Вы её куда-нибудь выкладывали? Я бы покрутил, посмотрел, что и как.
Да, RHEL на мой взгляд (да и не только на мой) — не самая удачная система, но она стандарт, как это ни печально. И oracle тот же поддерживает только её в качестве варианта линуксовой системы. Да и хозяева серверов, как правило, с большим подозрением относятся к новым системам, потому что как бы хороша и идеологически верна новая система ни была - её надо поддерживать, а такую инсталляцию поддержать (т.е. разобраться с ней) сможет далеко не каждый, и не потому что система запредельно сложна или нестандартна, а потому что просто людей с головой мало в отрасли.
Поэтому же, кстати, и пишется софт не пойми на чём, точнее, понятно на чём — пхп, цпп, ява. Потому что чем писать всё впятеро меньшей командой за вдесятеро меньшие сроки на коммон лисп скажем, люди предпочитают использовать те технологии, которые доступны широкой массе, чтобы случае чего было возможно найти человека который хоть что-то понимает в написаном.
Заказчики, кстати, придерживаются примерно такой же идеологии, им не нужны более совершенные в технологическом плане, но отходящие от industry standards решения.
А система ваша да, интересная. Вы её куда-нибудь выкладывали? Я бы покрутил, посмотрел, что и как.
Статью целиком разобрать не смог, но по случаю вспоминается шутка (мой вольный перевод):
Когда я был новичком, то я брал ядро из коробки, потому что оно стабильно и работает. Когда я стал опытным, то я стал собирать свои ядра, потому что хотел заставить их работать так, как нужно было мне. Когда я стал гуру, то я брал ядро из коробки, потому что оно стабильно и работает.
Ничего личного ;)
Когда я был новичком, то я брал ядро из коробки, потому что оно стабильно и работает. Когда я стал опытным, то я стал собирать свои ядра, потому что хотел заставить их работать так, как нужно было мне. Когда я стал гуру, то я брал ядро из коробки, потому что оно стабильно и работает.
Ничего личного ;)
Wow! Вы действительно powerman. :-)
Спасибо. Все собираюсь собрать дома медиацентр под Linux. Как раз по теме, т.к. сильно волнует быстрая загрузка.
Не понимаю, чем вам не понравились скрипты Gentoo и идея разработчиков с rc-update. У меня например Gentoo бутится до X'ов примерно за минуту. Какой смысл в выйгрыше в 10 секунд?
Какие 10 секунд? Даже выпонение всех 5000 строк скриптов займёт меньше секунды. Время загрузки определяется не навёрнутостью скриптов, а тем, что они загружают.
Не совсем понятен смысл всей этой мегамонстряческой работы, проделанной автором. Выйгрыш в скорости загрузки не заметен невооружённым взглядом. Кто хочет понять механизм загрузки системы - читает доки по дистрибутиву. В результате данной работы автор получил кучу хардкода безо всех удобных фич, предоставляемых скриптами дистров.
Не совсем понятен смысл всей этой мегамонстряческой работы, проделанной автором. Выйгрыш в скорости загрузки не заметен невооружённым взглядом. Кто хочет понять механизм загрузки системы - читает доки по дистрибутиву. В результате данной работы автор получил кучу хардкода безо всех удобных фич, предоставляемых скриптами дистров.
Как раз изучая Linux, перешёл от Ubuntu к ArchLinux (там минималистические сценарии загрузки, в них новичку гораздо легче разобраться). Но эти ещё круче! Очевидно, это будет следующая ступень.
Cool! Спасибо за статью! Побольше бы таких. Именно вглубь, а не бла-бла-бла в стиле "как тыкать в gimp и wine". :)
Радует что на хабре затрагивают такие темы. Только инит у тебя не идеальный, покрайней мере скорость непорадовала ;)
У меня дома сервер с приличным количеством демонов быстрее загружается, а лаптоп так вобще ;)
У меня дома сервер с приличным количеством демонов быстрее загружается, а лаптоп так вобще ;)
насколько быстрее получается по сравнению с генту?
(хотя вас это кажется ообо и не интересует)
мои линуксы секунд по 30-то всяко грузятся..
(хотя вас это кажется ообо и не интересует)
мои линуксы секунд по 30-то всяко грузятся..
Чего то вот читаю, читаю...что-то знакомое...
Мне кажется, или runit пытается скопировать bsd-style систему инициализации?
А BSD-style это не быстрее и не легче, случаем?
Возвращаемся обратно (т.е. новое это хорошо забытое старое?:) )
Ни разу не пользовался runit, но последние 2 года пользуюсь ArchLinux'ом. Очень похоже...
Мне кажется, или runit пытается скопировать bsd-style систему инициализации?
А BSD-style это не быстрее и не легче, случаем?
Возвращаемся обратно (т.е. новое это хорошо забытое старое?:) )
Ни разу не пользовался runit, но последние 2 года пользуюсь ArchLinux'ом. Очень похоже...
UFO just landed and posted this here
Ужас просто.
По сравнению с Linux система FreeBSD похожа на DOS: после форматирования флэшки в UFS2 и внедрения загрузчика boot0 в "загрузочный сектор" систему можно просто скопировать с винчестера на эту флэшку, поправить /etc/fstab и дописать всего одну(!) строчку в /boot/loader.conf.
По сравнению с Linux система FreeBSD похожа на DOS: после форматирования флэшки в UFS2 и внедрения загрузчика boot0 в "загрузочный сектор" систему можно просто скопировать с винчестера на эту флэшку, поправить /etc/fstab и дописать всего одну(!) строчку в /boot/loader.conf.
Разобраться, как загружается система это и полезно и очень интересно. Но писать свои скрипты, как и использовать чужие я не стал бы, ибо их необходимо самому поддерживать. Пример с ALSA весьма показателен. Отказ от SysVInit мне не понятен. /etc/inittab весьма удобен.
В данном случае стандарт лучше, разработчики дистрибутива скорее лучше чем вы напишут надежную и более универсальную вещь, а если ошибка и обнаружится, то оперативно ее исправят.
В данном случае стандарт лучше, разработчики дистрибутива скорее лучше чем вы напишут надежную и более универсальную вещь, а если ошибка и обнаружится, то оперативно ее исправят.
Это всё происки консерватизма. Не обращайте внимания - пионерская дорога всегда была трудна. Побольше надо таких статей. Дело не в отказе от стандартов; товарисч проявил творческую инициативу, более того - поделился с массами в лучших традициях OS. А насчёт нестандартности и смены персонала серверов - 50% систем, которые я наблюдал, внушали мне трагический ужас множественными костылями и подпорками; причём всё внедряется на протяжении, как правило, нескольких лет, и уже сам автор не может понять, что происходит у него в системе. Это говорит о культуре и принципах администрирования. Никакой документации, никаких комментариев, не говоря уже о diff-файлах (или просто исходниках). И частенько всё заканчивается плавным выводом машины из калашного ряда на задворки истории...
Обязательно внедрю к себе запчасти от вашей схемы.
Обязательно внедрю к себе запчасти от вашей схемы.
Если будете внедрять - берите свежую полную версию у меня на сайте. В статье хоть и реальный код, но это всё-таки пример для обучения/демонстрации, и некоторых частей в статье нет (например, скрипта для shutdown, etc.).
Обновил статью/скрипты. Не уверен, нужно ли это кому-нибудь, но пусть лучше будет актуальная версия. В Gentoo эти скрипты можно поставить из оверлея «powerman» пакетом power-misc/runit-scripts.
Sign up to leave a comment.
Как загружается Linux