При проектирането на корпоративна ИТ система е необходимо да се определи кръгът от задачи за решаване и изискванията за сигурност, бързина и надеждност. Тези характеристики пряко зависят от избора на операционната система (ОС), инсталирана на сървъра. Свободно разпространените UNIX-подобни системи BSD и GNU / Linux постепенно заменят познатия Windows. Те са по-сигурни, тъй като достъпът се осъществява на принципа "всичко е забранено, каквото не е разрешено", така че те практически не са податливи на вирусни атаки, имат висока производителност и надеждност.
BSD операционни системи
Системата за разпространение на софтуер Berkeley Software Distribution (BSD) е създадена в началото на 90-те години от възпитаници на Университета в Бъркли (Калифорния). Разработчиците на UNIX-подобната операционна система 386BSD пуснаха изходния код за отворен достъп и основните операционни системи бяха написани на тяхна основа:
- BSD / OS, комерсиална версия.
- NetBSD, с отворен код.
- FreeBSD, с отворен код.
Комерсиалната версия вече не се поддържа, а други отворени проекти се развиват успешно. В момента има 4 BSD проекта с отворен код. Всеки проект се основава на собственото си ядро; те са създадени за различни цели, но практически не се различават много един от друг.
BSD семейство:
- FreeBSD – Проектът има за цел да създаде лесна за управление система с висока производителност.
- DragonFlyBSD – високопроизводителна мащабируема ОС, предназначена да поддържа многопроцесорна обработка (SMP), извлечена от проекта FreeBSD;
- NetBSD - поддържа максимална преносимост на кода за различни изчислителни ресурси; поддържа остарял хардуер; тази ОС е използвана в космически проекти на НАСА.
- OpenBSD - надеждна ОС с повишено ниво на сигурност, базирана на проекта NetBSD; той е инсталиран в банки и правителствени агенции в Съединените щати.
Отделно може да се отбележи TrueOS (по-рано PC-BSD), операционна система, базирана на FreeBSD и ориентирана за използване на работни станции.
Най-разпространеният е FreeBSD, като 80% от потребителите на BSD са го инсталирали.
В онлайн режим е налична подробна документация в различни формати за конфигуриране и управление на системата.
Във FreeBSD приложенията могат да се инсталират по два начина:
- използване на мениджър на пакети (започвайки от версия 9.1, по подразбиране се предлага нова, по-гъвкава реализация на пакета, практически в крак с версиите в портовете);
- използвайки колекцията от портове.
Ports Collection — автоматизирана система за изграждане на софтуер от източник — значително опростява процеса на инсталиране. В момента има над 33 000 заявления. Достатъчно е да зададете параметрите за изграждане, като изберете необходимите елементи от менюто и стартирате процеса за изпълнение.
Операционни системи Linux
Linux, за разлика от BSD, е само ядрото на операционната система. Чрез добавяне на GNU програми към ядрото, операционните системи GNU / Linux се формират със собствен набор от приложения и системни компоненти. Дистрибуциите на Linux се разпространяват под формата на инсталационни пакети безплатно или на разумна цена; можете да компилирате системата от източник.
Основни дистрибуции на Linux:
- Debian е една от първите дистрибуции.
- Ubuntu е най-популярният Linux, базиран на Debian.
- Fedora - Поддържа се от RedHat.
- RHEL е комерсиалната версия на Fedora Linux.
- Gentoo е изцяло изграден от изходни кодове, можете гъвкаво да персонализирате системата.
- Mint - Съвместим с Ubuntu, съдържа Java и Adobe Flash.
- Slackware е най-старият Linux.
- Arch е постоянно актуализирана дистрибуция, която поддържа двоичен формат и инсталиране от източник.
- CentOS - Базирана на комерсиалната дистрибуция на RedHat, стабилна сървърна ОС.
- PCLinuxOS е преносима дистрибуция на LiveCD.
Всеки Linux е създаден за конкретни задачи. Инсталирането на Gentoo и Arch изисква богат опит в разрешаването на проблеми със зависимостта и драйверите. Дистрибуциите на Ubuntu и Debian са сравнително лесни за инсталиране.
Съветите на опитни специалисти от неформалната Linux общност помагат да се разберат тънкостите на работата със системата. Повечето приложения, написани за Linux, могат да бъдат изтеглени безплатно от хранилища в Интернет.
Сравняване на FreeBSD и Linux
Както семейството BSD, така и Linux най-често се разработват на некомерсиална основа и са достъпни за безплатно използване. Потребителите могат да вземат изходни кодове и да променят, както намерят за добре.
И двете дистрибуции на FreeBSD и Linux са UNIX-подобни операционни системи. Linux първоначално е създаден от Линус Торвалдс като безплатна алтернатива на UNIX-подобната система MINIX, докато FreeBSD е по-близо до оригиналната версия на UNIX: първата BSD OS дори се наричаше Berkeley Unix.
Общото наследство на UNIX и на двете семейства се проявява в използването на сходни модели. И в двата случая взаимодействието на потребителя със системата се осъществява главно с помощта на командния интерпретатор (обвивка), интерфейсът за програмиране на приложения (API) има подобна функционалност, има сходство в йерархията на файловата система. Това прави много по-лесно пренасянето на приложения от FreeBSD към Linux и обратно, отколкото от други не-UNIX-подобни системи.
Една от основните разлики между семейството на BSD и дистрибуциите, базирани на ядрото на Linux, е видът на лицензиране.
Повечето дистрибуции на Linux и техните приложения са лицензирани под GNU GPL, известен също като copyleft, който ви позволява да използвате оригинален код за създаване на нови продукти, без да искате разрешение от собственика на източника, но запазвайки условията за разпространение. Този лиценз насърчава идеята за безплатно разпространение и откритост преди всичко. Ето защо, когато разработвате собствен софтуер, внимавайте да използвате продукти, лицензирани под GPL.
Операционните системи от семейството на BSD, включително FreeBSD, се разпространяват под BSD лиценза, който съдържа повече свобода от GPL лиценза, без да се изисква всички производни да запазят всички условия на оригиналния лиценз. BSD лицензиран софтуер е безплатен за използване за разработване на патентовани приложения със затворен код.
Друга фундаментална разлика е, че FreeBSD съдържа не само ядрото, но и основните компоненти на операционната система, разработени от екипа на FreeBSD. Докато Linux е само ядрото. Но вече специфичен комплект за разпространение включва, в допълнение към ядрото, определен набор от софтуер, често събиран от различни източници.
Използване на FreeBSD и Linux
Интересното е, че както FreeBSD, така и Linux са в основата на много други системи с отворен код и собствени системи и се използват на различни устройства.
Например, FreeBSD е основата за следните продукти:
- FreeNAS е операционна система за мрежово съхранение.
- pfSense е дистрибуция на защитна стена.
- m0n0wal е вграден комплект за разпространение на защитна стена.
- Дарвин е ядрото на macOS, iOS системите.
- Junos е операционна система за мрежово оборудване от Juniper Networks.
- OneFS на Isilon Systems е операционната система за NAS от Dell EMC.
- Уреди Netflix Open Connect – сървъри за поточно предаване.
- Игрови конзоли PlayStation 3, PlayStation 4, PlayStation Vita от Sony Computer Entertainment.
- и т.н.
Въз основа на ядрото на Linux се създават следните:
- Android е операционна система за мобилни устройства (Google).
- Tizen е операционна система за мобилни устройства (Samsung).
- VMware ESXi е хипервизор.
- ChromeOS е операционната система за лаптопа Chromebook.
- ОС за едноплаткови компютри Cotton Candy и Raspberry Pi.
- ОС за мрежово оборудване Linksys.
- и т.н.
Заключение
Системите с отворен код са се развили с течение на времето и е много по-лесно за съвременния потребител да ги инсталира и използва, отколкото преди. Разглежданите системи са много сходни, като изборът може да се направи въз основа на наличието на конкретна задача и подходящи специалисти, които разбират конкретната система.
ATLEX използва дистрибуцията на CentOS на сървъри и сървъри, за да предостави услуга, базирана на Xen. За облачни услуги на OpenStack се използва дистрибуцията на Ubuntu. И FreeBSD управлява някои сървъри за услуги.
Можете да инсталирате и тествате всяка ОС на виртуални машини в нашата, а специалистите на компанията винаги ще ви предоставят квалифицирана поддръжка.
В областта на съвременния софтуер с отворен код думата "Linux" на практика се превърна в синоним на понятието "операционна система", въпреки че малко хора знаят, че в действителност тя далеч не е единствената ОС като Unix днес, чиито изходни кодове са налични. за всички.
През 1999 г., според данни на IOSC, почти една трета от всички машини, които са били свързани с интернет, са работели с Linux, докато близо 15% са работели с FreeBSD. Какъв вид система е това и до ден днешен само няколко съвременни потребители на компютри знаят, въпреки всичките й предимства и широко разпространено използване наведнъж. Струва си да се отбележи фактът, че много от световните лидери в областта на уеб-услугите активно работят върху тази система. По-специално, трябва да се отбележи, че системата Yahoo днес е базирана на FreeBSD. Какво дава това на потребителите, те самите едва ли знаят и дори мислят, но собствениците на системата са сигурни, че това е правилното решение.
Какво е BSD?
BSD е съкращение от Berkeley Software Distribution. Това беше името на софтуера, който се разпространяваше в изходни кодове в Бъркли. Струва си да се отбележи, че оригиналното допълнение към стандартната операционна система UNIX беше единственото нещо, което FreeBSD представляваше. Какво беше това в сравнение с текущата версия на системата?
Създадени са няколко операционни системи с отворен код, базирани на версия 4.4 на BSD-Lite. По-специално, съставът на тези системи включваше разработването на други проекти, сред които проектът GNU заслужава специално внимание.
структура
Предимствата и характеристиките на тази система се различават в структурата на FreeBSD. Каква е тази структура:
- Ядро, което е проектирано да планира внимателно всички процеси, да управлява паметта, да работи с различни устройства и да поддържа многопроцесорни системи. Трябва да се отбележи, че за разлика от Linux OS, в този случай има няколко типа BSD ядра, които се различават по различни характеристики.
- Библиотеката C, която се използва като основен интерфейс за системно програмиране и е базирана на код от Бъркли, а не от проекта GNI.
- Всички видове помощни програми за файлове, компилатори, обвивки, линкери и други програми за крайни потребители, някои от които са базирани на GNU код.
- FreeBSD UNIX е операционна система, включително X Window, която е пряко отговорна за Тази система се използва в по-голямата част от версиите на BSD и се поддържа официално от проекта X.Org. Тази система позволява на потребителя да избира измежду няколко графични скина, както и разнообразие от леки мениджъри на прозорци.
- Голям брой други системни и приложни програми.
Какво е истинският UNIX?
Струва си да се отбележи, че самата FreeBSD UNIX винаги е различна операционна система. И видовете такива системи не са клонинги един на друг. Те са само потомци на общ прародител, традиционната операционна система UNIX. Този факт може да е донякъде изненадващ, особено ако си спомняте, че разработчикът на тази операционна система никога не е разкривал кодовете на своите разработки пред широката публика.
BSD UNIX ли е?
Всъщност операционната система UNIX никога не е била софтуер с отворен код, така че BSD определено не може да се нарече UNIX система, дори само защото графичният интерфейс на операционните системи е различен. Въпреки това, в същото време компанията, разработила UNIX, активно използва разработки на други хора, и по-специално това се отнася за софтуер, разработен от организацията CSRG.
Първоначално BSD дистрибуциите, както и графичният интерфейс на операционните системи, бяха комплекси от потребителски програми и тази ситуация продължи точно докато компанията сключи договор с DARPA, подчинен. Целта на този договор е да актуализира различни комуникационни протоколи на която се поддържа компютърната мрежа на агенцията ...
През 80-те години на миналия век се появиха няколко компании за работни станции, като много от тях придобиха UNIX лицензи, вместо да се опитват да разработят свой собствен софтуер от нулата. По-специално, заслужава да се подчертае Sun, който направи това и реши в крайна сметка да пусне собствена операционна система, базирана на версия 4.2BSD, която се нарича SunOSTM. Когато UNIX компанията AT&T в крайна сметка реши да комерсиализира собствената си операционна система, се появи доста строга реализация - System III, последвана с течение на времето от пускането на System V.
По каква причина тази операционна система остава непотърсена?
Има редица причини, поради които FreeBSD 10 е по-малко популярен днес:
- Разработчиците най-често се интересуват от качеството на собствения си код и повече от полирането му, отколкото от рекламата.
- Като цяло популярността на Linux е следствие от редица външни фактори по отношение на този проект, по-специално това се отнася до медиите, както и компании, които са решили да създадат свой собствен бизнес, предоставяйки услуги на потребителите на тази операционна система .
- Разработчиците на BSD са изключително по-опитни от разработчиците на Linux и затова обръщат много по-малко внимание на улесняването на живота на обикновените потребители. С други думи, настройката на FreeBSD за обикновения потребител е по-сложна от
- През 1992 г. UNIX разработчик решава да съди BSDI, който доставя операционната система BSD / 386. Основната точка на обвинението в случая беше, че ОС съдържа затворен код, собственост на ищеца, и изглежда, че в крайна сметка делото е било решено извън съда през 1994 г., но цял комплекс от вторични съдебни спорове, дори и днес, трови живота на много хора.
- Смята се, че самите проекти на BSD се различават и дори могат да противоречат един на друг. Това мнение се основава на събития, случили се преди много време.
Кое е по-добре - Linux или BSD?
Днес най-често срещаният избор за инсталиране на Apache сървър е FreeBSD вместо традиционната Linux система за повечето други системи. За обикновения потребител разликата между тези системи е изненадващо малка, тъй като и двата продукта са базирани на UNIX. И двете системи са разработени на некомерсиална основа.
Кой притежава BSD?
Струва си да се отбележи, че няма конкретно лице или компания, която да притежава разработката на BSD. Разработването и последващото разпространение на тази система се извършва от цяла група висококвалифицирани и същевременно посветени на проекта специалисти, събрани от цял свят. Някои BSD компоненти са отделни проекти с отворен код, които имат свои собствени закони и екипи за разработка.
Какво трябва да изберете?
Изборът между тези операционни системи наистина е доста труден, така че има няколко съвета, които ви позволяват да изберете коя опция е оптимална – Linux или FreeBSD. Командите и в двата случая са доста сходни, така че изборът най-често може да се базира на следното:
- Ако вече използвате определена операционна система с отворен код, тогава дори не трябва да променяте нещо.
- Системите FreeBSD могат да работят много по-добре, но това правило не е универсално.
- BSD системите имат доста добра репутация, особено когато става въпрос за надеждност.
- Проектите на BSD имат по-добра репутация заради високото си качество и пълнотата на наличната документация.
- BSD може да използва по-голямата част от изпълними файлове на Linux, докато Linux не може да използва много BSD изпълними файлове.
Предоставя техническа поддръжка и услуги за FreeBSD - портове и системи - FreeBSD Mall, Inc.
Събитията в света на операционните системи за свободно разпространение от семейството на BSD: FreeBSD, OpenBSD и NetBSD отдавна привличат вниманието на разработчиците на ОС. Информацията за възможностите, предимствата и недостатъците на такива системи, както и информацията за техните търговски реализации (BSD / OS) ще бъдат полезни, когато потребителят отново се изправи пред въпроса: дали да закупи комерсиална Unix система или да направи крачка към безплатното софтуер. Освен това статията може да бъде от интерес за всеки, който иска да знае самата история на Unix OS.
Историята на BSD Unix започва, когато операционната система Unix дойде в университета в Бъркли (Калифорния, САЩ) през 1974 г. По това време тази ОС вече беше разпространявана в продължение на няколко години срещу номинална такса от Bell Technical Labs (BTL) сред университети и други образователни институции, след като успя да спечели симпатиите на потребителите, които харесаха отвореността на системата: Unix беше доставен в изходния код (без BTL поддръжка и гаранции) и потребителите имаха възможност самостоятелно да го проучат, поправят и разширят. Всичко това породи желание да споделят работата си с други Unix ентусиасти и в много отношения оформи специфичния начин на мислене и Unix културата. Трябва да се отбележи, че служителите на Bell Technical Labs действаха много мъдро (може би дори без да осъзнават това), оставяйки Unix да плава свободно. Freedom направи услуга както на самата система, така и на нейните потребители - много професионалисти са израснали в Unix, да не говорим за броя на защитените дипломи по теми, свързани с тази ОС. Така че може да се счита, че Unix OS навлезе в търговския свят с пълно университетско образование. Между другото, съвсем наскоро BSDI реши да предприеме такава стъпка - прехвърляне на изходния код в образователни институции. Чудя се дали историята ще се повтори?
Но да се върнем към Бъркли. Именно там се раждат много от идеите, които сега станаха общоприети - поддръжка на TCP/IP протокола в Unix, система за виртуална памет, бърза файлова система (FFS), ex и vi редактори, BSD сокети (интерфейс за програмиране на мрежови приложения ), sendmail, csh и много други.... Университетът също така предостави на света страхотни специалисти, които оформиха развитието на Unix по много начини – помислете за Ерик Олман, Бил Джой или Чък Хейли. Те бяха първите, които получиха Unix текстовете, които се „установиха“ в Бъркли. Unix е разработен тук от Групата за изследване на компютърните системи (CSRG), която за съжаление се разпадна през 1992 г. Въпреки това, най-добрите му традиции са продължени от BSDI (Berkeley Software Development, Inc.) и групите за разработка на FreeBSD и NetBSD. Съвсем наскоро беше добавен екипът на проекта OpenBSD.
1. Всичко започна с 386BSD
По това време имаше няколко версии на BSD Unix, обикалящи по света, но всички те имаха едно общо нещо: изискваха лиценз за използване на оригиналния изходен код на Unix. По-голямата част от BSD кода е написана в Бъркли и един ден някой забеляза, че не е останал много от оригиналния код; така се роди идеята да се създаде безплатен Unix и да започне да се разпространява в мрежата (Net дистрибуция).
Уилям и Лина Джолиц решиха да пренапишат части от системата, които липсваха, за да създадат BSD Unix с отворен код. Резултатът беше 386BSD версия 0.0. Все още не готов за използване, 386BSD имаше едно неоспоримо достойнство: вече не изискваше страшния изходен лиценз за създаване на работеща версия на системата. Скоро последва 386BSD 0.1 (дотогава Linux, друг член от семейството на безплатни Unix системи, съществуваше повече от година). Много хора, които искат да се побъркат с изходния код, с който вече са запознати, решиха да започнат да използват и пачват 386BSD 0.1. В резултат на това от юни 1992 г. бяха направени голям брой корекции и подобрения в системата. Много FTP сървъри дори имаха неофициален patchkit (набор от корекции), който направи 386BSD по-стабилен и по-лесен за използване - много проблеми в системата бяха решени с patchkit. Но днес, след някои правни проблеми с част от кода, принадлежащ на AT & T / Berkeley, оригиналната система стана доста трудна за намиране - тя беше премахната от FTP сървъри по целия свят.
Трябва да се помни, че когато некомерсиалното семейство BSD беше създадено за първи път, Уилям и Лин използваха лента, наречена Berkeley Net Release / 2 като основа. След като по този начин изградиха солидна основа, те положиха, без да искат, и бомба със закъснител. В резултат на съдебни битки, някои от файловете на оригиналната Net / 2 лента бяха определени само като двоични. Следователно те трябваше да бъдат пресъздадени от нулата, за да получат наистина безплатна система за разпространение. Това е основната причина, поради която е почти невъзможно да се намери оригиналната 386BSD версия 0.1 сега. За да замени 386BSD, се родиха три нови системи под нови имена. Първо беше NetBSD, последван скоро от FreeBSD, а най-скоро OpenBSD се присъедини към групата.
Ако погледнете файла README, който идва с всяка BSD система, ще откриете, че тези системи са базирани на BSD 4.4-Lite. Екипът за разработка на FreeBSD използва дистрибуцията на BSD 4.4-Lite и генерира липсващите части от кода; всичко това, след по-нататъшно развитие, се превърна във FreeBSD. Разработчиците на NetBSD започнаха разработката с 386BSD, като добавиха и наличните части от BSD 4.4. Системата OpenBSD по едно време се отдели от NetBSD - разработчиците решиха да комбинират най-добрите характеристики на FreeBSD (използваемост и функционалност) и NetBSD (преносимост към голям брой платформи). По този начин екипите за разработка на Open / Free / NetBSD пресъздадоха онези файлове, които не бяха в оригиналния пакет BSD 4.4-Lite или не можеха да бъдат свободно преразпределени. Всички системи са възможно най-близки до BSD 4.4, въпреки че всяка има своите предимства и недостатъци.
Нека разгледаме тези системи по-подробно, но веднага си струва да се отбележи, че много често много от казаното за една система се отнася за друга: всички тези операционни системи OpenBSD, FreeBSD и NetBSD се разработват отделно, но не изолирано.
2. NetBSD
Проектът NetBSD е резултат от усилията на голяма група ентусиасти да създадат безплатна Unix-съвместима операционна система. NetBSD се основава на голям брой безплатен софтуер, най-вече университета в Бъркли BSD4.4-Lite. Системата работи на различни платформи - от DEC Alpha до Apple Macintosh и z80, идва с пълен изходен код и се поддържа от разработчиците и потребителите на системата. Разработчиците се фокусираха върху надеждността и поддръжката на голям брой платформи. Днес почти няма хардуерна конфигурация, където NetBSD да не може да бъде инсталиран.
Реализацията на проекта започна през януари 1993 г., а до април се появи първото официално издание - версия 0.8, която все още работеше само на платформата i386. Тя беше последвана от версия 0.9 през август същата година. NetBSD първоначално беше наследен от 386BSD, който използва Berkeley Net Release 2 (BNR / 2) и естествено, подобно на други базирани на BNR / 2 операционни системи, се сблъска с трудности в някакъв момент. Само година след пускането на 0.9, през октомври 1994 г., се появява NetBSD 1.0 – първата версия на NetBSD, базирана на BSD4.4-Lite. В допълнение, системата е пренесена към HP300 / 9000, Macintosh, PC532, Sun SPARC и Amiga. През септември 1995 г. е създадена NetBSD Foundation, организация с нестопанска цел, която става координиращ орган на проекта NetBSD. Скоро (ноември 1995 г.) NetBSD се пренася към Atari, DECstation, VAX, Sun3; той добавя двоична съвместимост (в рамките на същата платформа) с FreeBSD, iBCS2, SunOS, Ultrix, HPUX, Linux, OSF / 1, SVR4. Версията е с номер 1.1. Най-новата версия на NetBSD беше реализация 1.2 (октомври 1996 г.) и заедно с много подобрения и промени се появи поддръжка за DEC Alpha платформи, Motorola MVME платки, SPARC / Sun4m.
NetBSD се разпространява в два варианта: официално издание и NetBSD-current. FreeBSD и OpenBSD имат едно и също оформление. Официалната версия има номер на версията и включва добре отстранени помощни програми, ядро, източници и инструменти за инсталиране. Изданието е баланс между функции и стабилност - по-лесно за инсталиране от текущата версия. Такива версии са добре отстранени и се появяват сравнително рядко, така че са подходящи за тези, които искат да имат стабилна работеща система. Тези версии са по-удобни за поддръжка, тъй като винаги е ясно какво е заложено. Най-големият проблем с официалните версии е, че потребителят не получава достъп до базата на изходния код с най-новите подобрения и поправки. Официалната версия е лесна за инсталиране - всяка платформа има подробни инструкции, образи на диск за зареждане или файлови системи miniroot. Обикновено има процедура за лесно мигриране от предишна версия към нова.
С NetBSD-current ситуацията е съвсем различна. Текущата версия се появява всяка вечер и е моментна снимка на изходното дърво на NetBSD, което трябва да бъде прекомпилирано на вашата платформа. Тъй като работата се извършва постоянно, текущата версия понякога не е напълно отстранена, може да съдържа грешки, може дори да не се компилира. Текущата версия е полезна за разработчиците на драйвери, разработчиците на системен софтуер и тези, които допринасят за създаването на NetBSD. Текущата версия позволява на разработчиците да се „придържат заедно“, да улавят грешки и да правят промени бързо. В даден момент текущата версия започва да се превръща в официално издание, провежда се бета тестване и от този клон израства нова текуща версия и т.н. Така разработката не спира за миг и в същото време нито една фаза скрит от общността - винаги можете да предложите свои собствени промени и допълнения, които (ако имат смисъл) ще бъдат включени в текущата.
Проектът NetBSD има за цел да следва индустриални стандарти като POSIX и Standard C. Припомнете си, че POSIX (интерфейс на портативни операционни системи) е името на група, финансирана от IEEE, която разработва стандартен API за Unix-подобни операционни системи. Има POSIX.1 (IEEE Std1003.1-1990), който стандартизира API за C POSIX.2 (IEEE Std1003.1-1992), който стандартизира как работят обвивката и помощните програми. Други стандарти POSIX описват езиците Ada и Fortran, разширенията в реално време и т. н. NetBSD вече е много близък до POSIX.1, така че пренасянето на софтуер към NetBSD е лесно. Но е малко вероятно NetBSD някога да получи POSIX-съвместим системен статус, тъй като сертифицирането струва много пари. Въпреки това, разработчиците вярват, че NetBSD е по-близо до POSIX и Standard C, отколкото всяка друга безплатна операционна система.
3. FreeBSD
Проектът FreeBSD е роден в началото на 1992 г. и се разраства отчасти от 386BSD Unofficial Patch Kit, или по-скоро от patchkit, воден от Нейт Уилямс, Род Граймс и Джордан Хъбард. Освен това Дейвид Грийнман и Джулиан Елишър участваха в разработката, въпреки че официално се присъединиха към проекта само месец след началото на неговото изпълнение. Тъй като организацията на работа чрез patchkit вече не можеше да спаси положението, основната цел на проекта беше да създаде междинна версия на 386BSD, която да коригира повечето грешки. Може би някой все още може да си спомни работните заглавия на проект като 386BSD 0.5 или 386BSD Interim, който отразява текущото състояние на нещата.
Точно по това време Бил Джолиц се оттегли от по-нататъшната поддръжка и развитие на системата, в резултат на което проектът за надграждане 386BSD се превърна в това, което сега познаваме като FreeBSD (името е измислено от Дейвид Грийнман). Джордан Хъбард се обърна към Walnut Creek CDROM (САЩ) с надеждата да отвори допълнителни канали за разпространение на операционната система, която все още не е изградена. Walnut Creek CDROM не само подкрепи идеята за разпространение на FreeBSD на CD, но също така помогна за хардуера и високоскоростните интернет връзки. Първият FreeBSD CD се появи през декември 1993 г. - това беше FreeBSD 1.0, версия на който също се разпространяваше в мрежата. Системата е базирана на лентата 4.3 BSD Lite (Net / 2) от Бъркли и допълнена с компоненти от 386BSD и Free Software Foundation. За първата версия успехът беше доста значителен и скоро, през май 1994 г., се роди много успешна версия 1.1.
Тогава обаче на хоризонта започнаха да се събират облаци. Novell, наследникът на AT&T, започна дело за забрана на кодови фрагменти на лентата Berkeley Net / 2, която произхожда от AT&T. Университетът в Бъркли беше принуден да пусне "олекотена" версия, наречена BSD4.4-Lite, и да препоръча на всички потребители на Net / 2 да преминат към нея. Следователно в края на юли 1994 г. проектът FreeBSD спира да доставя FreeBSD, но според лицензионното споразумение има право да пусне друга версия преди "X-hour". Резултатът е FreeBSD 1.1.5.1 - резултат от една година в Net / 2. Тази версия имаше по-добра производителност от всички предишни, имаше по-висока надеждност и беше страхотен продукт сама по себе си.
Но сега разработчиците трябваше да започнат отначало, въз основа на новия и непълен комплект BSD 4.4-Lite. Поради различни законови ограничения екипът на Berkeley CSRG премахна голяма част от кода, използван за създаване на стартираща, работеща система и всъщност портът на Intel x86 беше много непълен. Проектът FreeBSD започва да работи отново през декември 1994 г. и още през януари 1995 г. FreeBSD версия 2.0 се появява в мрежата и на компактдиск. Въпреки някои груби ръбове, системата имаше голям успех и скоро беше последвана от по-бързия и лесен за инсталиране FreeBSD 2.0.5, издаден през юни 1995 г.
В края на тази година беше пусната версия 2.1, много стабилна, в много отношения подобрена, която във всички отношения надмина версията на FreeBSD 1.1.5.1. В течение на две години беше извършена огромна работа за превръщането на непълния пакет BSD 4.4-Lite в работеща, надеждна и удобна за потребителя операционна система. Човек не може да не се възхищава на екипа за разработка, към който по това време се присъединиха много отлични и ентусиазирани програмисти. Малко по-късно 2.1 се превърна в 2.1.5, след това в 2.1.6. И в двата случая стабилността е подобрена, добавени са допълнителни драйвери и са отстранени грешки. През февруари 1997 г. беше открита неточност в системната библиотека в манипулатора на променливата на средата PATH_LOCALE и тогава екипът за разработка на FreeBSD премахна версия 2.1.5 / 2.1.6 от всички FTP сървъри и пусна версия 2.1.7 (освобождаване на сигурност). След това беше пусната версия 2.2 и започна работата по FreeBSD 3.0, която планира да подобри качеството на виртуалната машина (VM), което ще подобри емулацията на DOS и Windows приложения.
Освен това съвсем наскоро беше стартиран амбициозен проект за повторение на целия FreeBSD код (около 120 MB) ред по ред. Целта на проекта е да се отървем от проблемите със сигурността, да поправим намерени грешки и да подобрим цялостния стил. Дървото на изходния код е разделено на отделни части, които се преглеждат от различни програмни екипи; всички поправки се проверяват многократно от независими експерти. Всичко това дава надежда, че FreeBSD ще стане по-сигурна система. Между другото, след като анализирате пощенския списък на BUGTRAQ за последните шест месеца, можете да видите, че комерсиалните операционни системи като Solaris, IRIX, да не говорим за NT, значително превъзхождат FreeBSD по отношение на броя на грешките в критичните за сигурността програми. Повече информация за FreeBSD Audit Project може да намерите на: http://www.freebsd.org/auditors.html.
По този начин разработването на FreeBSD не е затворен процес, а по-скоро поддържа дълга традиция на сътрудничество между специалисти от цял свят, работещи по една и съща задача. Най-активните разработчици преминават към основния екип на FreeBSD, който отговаря за цялостната посока и координация на проекта.
4. OpenBSD
Проектът OpenBSD наскоро се отдели от NetBSD и също е член на семейството BSD4.4-Lite. OpenBSD се развива самостоятелно днес; в допълнение към собствената си разработка, включва добри идеи от други групи (FreeBSD / NetBSD). Разработката на OpenBSD е започната от Тео де Раат, един от четиримата създатели на NetBSD. И ако по-рано за OpenBSD все още беше възможно да се каже: "OpenBSD е NetBSD плюс допълнителни функции", сега, след дълга работа, е очевидно, че OpenBSD е независима система от семейството BSD - много в сравнение с оригиналната версия , беше добавен и коригиран.
OpenBSD е наследил добра мултиплатформена поддръжка, но процесът на пренасяне продължава. Групата OpenBSD обръща специално внимание на сигурността на системата: по-специално отдавна беше направен опит да се преработи изходният код, за да се предотвратят възможни атаки, свързани с фиксиран размер на буфера, както и да се коригират много програми. OpenBSD има отлична POSIX съвместимост, надеждност и сигурност. Екипът на OpenBSD винаги реагира своевременно на съобщения за неточности и възможни проблеми, отворен е за нови разработчици и всеки специалист има възможност да добави към системата това, което й липсва.
OpenBSD е съвместим с много разширения на FreeBSD (особено със системата за портове на FreeBSD); Наскоро се появи поддръжка за банкомати и се работи за активиране на IPX и редица други мрежови протоколи. Едно от основните предимства на OpenBSD е разбирането за необходимостта от сигурност на системата. OpenBSD остава далеч най-надеждната Unix-подобна компютърна система в това отношение. Последната версия на OpenBSD е 2.0, като скоро ще се появи 2.1 (на CD и FTP сървъри).
5. Net / Free / OpenBSD функции
И така, какво представлява семейството на BSD Unix безплатни системи за разпространение днес?
FreeBSD е Unix-подобна операционна система за компютри, базирана на архитектура на Intel, която включва 386, 486 и Pentium процесори. В допълнение, NetBSD / OpenBSD поддържа много други платформи. И трите системи предоставят много функции, които преди са били налични само на по-мощни и скъпи машини.
6. Особености на реализациите
В допълнение към основната дистрибуция, FreeBSD предлага голяма колекция от пренесени софтуерни продукти от няколкостотин заглавия. Списъкът включва мрежов софтуер, системи за програмиране, игри и др. Пълната колекция заема само 10 MB дисково пространство, тъй като съдържа само списъци с промени, които трябва да бъдат направени в изходния код преди компилацията. За да инсталирате, просто въведете командата "make", след което системата автоматично ще вземе основната версия на програмата от компактдиска или от FTP сървъра, ще направи необходимите промени и ще компилира. За тези, които няма да компилират програми сами, е подходяща колекция от готов софтуер (пакети). За да инсталирате програмата, трябва да въведете една единствена команда "pkg_add" с името на архива, което може да се намери на CD или FTP.
FreeBSD е богат на функции, надежден и бърз. Може би тази система от цялото семейство безплатни BSD системи се развива най-динамично сега. Много внимание се отделя на съвместимостта с други системи и използваемостта. Ако потребителят работи на x86, тогава трябва да обърнете внимание на FreeBSD - това ще ви позволи много плавно да влезете в света на BSD системите. NetBSD се фокусира повече върху поддръжката на различни платформи, докато OpenBSD се опитва да комбинира най-доброто от FreeBSD и NetBSD с фокус върху сигурността на системата. В допълнение към отличната работа, която CSRG свърши, екипите за разработка са прекарали хиляди часове в усъвършенстване на системите за максимална производителност и надеждност. Докато търговските гиганти се борят в областта на операционната система за компютър, FreeBSD, NetBSD и OpenBSD ги предлагат сега.
7. Примери за употреба
Областите на приложение, в които може да се използва BSD Unix, са ограничени само от въображението на потребителя - от разработка на софтуер за автоматизация на предприятието до автоматично управление на сателитни антени. Ако нещо може да се направи с помощта на комерсиална реализация на Unix, то най-вероятно може да се направи с помощта на BSD Unix, който предлага много висококачествен софтуер от изследователски центрове и университети по целия свят безплатно. Броят на наличните търговски приложения нараства всеки ден.
Тъй като изходният код на системите е напълно достъпен, системата може да бъде персонализирана и/или адаптирана за решаване на специфични проблеми, осигурявайки гъвкавост, която не се среща в много търговски затворени системи. Ето само няколко примера за използване на FreeBSD, NetBSD или OpenBSD:
BSD Unix обикновено не включва код за поддръжка на DES, за да се избегне нарушаване на ограниченията за износ в САЩ, където е наличен допълнителен компонент за предоставяне на DES; за жители на Европа и други страни има и DES реализация, разпространявана чрез европейски FTP сървъри. Ако защитата с парола е всичко, което се изисква от функцията crypt () и не е необходимо да използвате пароли на други системи (Sun, DEC и т.н.), FreeBSD предлага силна криптографска защита, базирана на MD5. Този модел осигурява сигурност на ниво DES или дори го надминава, така че е подходящ за повечето потребители на системата. OpenBSD поддържа MD5 и се работи за добавяне на модел за криптиране на blowfish. FreeBSD също се движи към внедряване на допълнителни схеми за криптиране, между които може да се превключва.
8. BSD/OS е комерсиална BSD система
Досега фокусът беше върху безплатните BSD системи, но има смисъл да се спомене и комерсиалната BSD / OS версия на Berkeley Software, DesingBSD / OS. Няколко водещи експерти от CSRG основаха BSD Inc. през 1991 г., за да разработят BSD технологията и да я предоставят на търговски клиенти.
BSD / OS е напълно функционална, POSIX-съвместима Unix система за 386, 486 и Pentium процесори. Системата е базирана на софтуер от университета в Бъркли, както и на други източници и компоненти, разработени в BSDI. Първата версия на BSD / OS беше доставена на клиента през март 1993 г. Днес BSDI Internet Server, базиран на BSD/OS, е широко признат в своя клас системи и е получил няколко награди (например InfoWorld Top Score Award през 1995 г.). Подобно на други BSD системи, тази ОС може да служи като WWW сървър, рутер и т.н. BSDI Интернет сървърът носи в света на компютрите много от това, което преди беше възможно само на по-мощни системи: многозадачност, поддръжка на мрежа. И така, тестовете за скорост на BSDI показаха, че BSD / OS на Intel 486/66 развива скорост на нивото на Sun SPARCStation II, а процесорът Pentium вече е сравним с SUN SS10.
BSD / OS включва всички компоненти на цялостна система: X11R6, TCP / IP (+ SLIP / PPP), NFS, C / C ++ инструменти за разработка, набор от приложения и др. BSD / OS се доставя в двоична форма и срещу отделно заплащане - с изходни текстове. Може би единственото нещо, в което BSD / OS очевидно превъзхожда безплатните си конкуренти, е поддръжката. BSD/OS е търговски продукт и неговите потребители имат горещи телефонни линии, отдели за поддръжка и др.
9. И така, кое е по-добро?
Няма категоричен отговор на този въпрос. Всеки спор в "свещената война" е загуба на време. Но можете да го погледнете и от другата страна. Всички системи предоставят дългоочаквани и уникални възможности: напълно функционална операционна система работи на популярен хардуер и въпреки това нейният изходен код е напълно достъпен. Тези, които работят в компютърната индустрия от дълго време, ще си спомнят, че операционните системи почти винаги са били създавани от доставчици на специфичен хардуер и като правило не е имало алтернатива на тяхната система. Изходният код никога не е бил публикуван (много компании все още продължават тази „добра“ традиция). Възможно е да станете истински професионалист само чрез независимо разбиране на структурата на системата, логиката на нейната работа.
Но днес ситуацията се промени. Потребителят има възможност да закупи компютър, който ще бъде няколко пъти по-мощен от многопотребителския VAX, и в същото време да избира измежду няколко безплатни операционни системи (BSD, Linux и др.) Класически въпрос: ако нещо изглежда като патица , ходи като патица и кряка като патица, как се казва? Отговорът зависи от това дали думата "патица" е запазена марка! Ако е така, тогава най-доброто, на което можете да разчитате без съгласието на собственика на търговската марка, е „създанието, подобно на патица“. Unix е търговска марка на X / Open Company, така че други системи, които не са упълномощени да го използват, наричат своите продукти като Unix-подобни или дори "UN * X-подобни". Следователно нито една от изброените ОС не може формално да се нарече Unix, но станаха ли по-лоши от това?
Днес безплатните операционни системи се развиват динамично, по никакъв начин не отстъпват и в много отношения дори превъзхождат своите търговски конкуренти. Освен това на потребителите се дава възможност лично да влияят върху развитието на системата - достатъчно е да има добри програмисти в персонала, за да станат независими от производителя на операционната система. Не е нужно да чакате няколко седмици, ако се открие някаква неточност или има нужда да се подобри или добави нещо. Вместо затворен екип от разработчици (колко хора знаят имената на създателите на Windows 95?), има общност от ентусиасти, отворени за сътрудничество.
Можете да изберете операционната система, която ви подхожда най-добре: FreeBSD, OpenBSD, Linux, NetBSD или каквото и да било. Но каквото и да изберете, това е добра сделка. Много малки фирми, доставчици на интернет услуги, други организации и потребители отказват да харчат пари за това, което може да се получи безплатно, и все повече използват безплатни Unix системи. Страхувате ли се, че няма да можете да намерите софтуера, от който се нуждаете? Първо, за вашите интернет услуги, второ, можете да закупите софтуер за BSD / OS и / или Linux и да го използвате във вашата система - двоичната съвместимост е добре отстранена. В допълнение, много търговски разработчици сега се обръщат към безплатни BSD системи.
литература
В. Колонцов. Намерете, проверете и неутрализирайте. Отворени системи. - 1996, № 6, с. 58-63.
Повече информация за операционните системи BSD
386BSD -по-старите версии на BSD вече са фокусирани изключително върху академичната и изследователската общност, разпространявани чрез Dr. Дневник на Доб на компактдискове.
FreeBSD - BSD версията за платформата Intel е насочена към широко използване, разпространява се на CD (Walnut Creek CD-ROM, http://www.cdrom.com) и чрез FTP ( http://www.freebsd.org).
BSD / OS (BSDI интернет сървър) -търговска BSD система от Berkeley Software Development, Inc. за платформи на Intel ( http://www.bsdi.com).
Usenet групи: comp.Unix.bsd. * Fidonet: ru.Unix ru.Unix.bsd IRC: #netbsd, #freebsd, #openbsd и др.
BSD OS живееше, живее и ще живее
Тази бележка се роди в хода на многобройни преходи от една система към друга, в хода на много години (в ИТ времеви мащаби) на тяхното съвместно използване, както и в хода на разсъждения по темата: на каква система да инсталирам нова машина? Непосредственият тласък за нея беше кореспонденцията с редица автори и мечтите за идеално разпространение, които не се обсъждаха толкова дълго. Но първо, няколко предупреждения
Трябва да ви предупредя веднага - няма да има отговор на въпроса, представен като заглавие. Защото аз самият не го познавам. Но за това, че следвам завета на великия римски историк - мога да гарантирам. Защото обичам и двете системи и освен това използвам и двете системи в ежедневието си - понякога заедно, понякога поотделно, в зависимост от задачите, обстоятелствата и само настроението ми.
И още нещо: по-нататък няма да се каже нито дума за използването на Linux или FreeBSD като сървъри, локални мрежови възли и подобни системни администратори. И изключително - за потребителя, тоест десктопа, техните качества. Предвидявайки реакцията на определена категория читатели, аз съм готов да подчертая последната фраза с етикет и повторете два и три пъти :-)Субективно въведение
Скоро минаха четири години, откакто FreeBSD и Linux се редуват на моите машини (вкъщи и на работа) на редовни интервали. Или мирно съжителстват в една, отделно взета системна единица. И през това време забелязах интересен модел.
В периоди, когато имам FreeBSD на моята машина, работното ми време е разпределено приблизително така: 90% е практическа работа (въобще няма значение каква работа е в момента), а 10% е горе-долу нездравословна експерименти върху системата. Веднага щом някакъв Linux се сгуши в ъгъла на твърдия диск - и делът на времето на експериментите веднага скача до 50%. И през периодите, когато създавах Linux от нулата, експерименталният режим всъщност стана постоянен.
И си зададох въпроса – защо? И - за себе си - отговорих: FreeBSD е съгласувана и хармонична система, в която след комплекс от първоначални настройки няма желание да се добавя или изважда нищо. Не е случайно, че движението, което понякога обхваща широк кръг потребители на Linux, на практика не се е развило в света на FreeBSD: известната работа на Йенс Швайкхард (съществуваща в) е по-скоро описание на автоматизирана алтернатива на sysinstall, отколкото ръчно изграждане на собствена система от нулата.
Linux не може да демонстрира такава вътрешна хармония. И следователно желанието да промените нещо в вече инсталирана система, да подобрите, добавите, почистите или дори просто да възстановите всичко, възниква постоянно и се преодолява само от липсата на време.
Това обаче не означава, че недвусмислено считам FreeBSD за най-добрата система за тази работа. Защото работата ми, освен всичко друго, се състои в създаване на различни бележки около компютъра. Сюжети, които доставят същите нездравословни експерименти в системата, които Linux е толкова предпочитан да прави - и които FreeBSD няма.
Въпреки това, повтарям, всичко това е чисто субективно, защото не всеки се занимава с композиране на бележки около компютри. И затова ще се опитам да направя по-обективно сравнение Първият опит за обективизъм: "желязо"
От какво се нуждаят повечето потребители от операционната система като такава? На първо място, разбира се, поддръжка на хардуер, който, както знаете, не страда от монотонност на настолни персонални компютри.
Смята се, че Linux поддържа по-широк набор от хардуер от FreeBSD. Всъщност за последното няма да намерим, да речем, драйвери за принтер от производителя. Пълната поддръжка на съвременните видеокарти се реализира само ако са от NVIDIA (и дори тогава, според прегледите, те са значително по-лоши, отколкото за Linux). Вероятно ще има напрежение в тази ОС и с т.нар. win – модеми. Това е от една страна.
От друга страна, всички доскоро щастливи собственици на ATA RAID и Serial ATA контролери в Linux трябваше да прибягват до всякакви трикове. Освен това не винаги е успешно, особено ако дисковете, прикрепени към такива контролери, е трябвало да се използват като устройства за зареждане. Всъщност ситуацията може да се счита за нормализирана само в най-новите ядра на 2.6.X ...
Във FreeBSD, 5-ти клон, повече или по-малко паралелно, на който контролерът на IDE-семейството се намира твърдият диск: благодарение на CAM (Common Access Method), по някакъв начин ще бъде възможно да се работи с него във всеки случай и ако той също е правилно идентифициран, тогава няма да има пречки за изтегляне от него. И в 4-ти клон - никога не съм срещал проблеми за "същите възрастови" ATA RAID контролери.
Друг пример са звуковите карти. Всички тези, базирани на повече или по-малко обичайни чипове, работеха във FreeBSD без най-малко усилия (ръце или мисли). Същото може да се каже и за звука на "чипсет". В Linux подобни устройства често изискват не съвсем тривиални манипулации с ALSA драйвери, тъй като сега те са вградени в ядрото. Но дори и в последния случай не може да се направи без някои коригиращи действия. Но това вече е предмет на втория опит за обективизъм.
И резултатът от "железния" обективизъм, бих формулирал по следния начин: може би Linux поддържа по-широк набор от всякакви видове оборудване (включително някои екзотични), но целият "хардуер", който се поддържа от FreeBSD (и това е почти всичко стандартно и широко разпространено "желязо"), в повечето случаи е по-лесно за използване. И тук плавно преминаваме към втория вълнуващ момент за потребителя, особено за начинаещ (а не начинаещите отдавна са направили своя избор) момент, чието име е Настройка
Дългогодишното (и внимателно култивирано) схващане, че FreeBSD е по-трудно за инсталиране и конфигуриране от Linux, не може да се дължи на нищо повече от недоразумение. Защото няма нищо общо с реалността.
Да започнем с инсталацията. Инсталирането на FreeBSD със стандартни средства (с помощта на помощната програма sysinstall) се извършва за половин час, не изисква незаменим достъп до мрежата (въпреки че това няма да е излишно) и в резултат на това дава напълно функционална система с конзола на кирилица, функциониращ комутируем (или, според ситуацията, локален), стартиран от X и минимумът, необходим за стартиране на практически дейности (от предварително компилирани двоични файлове). Всички настройки, както за цялата система, така и за пакети от приложения, са разумни (макар и не идеални от гледна точка на конкретен потребител).
Разбира се, инсталирането на FreeBSD изисква известни предварителни познания. Което се свежда до а) идея за разделяне на диска в стил BSD, номенклатурата на устройствата, възприета тук, и стратегията за създаване на файлови системи. Не защото тези моменти са толкова сложни - те са просто, че са много различни от всичко, което потребителят би могъл да знае преди (от опита на общуването с DOS / Windows или Linux). Освен това разделянето на диска и файловите системи върху тях е единственото нещо, което потребителят не може да промени след инсталацията (без пълно преинсталиране, разбира се). Това обаче не е толкова лошо: схемата за оформление и файлови системи по подразбиране, предложена в sysinstall, е доста подходяща за настолен персонален компютър, въпреки че не е идеална в някои специални случаи.
Повечето от инсталаторите, които познавам от различни Linux дистрибуции, се различават от Free sysinstall в две противоположни посоки:
- има по-прости инсталатори - въпреки че според мен това е същата простота, което е по-лошо ... знаете ли какво;
- и има инсталатори, които са по-гъвкави - но те вече изискват от потребителя достатъчно задълбочени познания и ясно разбиране на същността на извършваните действия.
Заедно с Free-shny sysinstall бих инсталирал (от всички известни ми) само инсталатора от Archlinux. Написан под влиянието на първия, свидетелства неговият разработчик, той осигурява почти същата комбинация от простота и гъвкавост.
Въпреки това (и това вече е спецификата на Linux като цялостност на системата), дори и в този случай на изхода не се получава цялостна работеща система. Няма да е възможно да се направи без ръчно усъвършенстване.
Разбира се, настройването след инсталацията също не е забранено във FreeBSD. Тук обаче тя е насочена към постигане на идеала, а не към осигуряване на основна функционалност. Което бих илюстрирал с поредица от примери.
Да започнем със същата русификация. Веднага след инсталирането на FreeBSD, потребителят, ако желае, получава напълно кирилизирана конзола. Въпреки това, в единична версия, с вътрешно кодиране kOI8 – R, вход и изход на екран в DOS кодиране и дори с не съвсем идеални шрифтове. Но от него не се изискват никакви допълнителни действия по основна русификация. И може да приведе оформления и шрифтове в съответствие с идеала си дори по-късно. В Linux дистрибуции, които всъщност не настояват за удобство на потребителя, ръчното редактиране на няколко конфигурации може би не може да бъде избегнато. Няма да се спирам на причините за това (за тези, които си представят разликата между конзолата в Linux и FreeBSD, те са очевидни).
Разбира се, в ориентираните към потребителя дистрибуции на Linux от домашен произход, потребителят получава 100% русифицирана конзола от кутията. Въпреки това, той е направен в съответствие с идеите на разработчиците. Които в никакъв случай не са длъжни да съвпадат с идеите (и най-важното, нуждите) на този конкретен потребител. И в този случай той ще трябва да отдели много повече усилия за корекция, отколкото при русифициране от нулата на който и да е дистрибуторски комплект от списъка, базиран на източници. В подкрепа на това, нека си припомним многобройните статии, посветени на връщането в Red Hat (и Fedore "от Mr. Core) от "прогресивното" UTF кодиране към KOI8, макар и "безполезно" едно, но доста удовлетворяващо за мнозина, много...
Русификацията на конзолата е тясно свързана със стила на init файловете, приети в тази система. И тук линейният BSD стил от гледна точка на потребителя изглежда по-прост от инициирането на System V-стил, приет в Linux, базиран на концепцията нива на изпълнение, чийто превод като "runlevels" може напълно да обърка начинаещ потребител.
Господа, администраторите на индустриални сървъри ще твърдят, че стилът на System V ви позволява гъвкаво да свързвате и изключвате различни стартиращи услуги. няма да споря. Колко често обаче потребител на настолен компютър се сблъсква с такава задача? Много по-често целта му е да убие веднъж завинаги многобройните услуги, които поддържащите дистрибуцията смятат за жизненоважни за неговото щастие...
Не е случайно, че много съвременни дистрибуции на Linux са склонни да използват зареждане в стил BSD, примери за което, освен класическия Slackware, и CRUX, и Gentoo. А в Archlinux концепцията за нивата на изпълнение като цяло губи своето значение, въпреки че съответните думи във файла / etc / inittab могат да бъдат намерени, на практика нивата на изпълнение изобщо не се възпроизвеждат при стартиране на системата. Но опитите за внедряване на "прогресивния" стил на System V в BSD системите не се наблюдават. Не считайте за такива групиращи скриптове на различни услуги в една поддиректория в / etc във FreeBSD 5-ти клон.
Що се отнася до русификацията на X - X, както знаете, тя също е в Африка X. И действията по въвеждане на пътища до файлове с кирилски шрифтове, коригиране на клавиатурната подредба и настройка на превключване от латиница към кирилица ще бъдат неизбежни, без значение какво е OS X отгоре.
Вторият случай е настройката на звука. Във FreeBSD това изисква (за по-голямата част от често срещаните чипове и аудио чипсет) добавяне на един (и същият във всички случаи) ред към конфигурацията на ядрото и прекомпилиране на последния. След това можете просто да забравите за звука - той ще работи по всяко време и навсякъде.
Между другото, можете да направите без прекомпилиране на ядрото, модулът за поддръжка на звука (както почти всички модули) се компилира във FreeBSD безпроблемно, просто трябва да го заредите ръчно или да се уверите, че е зареден при стартиране на системата.
В Linux: започваме с факта, че едно и също аудио с чипсет (и с постепенното изчезване на карти като SB AWE128, става за предпочитане за всички потребители без твърдения за пристрастяване към музика или композиране), по всякакъв начин изисква драйвери ALSA. За щастие сега те са вградени в ядрото и в повечето дистрибуции са включени в ядрата по подразбиране като модули. Ако не, тогава прекомпилирането на ядрото няма да е голяма работа.
Въпросът обаче не се ограничава до прекомпилиране на ядрото. Необходимо е също така да инсталирате подходящия ALSA-инструментариум (и като правило средствата за неговата съвместимост със старата звукова система OSS), да активирате съответния демон и, като използвате не съвсем очевидни средства, да осигурите неговото „самовъзстановяване“ . И след всичко това отново се изправете пред изненади. Например с нежеланието на мирното съжителство на ALSA и изкуствата (озвучителната система KDE). Разбира се, хората могат да спорят, че това са проблеми с KDE, но FreeBSD изобщо ги няма.
Между другото, относно инсталирането на инструменти (и други програми) ... Това изисква система за управление на пакети
Тук доскоро FreeBSD несъмнено държеше надмощие. Неговата система за портове осигурява несравнима комбинация от простота и гъвкавост, оставяйки винаги възможността за изграждане на пакети от източник или инсталиране от двоични файлове. Без да се изключва комбинацията от тези методи. От всички богатства на Linux в тази област, само Apt на Debian, асимилиран в дълбините на много базирани на rpm дистрибуции, може да се сравни с портове. Въпреки това, въпреки че apt предполага възможността да създавате свои собствени пакети, основният метод за това е да се използват предварително компилирани двоични файлове, сглобени в съответствие с идеите на поддържащия за техните зависимости.
Сега ситуацията се промени и в Source Based Linux дистрибуции са широко използвани системи, подобни на портове, които са се развили под силното влияние на техния FreeBSD прототип: Gentoo portages, Sorcery от Sorcerer, CRUX портове, Archlinux Building System от дистрибуторския комплект на едно и също име гъвкавост, глобализация на конфигурацията или прозрачност на устройството, използване и модернизация. Освен това, през десетилетието на тяхното развитие, FreeBSD портовете се превърнаха в много тромава и трудно забележима структура, поддържането им актуално е отделна задача. която сама по себе си вече не е част от базовата система, а от системата на пристанищата).
И тук е уместно да кажем няколко думи за друга широко разпространена легенда - сякаш изграждането от източник с помощта на комплекси за управление, подобни на портове, винаги води до "по-чиста" (тоест свободна от ненужни компоненти) система. Това не винаги е така.
Първо, в самото естество на портовете (и техните клонинги), често има известна излишество в инсталираните компоненти. Пример от учебника е cvs-up, който изисква както базовата система, така и FreeBSD портовете за актуализиране: в двоична форма това е лек компактен пакет, който не натоварва дори потребител с модемна връзка. При изграждане чрез портове той изтегля модулната дистрибуция (тъй като е написана на нея), което няма да е полезно за никого, освен за привържениците на този език за програмиране.
Това, което винаги ме е изненадвало за FreeBSD портовете, е ситуацията на изграждане на моя любим редактор Джо. Което, като зависимост, със сигурност изисква GNU make версия 3.80, въпреки че неговият собствен make е включен във FreeBSD Distributions и не е трудно да се компилира с него с помощта на joe на ръка.
Като цяло, "чистотата" на инсталацията на пакета е много зависима от конкретната реализация на порта. Наскоро открих в новините съобщение за нов мениджър на прозорци, наречен edo - малък, както се казваше, компактен и бърз. Беше намерен и в портовете на FreeBSD, откъдето реших да го изградя. В резултат на това този малък :–) WM издърпа (като зависимост) нищо повече от MySQL ...
Ако обаче смятате, че това поведение на портовете е характеристика на FreeBSD и създателите на техните Linux клонинги са взели предвид грешките от миналото, уверявам ви, че това не винаги е така. Освен това в Linux ситуацията се влошава от особеностите на базовата система, по-точно от непоследователността в развитието на отделните й компоненти.
Всеки, който някога е компилирал Linux от нулата, знае, че някои версии на пакетите Base Linux са склонни да се изграждат само с определени (в никакъв случай най-новите) версии на помощни програми като autoconf и automake, като категорично отказват да го правят с другите си версии (дори по-скорошни и прогресивни).
Разработчиците на Linux базирани дистрибуции понякога заобикалят тази трудност, като насилствено добавят такива "лигави" пакети за autoconf и automake от миналогодишното бутилиране към списъка с зависимости, докато самият базов комплект включва техните текущи версии. В резултат на това, например, в Gentoo, когато изпълнявате bootstrapping или emerge система, можете да се изненадате да видите системата да сърфира в интернет за брадат, като Karl Marx, autoconf, въпреки че новата му версия току-що е разгърната от stage1 tarball. И ако си спомняте, че много хора вярват, че наистина стабилно ядро на Linux може да се изгради само с gcc версия 2.9.X, което води до наличието на два компилатора в системата, тогава за какъв вид "чиста" сборка все още можем да говорим ?
Постигането на разумен баланс между разгръщането на предварително компилирани пакети, инсталирането им от система, подобна на порт, и самостоятелното сглобяване е напълно отделна тема. Междувременно бих се осмелил да формулирам още няколко "лещи":
- FreeBSD, противно на общоприетото схващане, е значително по-лесен за конфигуриране и администриране локално. Дори без да се вземе предвид фактът, че е един, а Linux има много;
- за разлика от това, системата за портове на FreeBSD понастоящем (за разлика от близкото минало) няма значителни предимства пред подобни инструменти от Linux базирани дистрибуции.
Ако внимателно изчислите горните плюсове и минуси на двете операционни системи, можете да стигнете до извода, че резултатът между тях е равен. Може би с леко позиционно предимство за FreeBSD, но толкова незначително, че е напълно разумно да се съгласим на равенство. Въпреки това, всяка ОС се инсталира, конфигурира и разширява от приложения не само за себе си, а за практическа употреба. И следователно трябва да се разглеждат в сравнение с техните потребителски качества
Тук за начало бих се осмелил да изразя бунтовно, от гледна точка на фанатиците на която и да е от обсъжданите системи, мнение (фанатиците обаче ще смятат за бунтовно всяко мнение, което не съвпада с тяхното собствено мнение). а именно:
За графичния потребител има малка разлика между FreeBSD и Linux.
Тъй като такъв потребител прекарва по-голямата част от времето си в X и за него няма абсолютно никаква разлика на каква операционна система работят тези X. Само му се струва, че работи в Linux или FreeBSD (NetBSD, OpenBSD - ще се осмеля да разширя този списък). Всъщност работи в KDE (Gnome, XFce, WindowMaker - добавете необходимото). И ако не трябваше предварително да инсталира и конфигурира своята операционна система, той би имал шанса никога да не разбере в коя от POSIX-съвместимите системи работи: той ще има същите елементи на интерфейса, същите инструменти за конфигуриране и приложения. ..
Така че в сравнителен аспект можем да говорим само за работа в конзолен режим, използвайки системните и потребителските помощни програми от основния комплект.
И тук не мога да не изрека ода за текстовата конзола на FreeBSD и нейните инструменти за управление. Които включват само две команди: vidcontrol и kbdcontrol, чиято цел недвусмислено следва от имената. И които ви позволяват да конфигурирате абсолютно всичко в конзолата – от плътността на знаците на екрана (т.нар. разделителна способност) до цвета на границите, които са различни за всеки виртуален терминал.
Потребителят на Linux първо трябва да разбере кой от двата пакета за управление на конзолата - kbd или console-tools - се използва в неговата дистрибуция. Разбира се, сега те са почти идентични по своите възможности, но всяка има свой набор от команди с малко по-различен синтаксис. А някои настройки (например цветовете на текста и фона) изискват от него да използва команди, които не са включени в нито един от пакетите. И нещо (например същите цветове на границата) все още ще остане недостъпно за него.
Същото важи и за основните команди на двете системи. FreeBSD Distributions е монолит, който е тясно свързан с ядрото и включва всичко, което потребителят може да има нужда, за да администрира и използва системата (а администрирането на локален работен плот е също толкова потребителска задача, колкото и текстообработката или манипулирането на файлове).
Разбира се, Linux има същия набор от класически помощни програми на Unix (по-точно, като FreeBSD, техните аналози). Това обаче са точно дезагрегираните пакети, разработени от GNU Project, по същество независими от операционната система. И вече поради това те не са толкова тясно интегрирани с него и един с друг.
И така, какво е водещият FreeBSD в режим на конзола? Според мен, абсолютно. Но само ако говорим за чисто текстова конзола. Ако обърнем поглед към т.нар. графична конзола (реализирана от Frame Buffer), тогава всичко изглежда малко по-различно.
Като начало графичната конзола FreeBSD (т.нар. Raster Mode) е ограничена до една резолюция от 800x600 (тук говорим за реална резолюция на пикселите, а не за плътност на знаците). И дори тогава на някои чипове този режим изобщо не работи, на други изглежда доста гадно. Всъщност не можах да постигна нормален резултат в растерен режим на нито една от видеокартите, с които разполагам.
В Linux графичната конзола е просто приятна за окото. Дори с поддръжка на Frame Buffer за абстрактни VESA-съвместими карти, разделителните способности могат да варират от 640x480 до 1280x1024, като дълбочината на цвета варира в рамките на стандартния диапазон. Това осигурява не само удобно гледане на изображения, но и много прилично (според мен - повече от прилично) възпроизвеждане на видео. За карти с добре внедрени собствени драйвери в ядрото на Linux (Matrox, ATI, видео с чипсет от Intel) към това се добавя възможността за задаване на нестандартни резолюции на екрана.
Естествено, никой не използва конзолата за манипулиране на изображения и много малко за гледане на видеоклипове. Защо придавам такова значение на графичната конзола? Да, защото неусетно, но идва ерата на дисплеите с течни кристали, бележи смъртта на чисто текстовия режим (но не и на конзолния режим като такъв). Защо - тези, които са видели стандартния текстов режим от 80x25 знака на 18-инчов LCD-монитор с физическа разделителна способност на матрицата 1280x1024, лесно ще разберат. И как би изглеждало на екран със съотношение на страните 16: 9, страх ме е дори да си представя ...
И накрая, има още един въпрос, който е важен за потребителя - относно производителността.
Идеята, че FreeBSD е по-бърза от Linux, е също толкова традиционна, колкото и идеята, че е по-трудна за конфигуриране. Все пак всичко толкова ли е ясно?
Първо, скоростта на изтегляне се счита за един от основните критерии, чиято връзка със скоростта на изпълнение на приложението е малко съмнителна. Спомням си, че от значителен брой операционни системи, които случайно видях в живота си, MS DOS се зареждаше най-бързо :-)
Второ, дори ако считаме скоростта на зареждане като един от критериите за производителност, само 4-ти клон на FreeBSD е по-добър от Linux. Петият клон се зарежда точно толкова дълго, колкото всяка Linux дистрибуция, която използва файловата система на устройството devfs. Разбира се, в благородното семейство Linux можете да вземете такива представители, които се зареждат още по-дълго, но това са много удобни за потребителя системи, натоварени с ... изобилие от услуги за стартиране (по-специално хардуерния автодетектор kudzu) .
От моя чисто потребителски опит бих казал, че разликата в производителността при потребителски задачи между Linux и FreeBSD обикновено не е органолептично забележима. С две изключения, първото от които е файловите операции.
Очевидно производителността на файловите операции на всяка ОС се влияе от два фактора - осъществяването на взаимодействие с дисковата подсистема (за настолен компютър - по-специално с ATA интерфейса) и организацията на поддържаната файлова система(и). И тук FreeBSD е в неизгодно положение в сравнение с Linux.
По-горе беше споменато, че благодарение на CAM във FreeBSD (говорим за 5-ти клон) се постига универсализъм в работата с дискови контролери - останах с впечатлението, че всъщност не се интересува от кой контролер е дискът (само ако е разпознат от BIOS - но това е необходимо само за зареждане на ядрото от него.) Все пак трябва да платите за универсалност. И изглежда, че в този случай изчислението идва под формата на намаляване на скоростта на дисковите операции - въпреки че Не намерих надеждна информация по този въпрос, въз основа на общи съображения, изглежда като истина.
Това е първата страна на въпроса. Втората е файловата система FreeBSD, която е UFS и (по подразбиране в 5-ия клон) нейната подобрена надстройка UFS2. Традиционно в тази ОС и двете се използват в частично синхронен режим (ноасинхронен режим), когато промените във файловите метаданни се записват на диска незабавно, а промените в блоковете данни се кешират в RAM.
Linux приема различен модел за работа с ATA дискове: различните типове контролери имат (или нямат) собствена поддръжка в ядрото. Това изключва използването на очевидно неподдържани устройства, но за поддържаните, очевидно, осигурява по-добра производителност. Файловите системи (а Linux поддържа няколко от тях като родни) по подразбиране всички (с изключение, вероятно, JFS) се използват в напълно асинхронен режим (асинхронен режим), когато и данните, и метаданните се кешират в RAM.
В резултат на комбинацията от тези фактори, файловите операции са значително по-бързи в Linux, отколкото във FreeBSD. Всъщност винаги съм подозирал това, но това само показа колко е значително изоставането на FreeBSD 5-ти клон в това отношение - дори механизмът SoftUpdates, предназначен да увеличи надеждността и производителността на манипулациите с файлове, не спасява ситуацията. Между другото - във FreeBSD 4-ти клон преди това не е наблюдавано такова изоставане, което косвено потвърждава отрицателното въздействие на работата с дисковата подсистема (утежняване на влошаването на синхронните операции) - той не използва CAM модела (поне беше не се използва, когато съм използвал). Но в Linux с неговото изключително асинхронно използване на файлови системи, според моите наблюдения, почти няма зависимост на скоростта на работа с файлове от производителността на хардуера на диска.
Второто от обещаните изключения се отнася до суапове. Които в Linux и FreeBSD се изпълняват значително по различен начин. За да разберете какво е достатъчно да погледнете изхода на командата top и в двете операционни системи със средно потребителско натоварване. В Linux можете да видите, че при достатъчно количество RAM, процентът на използване на пространството за размяна клони към нула. Например, на моя лаптоп с Linux (512 MB памет) към момента на писане на тези редове, със зареден KDE, html редактор Quanta, konsole, две копия на konqueror и работещ mplayer (възпроизвеждащ mpeg и RealAudio), swap не се използва изобщо. На настолен компютър с FreeBSD (1 GB памет), при същото натоварване, използваната зона за размяна е по-малко от 10% почти никога не пада.
Това се дължи на факта, че Linux прибягва до размяна само когато RAM е пълна, докато във FreeBSD във всеки случай (дори и с излишък от RAM) страниците от паметта, които не са били достъпни за определен период от време, се разменят на диска. По същество RAM в тази ОС действа като вид кеш за зоната за размяна (по-точно за виртуалната памет като цяло). Което е ефективно предвид ограничения му обем и беше оправдано в старите времена, когато процесорите бяха бавни и паметта беше оскъдна. В днешно време този модел на използване на суап в някои ситуации води до забавяне на работата. Пример е KDE с голям брой настолни компютри и периодично превключване между тях, където подобно забавяне е видимо с просто око.
Всичко това води до по-висока цел (установена от тестове) и особено субективна производителност на Linux в сравнение с FreeBSD. Въпреки че трябва да подчертая отново – говорим за настолната сфера: на силно натоварен сървър, механизмът за кеширане на FreeBSD може да покаже своите силни страни, а съотношението на скоростта между тези системи може в някои случаи да се окаже точно обратното.
В самото начало на тази статия не обещах да дам еднозначен отговор на въпроса, поставен в заглавието й. По-точно, той обеща, че няма да бъде. Наистина за себе си не виждам еднозначен отговор. Но ще си позволя да направя някои очертания за него.
Това, което печели FreeBSD, е а) лекота на инсталиране, б) логическа конфигурация и в) лекота на администриране в локален мащаб. Същите функции (поне повечето от тях) обаче сега са характерни за най-добрите (според мен) съвременни представители на семейството на Linux (CRUX и Archlinux, до известна степен - Gentoo). Въпреки че по очевидни причини не е необходимо да очакваме от тях вътрешната хармония и целостта на FreeBSD в близко бъдеще.
В същото време съм наясно с архаичната природа на файловата система FreeBSD, особено ясно видима в сравнение със съвременните реализации на ReiserFS и XFS за Linux. И почти едномесечната работа на FreeBSD-десктоп и Linux-лаптоп - машини с почти еднаква номинална производителност - тоест лице в лице, ме убеждава в по-бързата производителност на последния. Но какво има по-голяма тежест за потребителя - всеки решава сам. За съжаление обаче Linux изглежда е най-добрият избор за използване на настолни компютри в момента.
Все пак бих искал да подчертая - в момента, тъй като пускането на FreeBSD 5.3 може значително да промени ситуацията. Въпреки това, каквото и да се случи, бих искал да видя бъдещето като взаимното влияние на двете операционни системи, взаимното усвояване на всички плюсове и премахване на минусите. Ето защо бих завършил моето протяжно повествование с лозунг в духа на съветските времена:
Демон с пингвин - братя завинаги!
Въведение
Стартирането на системата се разделя на два етапа, само косвено свързани един с друг – реално зареждането и инициализирането й.
Стартирането на операционната система означава стартиране на специална програма за изпълнение, която се нарича образ на системното ядро (или просто ядрото). Изображението на ядрото е почти обикновен двоичен изпълним файл. И спецификата на неговото стартиране е само във факта, че ако някакви други програми се стартират под контрола на която и да е ОС, четейки от файловата система, която тази ОС възприема като родна (родна), тогава ядрото трябва да стартира сякаш от само себе си , без никаква операционна система (защото това е операционната система) и от носител, за който системата не знае нищо (тъй като самата тя все още не е заредена). Неслучайно в английската литература има общоприета метафора за процеса на зареждане, наречена bootstrapping, която може да се преведе също толкова алегорично като „да се повдигаш за връзките на обувките си“. И въпреки че не всеки успява в това в реалния живот, в света на POSIX системите тази процедура се извършва редовно - и като правило успешно.
Изображението на ядрото съдържа всичко необходимо за чисто стартиране. Въпреки това, той може да бъде изпълнен по този начин само от носител без файлова система. И следователно директното стартиране на ядрото, доколкото знам, се използва само при зареждане от флопи диск. При обичайното стартиране на ОС от твърдия диск в този бизнес участва и известна външна сила - специална програма, наречена bootloader. Той зарежда ядрото на системата, отговаря за откриване на хардуер, зареждане на обектни модули (зареждаеми модули на ядрото) и монтиране на основната файлова система (само за четене). Междувременно ядрото стартира системни (т.е. не свързани с изпълними файлове) процеси, които управляват виртуална памет, буфери, страници с памет и т.н., до суапера, а след завършване - своя собствен и първия "нормален" ( който е свързан с изпълнимия файл на диска) init процес (/ sbin / init).
След това системата за иницииране влиза в игра. Неговата роля е да осигури, чрез съответните скриптове за стартиране (те също са скриптове за инициализация), монтиране на файлови системи (и повторно монтиране на root в режим "четене/запис"), стартиране на основни системни услуги или демони, извикване на команди за получаване на терминал (getty процеси) и оторизация на потребителя (вход). Краят на стартирането на системата се отбелязва с покана за оторизация.
Визуално етапите на зареждане и инициализация се различават по един или друг начин визуално представяне на показваните съобщения. В DragonFlyBSD, например, съобщенията за напредъка на стартиране се показват в радикално бели знаци, които се заменят по време на фазата на инициализация с обичайното заглушено бяло.
Зареждането и инициализацията е първото нещо, което потребителят вижда във всяка ОС. Вярно е, че потребителят на POSIX-съвместима система получава такова удоволствие много по-рядко от "перваза на прозореца". Нормалната работа на домашна Unix машина е да я включите рано сутрин и да я изключите късно вечерта. (Вярно е, че всеки има свои собствени представи за „ранно“ и „късно“). И служебната Unix машина изобщо не трябва да се изключва завинаги - до пълна физическа амортизация. Е, необходимостта от рестартиране на системата, докато работите в Linux или BSD, е изключително рядка. Всъщност, само след повторно изграждане и преинсталиране на ново ядро (или преместване на основния дял - но това обикновено е изключителен случай) - във всички останали случаи на преконфигуриране на системата можете да направите без него.
И така, изглежда, какво го интересува потребителя как стартира системата и колко време отнема? Необходими са обаче някои стъпки за настройка на двата етапа на този процес. Тъй като при стартиране на системата се показва не само начален екран и евентуално меню с опции за зареждане, но също така се зареждат модули на ядрото, съответстващи на наличния хардуер, монтират се файлови системи, стартират се скриптове за инициализация, виртуални терминали се отворени и така нататък и така нататък. Разбира се, от всички тези действия, разбира се, само действителното зареждане на ядрото е абсолютно задължително - останалото може да се извърши по-късно. Не би ли обаче било по-добре да конфигурирате системата така, че веднага след края на процедурата по стартиране да получите напълно готова за използване система, вместо по-късно да я привеждате ръчно в това състояние?
Освен това разбирането на напредъка на зареждането и инициализацията няма да е излишно, ако ръчно се намесите в този процес. И необходимостта от такава намеса - уви - от време на време възниква при спешни ситуации ...
Така че нека проследим основните етапи на зареждане и инициализиране на DragonFly и да видим какво трябва да конфигурират, както и къде и как (и най-важното – защо) могат да бъдат намесени.
Относно зареждането и зареждащите устройства
Разумно е да започнем да изучаваме старта на системата от първия й етап - а именно действителното натоварване. Както вече споменахме, тези етапи се контролират от специална програма, която на руски се нарича bootloader. въпреки че на английски се използват два термина за него - loader и boot manager (което, както ще видим с времето, са малко различни неща, но сега това не е важно).
Всъщност всеки зареждащ модул включва две или дори три относително независими части - дори ако се разпространява като един пакет като Lilo или GRUB. За да се убедим в това, нека си представим как машината се стартира на "желязо", така да се каже, ниво (което означава - съвместима с Intel персонална машина, на други архитектури всичко е малко по-различно).
На първо място, след включване на захранването се стартира програма, която се флашва в ROM (BIOS) на компютъра. Той проверява хардуера, след което намира носителя, инсталиран в BIOS Setup като първо устройство за зареждане (по-конкретно, твърдия диск), върху него е първият физически блок, съдържащ така наречения Master Boot Record (MBR).
Съдържанието на MBR е, първо, таблица с дискови дялове, четирите, в един от които преди това инсталирахме DragonFly. И второ – някакъв код, който поема контрола от BIOS в края на работата си. В стандартния MBR - тоест, който е написан на "прясно прецакан" твърд диск или се възстановява след DOS-командата FDISK / mbr - този код може да намери само първия физически дял на диска (основен дял) и контрол на трансфера към неговия зареждащ сектор. Което е напълно достатъчно, за да стартирате операционни системи като DOS или Windows 9X / ME от първия (или единствения) дял. Но очевидно не е достатъчно във всеки друг случай - например, ако на диска са инсталирани няколко операционни системи, които, разбира се, не могат да се поберат в един дял.
Следователно всеки буутлоудър трябва да включва програма, написана в MBR. Тъй като обемът на последния е само 512 Kbytes (размерът на физически дисков блок), някои от които вече са заети от таблицата на дяловете, тази програма не може да побере особено богати функции. Обикновено той е в състояние да идентифицира всички използвани първични дялове, да ги изброи и да позволи на потребителя да избере дял за зареждане и след това да прехвърли контрола към сектора за зареждане на избрания дял.
Подобно на MBR, секторът за зареждане на дяла (Записът за стартиране вече не е главен!) Съдържа информация за неговото разделяне (Етикет на диска), в зависимост от схемата, използвана в тази ОС, и контролния код, който поема от програмата, записана в MBR. И този код е втората част на буутлоудъра. Вярно е, че неговите възможности също не могат да бъдат богати - в края на краищата размерът на сектора за зареждане на дяла е същите 512 KB. И следователно има само една функция - да прехвърли контрола към програма, която се намира извън сектора за зареждане. Което всъщност трябва да идентифицира основния дял на ОС и файловата система, която носи, и след това, пряко или косвено, да зареди ядрото му.
Лесно е да се досетите, че първите два компонента на буутлоудъра всъщност нямат нищо общо с никоя операционна система и изобщо не са част от файловата система. Но с третото - варианти са възможни. Може да бъде включен във файловата йерархия на стартиращата ОС, като Lilo, или може да бъде нещо като независима мини-ОС, като GRUB (не случайно е силно препоръчително да се инсталира на собствен дисков дял, който не се монтира по подразбиране в корена на никоя от операционните системи, които зарежда). А какво ще кажете за устройството за зареждане на нашата героиня - DragonFlyBSD?
Етапи на зареждане
В тази ОС се използва програма за зареждане на системата, която е обща за всички операционни системи BSD. Той има собствено име, а името, колкото и да е странно, е BSD Loader (въпреки че, както ще стане ясно малко по-късно, това е донякъде произволно).
Трябва да се разкая - за няколко години общуване с FreeBSD и от време на време запознанства с неговите сестри (OpenBSD и дори NetBSD), някак си нямах причина да се занимавам с устройството на техния буутлоудър. Е, зарежда родната система перфектно - и страхотно (например FreeBSD). Зарежда и други BSD системи - още по-добре. Това, че Linux може да се стартира без стрес, като цяло е толкова страхотно. И това, което също може да зареди Windows, е просто безплатно приложение ...
Тъй като щях да съм в щастливо невежество, ако по някакъв начин, във връзка с инсталирането на FreeBSD на лаптоп на Toshiba, не трябваше да ровя малко с опциите на BSD Loader. И тогава се оказа, че това е програма с мощни интерактивни възможности и дори с възможност за персонализиране. Не да се сравнявам с GRUB, разбира се, но ако не експериментирате с множество операционни системи на много твърди дискове, функциите за зареждане са повече от достатъчни. Това, което ще се опитам да демонстрирам по-долу, използвайки примера на DragonFlyBSD OS. Въпреки това, почти всичко казано е вярно за всички други BSD системи (и за FreeBSD - и без клаузата "почти").
Основната характеристика на зареждането на DragonFly (въпреки че почти всичко казано е валидно за всички други BSD системи - и за FreeBSD и без уговорката "почти"), което го отличава от Lilo и в по-малка степен GRUB, е, че не прикрива многокомпонентната си природа, включително четири (почти) независими програми.
Първата част на bootloader (т.нар. boot0) е програма, написана по време на инсталацията на системата към сектора за зареждане на диска, от който се зарежда машината според настройките на BIOS. Обикновено това е Master на първия IDE канал (тук няма да говорим за SCSI дискове), но са възможни опции (например, ако имате хардуерен ATA RAID или допълнителни ATA контролери). Тази програма отговаря за първия етап от етапа на зареждане, който чете таблицата на първичните дискови дялове, показва списък с тях (ако има повече от един дял), определен период на изчакване, който потребителят може да избере (по подразбиране, дялът, избран в предишната сесия, ще бъде стартиращ) и след това (или след фиксиран период на изчакване), прехвърляйки контрола към кода, написан в сектора за стартиране на избрания (или по подразбиране) дял. Секцията се избира чрез натискане на клавишите F1—F4). Ако има два диска, натиснете F5той просто ще прехвърли контрола към сектора за зареждане на втория от тях - и там събитията ще протичат в зависимост от това какво е написано в него: самият boot0 не е в състояние да чете дялове на втория физически диск.
Списъкът с дялове, от които да избирате, включва техните имена според идентификаторите на типа файлова система, например:
F1 DOS F2 Linux F3 BSD F5 устройство 1
Доскоро BSD Loader не можеше нито да разпознае логически дялове в Extended DOS, нито да зареди операционна система от тях. Сега обаче ситуацията, очевидно, се е променила: това може да се заключи от съобщенията за възможността за инсталиране на DragonFlyBSD в разширения раздел (единственият, доколкото знам, от BSD системите, способен на това). Възможно ли е да си представим инсталирането на системата без възможност за зареждане със стандартни средства?
По принцип наличието на първата част на зареждащия BSD зареждащ е по избор: той може да бъде заменен от зареждащия зареждане на Linux (същият Lilo, който прехвърля контрола към сектора за зареждане на BSD slice "по верига") или мулти- система GRUB, която директно може да работи с файлови системи и да зарежда ядра на различни операционни системи.
Втората част (boot1) се намира в сектора за зареждане на първичния дял, носещ BSD системата (BSD slice). Тоест и boot0, и boot1 лежат не само извън файловата система, но всъщност извън самия BSD срез. Третата част (boot2) вече лежи вътре в среза, но не е включена в нито един от неговите логически дялове.
Втората и третата част на буутлоудъра са по същество една програма, разделена само поради ограничението на размера на сектора за зареждане на дяла (512 байта). Така че задачата boot1 включва само идентифициране на BSD среза, намиране на boot2 в него и прехвърляне на контрол към него. И той трябва, след като изчака известно време, да идентифицира основната файлова система, да намери в нея и да стартира двоичния изпълним файл - /boot/loader, който формира четвъртата част на зареждача; строго погледнато термина BSD зарежданесе отнася само за тази програма.
По този начин можете да видите, че първите три части на BSD bootloader (boot0, boot1 и boot2) лежат извън файловите системи на инсталираната BSD OS. В който получаваме само като се започне от стартирането на loader, обикновен изпълним файл, поставен в специална директория / зареждане на основната файлова система.
Вярно е, че в директорията / boot (това е местоположението по подразбиране на зареждането), заедно с неговия изпълним файл, можете да видите и файлове с имена boot0, boot1 и boot2. Но те са просто копия на съответния код, разположен (и изпълняван) извън файловата система BSD. Тяхната цел е да възстановят стартирането след извънредни ситуации.
Задачата на товарача е бързо да зареди ядрото и набор от модули по подразбиране, след което показва менюто си с логото на проекта, на което можете да разпознаете водно конче (заменяйки дявола с вила от FreeBSD). Менюто съдържа следните елементи:
- Обувка DragonFly- нормално зареждане на ядрото с всички пуснати (от кого и къде пуснати - говори напред) модули, монтиране на файлови системи и изработване на предписаните стартови скриптове;
- Стартирайте DragonFly с деактивиран ACPI- същото нещо, само с изключени acpi модули, което понякога може да се изисква на някои лаптопи;
- Стартирайте DragonFly в безопасен режим- зареждане в безопасен режим, тоест без свързващи модули;
- Стартирайте DragonFly в режим на един потребител- зареждане в режим на един потребител, в който се монтира само основната файлова система (и дори тогава само за четене), а етапът на инициализация се игнорира;
- Стартирайте DragonFly с подробен запис- нормално изтегляне, но с извеждане на подробни съобщения;
- Избягайте към подканата за зареждане- изход към командния ред на bootloader;
- Рестартирайте- Е, ние знаем това като три пръста, само че още по-добре.
Ако не направите никакъв избор, опцията по подразбиране ще започне да се зарежда след десет секунди. За да предотвратите това (и да получите повече време за размисъл), просто натиснете Интервал- обратното броене ще спре и няма да има изтегляне до изричен избор.
След избора или изтичането на срока на ограничение започва доста продължителен процес на идентифициране на хардуера, по време на който множество съобщения на ядрото се показват на екрана - за разлика от нормалните съобщения - в ярко бял "цвят" на символи. Тези съобщения са много интересни, но не са лесни за четене. Което обаче не е страшно – в бъдеще те могат да се разглеждат с командата dmesg. След това се монтира основната файлова система и от нея (с обичайния изпълним файл / sbin / init) се стартира процесът на инициализиране, изпълняват се стартиращите скриптове. В памет на това яркият бял цвят на съобщенията на ядрото се променя в обичайния сивкав - фазата на зареждане, която ни интересува в момента, приключи.
Интерактивно управление на процеса на зареждане
Възниква въпросът - може ли потребителят да повлияе на процеса на изтегляне? Отговорът ще бъде да. По време на работата на системата за зареждане на потребителя се дава свобода на избор три пъти: избор на дял за зареждане в началния етап на boot0, избор на интерактивен контрол на етап boot2 и избор на режим на зареждане веднага след стартиране на зареждането. И във всички тези случаи потребителят може да се намеси в процеса с ръцете си. За какво? Това е друг въпрос и отговорът на него, надявам се, ще стане ясен от последващото представяне.
С избора на раздела за зареждане всичко е ясно: той ви позволява да стартирате една от ОС, ако няколко от тях са инсталирани на дадена машина. Но на етапа на работа на boot2 можете да прекъснете изпълнението му или по-скоро да избегнете стартирането на зареждане. За да направите това, в паузата между избора на зареждане от BSD дяла и появата на съобщения за зареждане на ядрото и модулите (тази пауза е маркирана с появата на мигащ символ _ на екрана), натиснете произволен клавиш. В отговор ще последва подкана за формуляра:
>> BSD / i386 BOOT По подразбиране: 0: ad (0, a) / boot / loader boot:
И в реда за подкана можете да посочите опция за зареждане, различна от тази по подразбиране. Например, можете да заредите директно файла с изображение на системното ядро. Това може да има някакъв смисъл след повторното изграждане на ядрото - ако новото не е конфигурирано достатъчно правилно за зареждане (но - уви - достатъчно за компилиране).
За да направите това, трябва да построите пътя към старото ядро в изображението и подобието на версията по подразбиране. Тоест посочете:
- номера на диска в колата в съответствие с това, което BIOS разбира (0 - първият от парите, 1 - вторият и т.н., независимо от реда на свързване);
- неговият интерфейс - в примерната реклама символизира ATA диск (за SCSI диск би било da, за флопи диск би било fd);
- Номер на IDE канал (0 - главен, 1 - подчинен);
- дял в смисъла, използван от BSD етикета, тоест част от срез, запазен за основната файлова система на BSD (a;
- старото име на файла с изображение на ядрото е /kernel.old.
Ако на диска има няколко основни дяла от различни типове, тогава дяловете, различни от BSD, ще бъдат пропуснати и буква a (очевидно изображението на ядрото може да се намира само в основната файлова система) ще се отнася до първия подраздел на парче с ID 165 (дори той да е четвъртият).
Ако имате съмнения относно точното име на файла (а може да има няколко от тях - преди да инсталирате всяко ново нетествано ядро, се препоръчва да направите копие на предишното, очевидно работещо), можете да въведете въпросителен знак в подканата , отговорът на който ще бъде списък с основната директория (но не по-дълбоко - преглед на поддиректориите със съдържание, дори в същата файлова система, ще се провали при boot2).
Въпреки това, същата процедура - зареждане на старото ядро - може (и трябва да бъде, тъй като е много по-лесно) да се извърши чрез зареждането и сега преминаваме към разглеждането на неговите интерактивни възможности.
Менюто за зареждане предлага достатъчен избор от режими за стандартни ситуации, но явно не обхваща всички нестандартни (затова са и такива). По-специално, опцията за зареждане на старото ядро не е предоставена в менюто. За щастие, предпоследният елемент от менюто решава този проблем (и много други заедно с него).
И така, избирайки шестия елемент от менюто - Избягайте към подканата за зареждане, - попадаме в средата на командния интерпретатор loader 'a. Той има интерфейс, подобен на черупка - командите с техните опции и аргументи се въвеждат след подкана, която изглежда като
От гледна точка на удобството на интерактивната работа - не GRUB, разбира се: нито автоматичното довършване, нито историята на командите, възможностите за редактиране са ограничени от ключа Backspace... Но с основната си роля - въвеждане и изпълнение на вградени команди - товарачът се справя доста добре.
Освен това има доста от тези команди: пълен списък от тях може да бъде получен чрез въвеждане на въпросителна в командния ред. Налична е и помощ - командата help ще даде кратък намек, help command_name - по-подробна информация за използването на командата-аргумент. Синтаксисът на командите обаче също е подобен на обвивка, така че не би трябвало да има проблеми с това.
Вградените команди за зареждане могат да бъдат разделени на три части според предназначението им:
- за получаване на информация;
- да конфигурирате буутлоудъра;
- всъщност да контролира процеса на зареждане.
От първата група команди отбележете следното: ls, lsdev, lsmod, show и др. Първият е предназначен за преглед на основната файлова система и нейните поддиректории, но само тези, които не са в отделни подсекции. Но тъй като всички файлове, необходими за зареждане, се намират в поддиректориите на самия корен (в /boot, /dev, / modules), това ограничение не е значително. Командната опция ls -l изброява файлове (и директории) с техния размер - без тази опция директориите са маркирани само с d.
Командата lsdev изброява дисковите устройства на машината, техните първични дялове и подключове (последните са само за дялове, етикетирани според правилата на BSD Label). Опцията -v осигурява подробен изход.
Командата lsmod показва модулите, заредени от зареждането, преди да се появи менюто (или командния ред). Както и в предишния случай, има опция за многословност - -v.
Командата show изпълнява подобна функция, но за променливи за зареждане. Даден без аргумент, той отпечатва стойностите за всички дефинирани променливи. Ако посочите името на променлива като аргумент, тогава ще се показва само нейната стойност. Разрешени са множество аргументи, разделени с точка и запетая.
Е, more прави същото като съименника на помощната програма Unix. Позволява ви да преглеждате съдържанието на текстов файл - тоест, като сме в обвивката за зареждане, можем да се запознаем с конфигурациите, които са важни за зареждане (и всякакви други).
Конфигурационните команди ви позволяват да дефинирате или премахвате променливи на зареждащия механизъм, да зареждате или премахвате модули на ядрото. Както вече споменахме, самото ядро с определен предварително дефиниран набор от модули и променливи се зарежда преди менюто за зареждане и неговия команден интерпретатор. Така че, с помощта на съответните команди, тези предварително дефинирани набори могат да бъдат леко коригирани (или напълно променени). Това може да е необходимо, ако конфигурацията на ядрото по подразбиране не е заредена по някаква причина (често срещан случай е конфликт между енергоспестяващи системи на лаптоп и системни модули ACPI), за целите на отстраняване на грешки или просто за задоволяване на любопитството за.
Нека първо разгледаме командите за управление на модули. Това е двойка команди за зареждане и разтоварване за съответно зареждане и премахване на модули. Първият се използва с аргумента module_name, който, ако е необходимо, може да бъде шпиониран (с помощта на ls) в директорията / modules - името в аргумента се дава без суфикса * .ko. Командата unload със същия аргумент ще премахне посочения модул, без аргументи - тя ще премахне всички модули като цяло, което ви позволява да започнете от нулата в конфигурацията.
Командите за зареждане и разтоварване се отнасят и за ядрото като цяло. И така, чрез командата
ОК разтоварете ядрото
можете да разтоварите ядрото по подразбиране от паметта (например, ако се окаже, че не работи) и с помощта на командата
Добре заредете kernel.old
заредете старото работещо ядро.
Двойка подобни цели - set и unset - също съществува за променливите на средата за зареждане. Тези променливи се използват за промяна на текущото дисково устройство, за определяне на местоположението на основната файлова система, за дефиниране на пътища до модули на ядрото, различни от модулите по подразбиране / и други подобни. Това се прави с командата set в съответствие със синтаксиса на C-shell, например:
OK set currdev = "disk1s1a"
Указва текущото дисково устройство по отношение на "диск # _срез # _секция".
За една променлива са разрешени няколко стойности - те са разделени с точка и запетая. Например,
OK set module_path = "/; / modules; mymodule_path"
дефинира местоположението на модулите на ядрото - корен, директорията на модулите по подразбиране и директорията / mymodule_path: очевидно е, че ако просто дефинирате пътя към вашите собствени модули в тази променлива, информацията за местоположението на модулите по подразбиране ще бъде загубена . Обръщам вниманието ви към наличието на стойността / в дефиницията на променливата - този път е необходим за зареждане на ядрото с помощта на командата load (в DragonFlyBSD ядрото е инсталирано по подразбиране в основната директория).
Някои променливи просто разрешават или деактивират някои действия и съответно техните булеви стойности - ДА или НЕ. Естествено, те се нуждаят от детайлни променливи, за да дефинират какво им е позволено. Например променливата
OK set userconfig_script_load = "ДА"
позволява само изпълнение на персонализирани конфигурационни скриптове и променливата
OK set userconfig_script_name = "/ boot / my.conf"
определя кой сценарий трябва да се приложи в този случай.
Използвайки променливи, можете също да дефинирате режими на зареждане. Например след задаване на променливата
OK задайте boot_single
Дефиницията на променлива може да бъде отменена с командата
Незададено име на променлива
В някои случаи неговият еквивалент би бил да се дефинира променлива с булева стойност NO или думата disable в името.
Пълен списък на вградените променливи на средата на буутлоудъра може да бъде намерен в съответната страница на ръководството:
$ man 8 товарач
И накрая, командите за управление на изтеглянето. Най-важният от тях е boot, който, без опции и аргументи, кара ядрото да се стартира незабавно в неговата конфигурация по подразбиране или текуща (тоест с отменени променливи и модули). / p>
Опциите на командата за стартиране определят режима на зареждане. Например командата
OK boot -s
ще предизвика зареждане в режим на един потребител. Това е еквивалентно на изпълнение на същата команда без опции, като преди това сте задали променливата boot_single.
Аргументите на командата за зареждане могат да определят името на изображението на ядрото, изпълнимия скрипт за зареждане и т.н. Същият пример за тайнство: заповедта
Добре стартирайте kernel.old
ще зареди старото ядро, подобно на командата за зареждане без опции, след като двойката се изпълни
OK разтовари ядрото OK зареди kernel.old
Все пак първият отбор от тази двойка пак няма да навреди - за да се избегне... Особено ако новото ядро се е събрало доста криво.
Тук не са описани всички функции на интерактивния режим на BSD loader - само тези, които случайно използвах. По-подробна информация може да бъде намерена не само в man (8) loader, но и чрез директно четене на помощния файл:
$ по-малко /boot/loader.help
И изобщо не е необходимо в процеса на управление на изтеглянето - по-добре е да го направите предварително.
Конфигуриране на буутлоудъра
Потребител, който е успял да усети духа на Unix Way (или поне го е усетил), има право да попита: ако процесът на зареждане може да се намеси интерактивно, възможно ли е да се коригират параметрите, определени на ръка, веднъж завинаги? И отговорът му ще бъде: е, разбира се, че можете.
Интуитивно е ясно, че тъй като намесата на потребителя е възможна на първия (boot0) и последния (loader) етап на зареждането, те са тези, които могат да бъдат персонализирани. И така се оказва.
Вярно е, че на първия етап от изтеглянето не можете да конфигурирате толкова много, а именно:
- променете времето за изчакване за избор на раздел (по подразбиране е равно на странна цифра от 18,2 секунди - това казва документацията);
- фиксирайте един от дяловете като стартиращ по подразбиране - без това, както вече споменахме, по подразбиране е дялът, избран при предишното стартиране на машината;
- още някои малки неща, които нямат практическо значение.
Командата boot0cfg служи за тези цели. Струва си да се помни само, че използването му е свързано с промяна в главния запис за зареждане (MBR), чието унищожаване прави невъзможно стартирането на машината от диск. Вероятността за прецакване на MBR с тази команда е изключително малка и няма тежки последици. Въпреки това (Бог пази тези, за които се грижи) - по-добре е да държите инсталационния диск на DFBSD под ръка. Не за преинсталиране на системата, разбира се, а за възстановяване на записа за зареждане - това е голяма спасителна дискета. А как – ще бъде тема на следващата статия от цикъла.
Така че можете да промените времето за изчакване, като използвате опцията -t #, където # е стойността в секунди (нулева стойност не е разрешена). Използвайки опцията -s #, един конкретен дисков дял се прави стартиращ по подразбиране завинаги (а не този, от който е стартиран при последното включване на машината). Очевидно стойностите 1-4 са приемливи тук (според броя на възможните първични дялове) плюс 5 - прехвърляне на контрола към MBR на втория диск. А опцията -v ще ни даде по-подробна информация за резултатите от извършената операция. И, разбира се, е необходим аргумент - името на дисковото устройство, чийто MBR променяме. Тоест командата
$ boot0cfg -t 30 -s 2 -v -f /boot/boot0.old ad0
променя MBR на първия IDE диск (ad0 аргумент), така че вторият му срез ще стане зареждане по подразбиране, времето за избор на дял ще се увеличи до 30 секунди и ще докладва резултатите от работата си под формата на нещо като следното:
# флаг начало chs тип край chs размер на изместване 1 0x00 0: 1: 1 0x83 850: 254: 63 63 13671252 2 0x80 851: 0: 1 0xa5 261: 254: 254: 713 15 версия = 713 x 15 x 0 x 30 опции = пакет, noupdate, nosetdrv default_selection = F2 (срез 2)
О, да, опцията -f ще създаде копие на текущия запис за стартиране в директорията / boot; вярно, файлът / boot / boot0 е копие на MBR на прясно инсталирана система, но - за застраховка, още един двоен няма да навреди.
Нека обърнем внимание на опцията noupdate в крайния изход на командата: именно тази опция фиксира един от срезовете като зареден по подразбиране. Ако не ви харесва тази позиция по някаква причина, лесно е да я промените, като повторите командата в тази форма:
$ $ boot0cfg -o актуализиране на ad0
Е, значението на други опции (и други начини за използване на командата) може да се изясни с леля Мани: man (8) boot0cfg.
Така че трябва да настроим самия товарач. Веднъж споменах, че преди да се появи менюто и възможността за превключване в интерактивен режим, ядрото вече успява да се зареди с определен набор от параметри и обещах да каже къде и от кого са поставени тези параметри. Време е да изпълните обещанието си.
И така, параметрите за зареждане на ядрото се задават от скрипта за инициализиране на зареждащото устройство - /boot/loader.rc. Всъщност това е един вид пакетен файл, от който се извикват няколко отделни скрипта, но за нас сега това не е от съществено значение. И важното е, че променливите на средата по подразбиране на зареждача и техните стойности са зададени в сдвоения конфигурационен скрипт - файла /boot/defaults/loader.conf. Той описва пътищата за търсене на модули, името на ядрото по подразбиране, текущото дисково устройство и основната файлова система, както и забавянето преди зареждане - всичко това може да бъде определено като променливи на средата интерактивно. Той също така съдържа списък с всички видове модули на ядрото (най-общо казано, всичко възможно) и показва дали те трябва да се зареждат автоматично при стартиране или не.
Сам по себе си /boot/defaults/loader.conf не е предназначен за редактиране, а само показва всички възможни параметри за зареждане и коригира техните стойности по подразбиране. И следователно действителната цел на конфигурирането на зареждача не е той, а файлът /boot/loader.conf.
Въпреки това, веднага след инсталирането на системата, няма да видим такъв файл в системата. Трябва да го създадете сами, да прехвърлите необходимите опции от файла /boot/default/loader.conf и съответно да промените стойностите им.
При настройката на която и да е система обикновено е по-лесно да се покаже как се прави, отколкото да се разкаже за нея. И затова ще дам моя /boot/loader.conf като пример с някои коментари. Аз съм прост човек, не склонен към ексцесии и затова този файл е много малък за мен.
Autoboot_delay = "5" # Време за изчакване преди автоматично зареждане beastie_disable = "YES" # Отмяна на дисплея на менюто за зареждане usb_load = "YES" # Зареждане на модула за поддръжка на USB шина ugen_load = "YES" # Зареждане на поддръжка на USB устройство като цяло ums_load = "ДА " # Зареждане на поддръжка на USB мишка # Тези редове са необходими, ако съответните функции # не са твърдо кодирани snd_pcm_load = "YES" # Заредете модула за поддръжка на звук snd_ich_load = "YES" # Заредете модула на звуковото устройство # В примера - аудио чипсет от Intel ICH #
Освен това тук можете да активирате зареждането на модула за скрийнсейвър като цяло и след това на конкретен модул (съответните файлове се намират в директорията / modules и имат формата * _saver.ko):
Vesa_load = "ДА" screensave_load = "ДА" screensave_name = "fire_saver"
Освен това можете да качите свое собствено изпръскващо изображение (създаването на което във формат * .bmp или * .pcx и поставянето му в директорията / boot трябва да се погрижите предварително):
Splash_bmp_load = "ДА" bitmap_load = "ДА" bitmap_name = "filename.bmp"
Нека обърнем внимание на реда vesa_load, който зарежда модула за поддръжка на едноименния режим в конзолата: необходим е за някои графични скрийнсейвъри (например "пламъка", показан в примера) и за разбира се, изпръскване на изображения. Въпреки това, поддръжката на VESA може да бъде вградена в ядрото (виж цикъла).
Даденият пример не изчерпва възможностите за преконфигуриране на буутлоудъра - можете да намерите други възможности, като погледнете файла /boot/defaults/loader.conf. Просто трябва да имате предвид, че някои функции, предоставени от зареждащи се модули, може вече да са компилирани в ядрото - по подразбиране или компилирани със собствените ви ръце - и не е необходимо да ги дублирате. Така че е добра идея да проверите текущата си конфигурация на ядрото, преди да редактирате /boot/loader.rc. За прясно инсталирана система е описано във файла / usr / src / sys / i386 / conf / GENERIC, а за самостоятелно сглобена ... обаче, ако вече сте компилирали ядрото, тогава знаете по-добре от ми името на неговия конфигурационен файл и какво пише в него.
Нека само да кажа няколко думи за модулите за поддръжка на файловата система. Очевидно няма смисъл да се създава поддръжка за тези от тях, които се използват само от време на време (като msdos) в ядрото: в този случай за всички тях (включително ext2fs), зареждаемите модули ще бъдат компилирани по подразбиране при компилиране на ядрото. Въпреки това, няма нужда да зареждате тези модули при стартиране (въпреки че има съответни редове във файла /boot/Defaults). При достъп до устройство с чужда файлова система, необходимият модул ще се зареди автоматично. Същото важи и за поддържащи модули за устройства като дискове в RAM (md - Memory Disk), освен ако, разбира се, системата не трябва да стартира от тях.
Но това не се случва със звуковите устройства. И следователно, ако е мързеливо да зареждате съответните модули всеки път, преди да слушате музика (гледайки напред, отбелязвам, че това се прави с командата kldload module_name), тогава е по-добре да ги предпишете автоматично да се зареждат при стартиране на системата, както е направено в примера.
Лесно е да намерите модулите, от които се нуждаете – те съдържат компонента snd в името си. Тоест, можете да прибягвате до команда като
$ ls / модули | grep snd
и изберете съответните реалности от изходния списък. В същото време, за много някога широко разпространени звукови карти на PCI шината, модулът snd_pcm е достатъчен.
В примера по-горе зареждането на менюта е отменено. Това меню е описано във файла /boot/beastie.4th, използването на който е предписано във файла /boot/loader.rc от реда
Включете /boot/beastie.4th
Разбира се, това не е необходимо. Като алтернатива можете да преработите /boot/beastie.4th, така че отделните елементи от менюто да съответстват на техните собствени опции за зареждане - например с различни набори от плъгини, за които ще трябва да създадете няколко алтернативни конфигурационни файла за зареждането. Или - изображения на ядрото, компилирани с различни опции. И ако знаете как да бродирате (съжалявам, рисувайте с ASCII символи), тогава можете да замените водното конче, украсяващо менюто, с нещо свое.
Задачи за инициализация
Да предположим обаче, че по един или друг начин зареждането на ядрото и цялата съпътстваща го икономика е приключило успешно. Тук се намесва основният калибър на всяка POSIX система - процесът на инициализиране. Това е първият (буквално и преносен смисъл - в BSD системите неговият идентификатор е равен на един) потребителски (тоест работещ в потребителско пространство на ядрото, потребителска земя), процес и се стартира чрез изпълнение на едноименния файл /sbin/ в него.
В действителност това могат да бъдат (и наистина има в различни системи) много различни програми. Освен това, той може да бъде отменен чрез интерактивно контролиране на процеса на зареждане с друга програма, като командна обвивка. Това обаче не е много важно сега - ще разгледаме само редовните задачи на програмата / sbin / init.
Първата от тези задачи, както по време на изпълнение, така и по стойност, е да се провери целостта на наличните файлови системи. За да направите това, всеки от тях се проверява за наличието на бит "чист байт", който се задава автоматично по време на правилното прекратяване на предишната сесия. Ако се намери такъв бит на всяка файлова система - всичко е наред, нещата продължават. Ако не, са възможни опции, които ще бъдат обсъдени в следващата статия.
Трябва да се отбележи, че "чистият бит за демонтиране" сам по себе си не гарантира безопасността на файловата система и особено на нейните данни. Показва само, че файловата система е била правилно демонтирана в предишната сесия. В този случай init прави разумно предположение, че метаданните и данните са наред, и преминава към следващата задача.
И следващата задача на процеса init е да извика и изпълни init скриптове, или скриптове за стартиране, събрани в директорията / etc и (или) нейните поддиректории. Това са обикновени шел скриптове, предназначени да се изпълняват от стандартна POSIX обвивка и включват командни последователности за монтиране на файлови системи, активиране на зоната за размяна, настройка на системния часовник и стартиране на определени услуги и демони.
Командите, които формират стартиращите скриптове, получават своите опции, техните стойности и аргументи от специални конфигурационни файлове, които също имат своето местоположение в / etc и неговите поддиректории. Конфигурационните файлове (или просто конфигурации) са или прости бази данни с опции и аргументи на команди, или списъци с имена на променливи (съответстващи на опциите на командите, използвани в скриптове) със стойности, присвоени към тях. Конфигурациите от скриптове се разграничават лесно, когато се гледа в директорията / etc по отсъствието на първите битове за изпълнение.
И накрая, третата незаменима задача на процеса init - така нареченото получаване на терминала (стартиране на getty процеса), настройка на неговите свойства и подготовка за оторизация - се замества от процеса на влизане. Изпълнението на тази процедура също се определя от параметрите от съответния конфигурационен файл.
Последователното разделяне на стартиращи скриптове и техните конфигурационни файлове е един от крайъгълните камъни на конфигурацията в цялата система. Всъщност, по време на нормалния ход на настройката, потребителят практически не трябва нито да се запознава със съдържанието на скриптовете (въпреки че това не е вредно), нито дори по-малко да променя нещо в тях (последното е разрешено само ако самият този потребител знае със сигурност кой знае, в противен случай системата може лесно да бъде доведена до неработещо състояние). Но не само е възможно, но и необходимо да се правят промени в стойностите на параметрите на конфигурационните файлове - разбира се, такова разрешение не освобождава потребителя от разбирането на значението на техните действия.
Разбирането на това обаче е затруднено от факта, че и скриптовете за инициализиране, и техните конфигурационни файлове се изпълняват много различно в различните операционни системи и техните дистрибуции. Това разнообразие обаче може да се сведе до два стила - BSD, всички вариации по темата на които са много сходни помежду си, и System V, всеки представител на който е оригинален по свой начин. Първият стил на иницииране се използва в операционните системи на едноименното семейство. Стилът System V преобладава в повечето разпространени Linux дистрибуции. Въпреки че напоследък много от тях (CRUX, Archlinux, Gentoo) все повече използват схеми за иницииране, подобни на BSD.
Инициализира се DragonFly
В DragonFly зареждането в стил BSD се приема както трябва да бъде за представител на семейството BSD. Основната му разлика от стила на System V е отсъствието на концепцията за нива на изпълнение (което често се превежда неточно като нива на натоварванеили дори нива на задействане). Вместо това има концепцията за режими на зареждане, от които има само два - еднопотребителски и многопотребителски.
В режим на един потребител зареждането се извършва а), когато изберете подходящия елемент ( Стартирайте в режим на един потребител) в менюто на bootloader, b) когато зададете командата boot -s в командния ред на bootloader (след избиране на нейния елемент от менюто Избягайте към подканата за зареждане), и в) ако се открият сериозни (невъзстановими автоматично) нарушения на целостта на файловата система по време на нейната проверка на първия етап на инициализация).
Когато се зарежда в режим на един потребител, състоянието след изпълнение на зареждача действително се запазва. Тоест, няма монтиране на файлови системи (с изключение на root, от който ядрото е било заредено преди това - и дори това е било монтирано в режим само за четене), няма скриптове за иницииране, няма активиране на виртуални терминали, няма покана за оторизиране на потребители. Само първата, системна, конзола се активира с автоматична, по подразбиране, без парола, регистрация на суперпотребител на нея.
Очевидно е, че нормалната работа в режим на един потребител е невъзможна - тя е предназначена за операции по спешно възстановяване след повреди и някои системни манипулации. За ежедневни действия е предназначен нормалният мултиплейър режим.
При зареждане в многопотребителски режим (и то се извършва по подразбиране, когато машината е включена или рестартирана), всички етапи на иницииране са завършени напълно: след проверката се монтират файловите системи, предназначени за това (и root на файловата система се поправя в режим на четене/запис), някои стартови скриптове (ще видим къде и от кого - ще видим скоро) и всички предварително дефинирани виртуални терминали (които също ще бъдат обсъдени по-късно) се активират с покани за разрешение. Упълномощаването е възможно както за администратора, така и за всеки потребител, но ще трябва да забравите за влизане без парола. Накратко, върви нормална цивилизована работа...
Няма непреодолима разлика между режимите за един и много потребители: преходът от един режим към друг е възможен не само при рестартиране на машината, но и по време на една сесия. За да преминете незабавно към режим на един потребител, използвайте командата
$ изключване сега
Връщането обратно към мултиплейър режим става чрез команда
Този метод се използва широко за повторно инициализиране на системата без пълно рестартиране след промяна на параметрите на конфигурацията - протича много по-бързо от пълно рестартиране. Просто трябва да запомните, че не всички услуги и демони са длъжни да работят правилно. Например демонът на конзолната мишка отказва да обслужва.
Зареждането в многопотребителски режим - и това е отличителна черта на BSD стил - потенциално води до наличието на абсолютно всички системни услуги и демони за стартиране: скриптовете, които ги инициализират (разположени в директорията /etc/rc.d) могат теоретично да се стартира от основния скрипт за стартиране - файла / etc / rc. Но кой от тях всъщност ще бъде стартиран се определя от опциите на неговия конфигурационен файл - /etc/rc.conf. Наличието на няколко основни скрипта за стартиране и неговия конфигурационен файл е втората отличителна черта на DragonFly (и като цяло стил на иницииране на BSD).
Когато DragonFly е инсталиран, в директорията / etc на диска се записва по подразбиране /etc/rc.conf, чиито редове изглеждат така
Servicename_enable = "стойност"
Променлива = "стойност"
Стойността на низовете от първия вид = "ДА" или "НЕ". Лесно е да се досетите, че позволяват (или отказват) стартирането на наименувана услуга посредством съответния (и по правило едноимен) скрипт от директорията /etc/rc.d. Стойностите на низовете от втория вид са параметри, предавани на командите, включени в скриптовете за инициализация.
По подразбиране DragonFly - и това също е традиция на BSD системите - във файла /etc/rc.conf има право да стартира само минималния брой системни услуги, необходими за започване. Повечето от тях обикновено са забранени - или изрично, като се посочи стойността "НЕ", или по подразбиране (и откъде идват тези настройки по подразбиране - сега ще видим). Така че разрешаването на необходимите за потребителя демони (например същата конзолна мишка) е работа на самия потребител.
Началните настройки по подразбиране са взети от файла /etc/defaults/rc.conf, който описва всички възможни (и всички възможни) стартиращи услуги и техните параметри (не забравяйте - видяхме подобна двойка конфигурации по подразбиране и работещи за програмата за зареждане). Този файл не е предназначен за директно редактиране (въпреки че не е забранен от неговите атрибути за достъп). Вместо това се предполага да намери редове в него, свързани с необходимите услуги, да ги прехвърли в /etc/rc.conf и да им позволи да стартират (или, напротив, да ги откаже, ако е разрешено по подразбиране, но в това в случай че не е необходимо). Опциите за квалифициране на услугата също се вземат от /etc/defaults/rc.conf, прехвърлят се в /etc/rc.conf и им се присвояват желаните стойности.
Като цяло това се прави, например, така: в една виртуална конзола (на която трябва да се регистрирате като root или да получите нейните права с командата su), файлът /etc/rc.conf се отваря в текстов редактор, в друг (можете да влезете като обикновен потребител) дава команда като
$ по-малко /etc/defaults/rc.conf
И необходимите редове от последния просто се прехвърлят към първия, където се променят според случая. Не е вредно да използвате трета потребителска конзола за четене на man (5) rc.conf.
Как всичко това се случва на практика е по-лесно да се разгледа с няколко примера. В статията за инсталиране на DragonFly беше показано, че за да конфигурирате конзолна мишка с USB интерфейс, е достатъчно да активирате демона на съответните устройства, като въведете реда във файла /etc/rc.conf
Usbd_enable = "ДА"
Въпреки това, за всички други видове мишки трябва да се дефинират редица други променливи. Кои не е трудно да се определи. Отиваме в предварително отворения файл /etc/defaults/rc.conf и търсим редове, свързани с мишката в него - в този случай е удобно да използвате команда като
$ grep мишка по подразбиране / rc.conf
- и погледнете изхода от резултата от търсенето:
Moused_enable = "NO" # Стартирайте демона на мишката. moused_type = "auto" # Вижте ръчната страница за rc.conf (5) за наличните # настройки. moused_port = "/ dev / psm0" # Задайте на вашия порт на мишката. moused_flags = "" # Всички допълнителни флагове за moused. mousechar_start = "НЕ" # ако диапазонът по подразбиране 0xd0-0xd3 е зает във вашия # старт като mousechar_start = 3, вижте vidcontrol (1)
От което всъщност стават очевидни по-нататъшните действия. Първо, демонът на мишката трябва да бъде разрешен да стартира - за който редът се добавя към /etc/rc.conf
Moused_enable = "ДА"
Командата / usr / sbin / moused (и можете да активирате поддръжката на мишката от командния ред, но само в тази сесия - това ще бъде обсъдено малко по-късно) обикновено изисква две опции - посочване на протокола (това е описано от moused_type line) и порт за връзка (сериен, PS / 2, USB - мишките с шина най-вероятно не са използвани). Когато описвате протокола, линията
Moused_type = "автоматичен"
подходящ за всички, доколкото знам, съвременни гризачи с PS / 2 конектори, въпреки че може да се посочи точно - ps / 2. Но за серийни (и още повече шини) мишки, протоколът трябва да бъде зададен изрично. Какво - гледаме в man (5) rc.conf или man (8) moused (аз, с греховна постъпка, вече съм забравил за тези създания).
Изрична индикация за порт също е необходима само за серийни мишки и мишки с гуми („Познаваш ли леля Маня? – Познавам леля Маня. – Вярваш ли на леля Маня? – Вярвам на леля Мана. – Така че, питайте я за такива животни .. .") ... Макар че ако уточниш
Moused_port = "/ dev / psm0"
за PS-полу звяр няма да има ни най-малка вреда.
Moused_flags = ""
можете да зададете различни опции, предоставени за командата /usr / sbin / moused, като например: емулация на средния бутон за модели с два бутона (при превъртащи мишки колелото работи подобно на средния бутон), скорост на реакция, ускорение при движение курсора и т.н. За подробности - пак към Мана, към Мана, към Мана...
Е, относно линията
Mousechar_start = "НЕ"
разговорът вече е бил: ако KOI8-R се използва като изходно кодиране и ядрото не е преустроено или е възстановено без опцията
Опции SC_MOUSE_CHAR = 0x3
НЕ по подразбиране трябва да се замени с 3. Във всеки друг случай просто не е необходимо.
Както ще видите в следващата статия, една от целите на възстановяването на ядрото беше да осигури поддръжка на графична конзола. Не е достатъчно обаче да включите съответната опция в конфигурацията на ядрото - съответният видео режим все още трябва да бъде активиран. Това се осигурява от скрипта /etc/rc.d/syscons, който изпълнява по-специално командата vidcontrol, която отговаря за всичко, свързано с настройките на дисплея. И тази команда получава своите параметри отново от файла /etc/rc.conf. По-специално, видео режимът се определя от променливата
Allscreens_flags = ""
за които трябва да дефинирате съответната стойност под формата на режим MODE_ #. Например, ако искате да имате разделителна способност 800 × 600 и 32-битова дълбочина на цвета, този ред ще приеме формата
Allscreens_flags = "MODE_277"
Сега за последния етап на иницииране - процеса на получаване на терминал. Той се контролира от записи във файла / etc / ttys, който беше споменат накратко в статията за инсталиране на системата. Наличието на специален файл за конфигуриране на виртуални терминали е третата от важните разлики между BSD системите: в Linux, независимо от стила на инициализиращите скриптове, приети в конкретна дистрибуция, настройката на виртуални терминали е описана в общата конфигурация на init процес.
Съдържанието на файла / etc / ttys изглежда така (пропускам редовете, описващи терминалите, получени чрез комутируем достъп до машината, като неуместни):
Console none unknown off secure # ttyv0 "/ usr / libexec / getty Pc" cons25 на защитен # Виртуални терминали ttyv1 "/ usr / libexec / getty Pc" cons25 на защитен ttyv2 "/ usr / libexec / getty Pc" cons25 on secure " / usr / libexec / getty Pc "cons25 на защитен ttyv4" / usr / libexec / getty Pc "cons25 на защитен ttyv5" / usr / libexec / getty Pc "cons25 на защитен ttyv6" / usr / libexec / getty Pc "cons25 на защитен ttyv7 "/ usr / libexec / getty Pc" cons25 на защитен ttyv8 "/ usr / X11R6 / bin / xdm -nodaemon" xterm изключен защитен
Както можете да видите, това е проста база данни, полетата на която имат следното съдържание:
- името на терминалното устройство, което има стойности конзола за така наречената системна конзола и името на виртуалния терминал (ttyv #, където # е пореден номер) за всички останали;
- процесът, стартиран на този терминал, за да го активирате; на системната конзола не се стартира процес, неговата роля (на първо място, мястото, където се поставят системните съобщения) се играе от първия виртуален терминал; при други, с изключение на последния (което ще бъде отделна дискусия), такъв процес е стандартният getty;
- тип терминал - по подразбиране за стандартен видео режим 80 × 25;
- състояние на терминала, което определя дали е активиран (включен) или не (изключен); "отрицателната" стойност по подразбиране може да се види в два записа - първия и последния;
- степента на сигурност на терминала; стойността по подразбиране secure предполага, че този терминал е физически, така да се каже, недостъпен за нападателя и следователно суперпотребителят може безопасно да се регистрира в него; ако го промените на незащитен, тогава root оторизирането от този терминал ще бъде невъзможно; задаване на unsecure за системната конзола ще доведе до задаване на паролата на суперпотребител при зареждане в режим на един потребител.
Какво подлежи на промяна тук? Първо, типът на терминала: в случай на русификация на режима на конзолата, стойността по подразбиране cons25 трябва да бъде заменена с cons25r; обаче го направихме веднага след инсталацията, нали? Ако използвате плътност на знаците, различна от стандартната, типът на терминала също трябва да бъде променен. Например, ако използвате режим 80x30, заменете cons30r тук. Пълен списък с валидни стойности на тип терминал може да бъде намерен във файла / etc / termcap.
Освен това, от гледна точка на сигурността, не е без причина да се разреши авторизация на суперпотребител само на всяка една виртуална конзола, например първата: тя все още не е много подходяща за практическа работа, тъй като върху нея се натрупват системни съобщения . Повечето от тях, разбира се, могат да се отърват чрез редактиране на файла /etc/syslog.conf, пренасочвайки техния изход, описан от реда
* .err; kern.debug; auth.notice; mail.crit / dev / конзола
от системната конзола към някакъв файл (или дори към устройството / dev / null). Въпреки това, някои неща все още ще се появяват на конзолата - например съобщения за прикачване и отделяне на устройства с горещо захранване (като USB памети или PC карти).
По принцип регистрацията на администратор може да бъде забранена напълно: получаване на временни права на root-оператор с командата
Това в никакъв случай не е пречка. Разбира се, броят на виртуалните терминали, активирани при стартиране на системата, може да се променя в една или друга посока. Ясно е, че за да намалите броя им, е достатъчно просто да изтриете или коментирате "допълнителните" редове, а за да ги увеличите - въведете липсващите в изображение и подобие на съществуващите (като не забравяйте да преименувате файловете на съответните устройства). Само имайте предвид, че ядрото GENERIC по подразбиране поддържа 16 виртуални терминала, поне един от които трябва да бъде запазен за стартиране на X window система - ръчно или автоматично. И още нещо - когато броят на виртуалните терминали се увеличи, трябва да се погрижите за наличието на файлове на съответните устройства (като ttyv #) - по подразбиране има "само" 12 от тях в директорията / dev.
Между другото, за X. Потребителите на Linux имат способността да предоставят графично оторизиране (и автоматично X зареждане) чрез прост метод - промяна на нивото на изпълнение по подразбиране. А какво да кажем за потребителите на BSD системи, които нямат понятие за ниво на изпълнение - тези, които работят основно в X и на които им е писнало да пишат командата startx? Да, всичко е също толкова просто: достатъчно е да активирате виртуалния терминал "x", като замените изключено с включено в последния даден ред. Това автоматично ще зареди графичния мениджър за влизане - xdm. Което, разбира се, може да бъде заменено с по-усъвършенстван аналог. Например линията
Ttyv8 "/ usr / local / bin / kdm -nodaemon" xterm изключен защитен
Недостатъкът на инициализирането на системата е спирането или рестартирането й, практически няма разлики между тези процеси. И за това отговаря командата за изключване, която може да бъде дадена от името на суперпотребителя или член на групата оператори. С опцията -h тя кара машината да спре, с опцията -r тя се рестартира. И тази команда също изисква аргумент - времето, когато трябва да се случи спирането или рестартирането. Има обаче начин за незабавно спиране или рестартиране:
$ изключване -h сега
$ изключване -r сега
съответно.
Освен това има и команди за спиране и рестартиране със същата цел. Те обаче не играят самостоятелна роля, просто като извикват командата за изключване с опция за спиране и съответно рестартиране.
Системата спира в обратен ред на нейната инициализация. Първо, се прави опит за грациозно прекратяване на всички потребителски процеси чрез изпращане на сигнала TERM. След изтичане на определен период от време се изпраща сигнал KILL до всички все още "живи" процеси - за да се гарантира, че те са убити. Тогава всички стартиращи услуги и демони се спират. Накрая съдържанието на дисковите кешове се записва на диска (чрез командата за синхронизиране) и файловите системи се демонтират. След това обикновено се появява съобщение, което показва, че машината може безопасно да изключи захранването или се изключва автоматично. При рестартиране всичко се случва точно по същия начин, но след спиране на системата машината автоматично се рестартира.
Както вече споменахме, скриптовете, отговорни за стартирането на услугите за стартиране, се намират в директорията /etc/rc.d. Повечето от програмите, които изпълняват, са така наречените демони (демон - Disk And Execution MONitor), нещо като TSR програми, работещи във фонов режим и чакащи заявка за изпълнение на тяхната функция (печат, изпращане на поща, достъп до ftp или http сървър и и т.н.). В съответствие с това скриптовете, които ги стартират, са подредени по принципа начало - стоп. И ако първата функция се изпълнява при стартиране на системата, тогава когато тя спре, както може да се досетите, втората.
Прогресът на процеса на изключване се контролира от скрипта /etc/rc.shutdown. Целта му е да изпълни функцията за спиране в скриптове на всички услуги, стартирани от /etc/rc скрипта в съответствие с описанието, дадено в /etc/rc.conf и /etc/defaults/rc.conf.
