კორპორატიული IT სისტემის შემუშავებისას აუცილებელია გადასაჭრელი ამოცანების დიაპაზონის განსაზღვრა და უსაფრთხოების, სიჩქარისა და საიმედოობის მოთხოვნები. ეს მახასიათებლები პირდაპირ დამოკიდებულია სერვერზე დაინსტალირებული ოპერაციული სისტემის (OS) არჩევანზე. თავისუფლად გადანაწილებადი UNIX-ის მსგავსი სისტემები BSD და GNU / Linux თანდათან ანაცვლებენ ნაცნობ Windows-ს. ისინი უფრო უსაფრთხოა, ვინაიდან წვდომა ხორციელდება პრინციპით „ყველაფერი აკრძალულია, რაც დაუშვებელია“, ამიტომ ისინი პრაქტიკულად არ არიან მგრძნობიარე ვირუსის შეტევების მიმართ, აქვთ მაღალი შესრულება და საიმედოობა.
BSD ოპერაციული სისტემები
Berkeley Software Distribution (BSD) პროგრამული უზრუნველყოფის განაწილების სისტემა შეიქმნა 90-იანი წლების დასაწყისში ბერკლის (კალიფორნია) უნივერსიტეტის კურსდამთავრებულების მიერ. UNIX-ის მსგავსი ოპერაციული სისტემის დეველოპერებმა 386BSD გამოუშვეს საწყისი კოდი ღია წვდომისთვის და მათ საფუძველზე დაიწერა ძირითადი ოპერაციული სისტემები:
- BSD / OS, კომერციული ვერსია.
- NetBSD, ღია წყარო.
- FreeBSD, ღია წყარო.
კომერციული ვერსია აღარ არის მხარდაჭერილი და სხვა ღია პროექტები წარმატებით ვითარდება. ამჟამად არის 4 ღია კოდის BSD პროექტი. თითოეული პროექტი ეფუძნება საკუთარ ბირთვს; ისინი შექმნილია სხვადასხვა მიზნით, მაგრამ პრაქტიკულად დიდად არ განსხვავდებიან ერთმანეთისგან.
BSD ოჯახი:
- FreeBSD - პროექტის მიზანია შექმნას ადვილად სამართავი სისტემა მაღალი წარმადობით.
- DragonFlyBSD - მაღალი ხარისხის მასშტაბირებადი OS, რომელიც შექმნილია მულტიპროცესირების (SMP) მხარდასაჭერად, მიღებული FreeBSD პროექტიდან;
- NetBSD - მხარს უჭერს კოდის მაქსიმალურ პორტაბელურობას სხვადასხვა გამოთვლითი რესურსებისთვის; მხარს უჭერს მოძველებულ აპარატურას; ეს OS გამოიყენებოდა ნასას კოსმოსურ პროექტებში.
- OpenBSD - საიმედო OS გაზრდილი უსაფრთხოების დონით NetBSD პროექტზე დაყრდნობით; ის დაინსტალირებულია აშშ-ს ბანკებსა და სამთავრობო უწყებებში.
ცალკე შეიძლება აღინიშნოს TrueOS (ყოფილი PC-BSD), ოპერაციული სისტემა, რომელიც დაფუძნებულია FreeBSD-ზე და ორიენტირებულია სამუშაო სადგურებზე გამოსაყენებლად.
ყველაზე გავრცელებული არის FreeBSD, BSD მომხმარებელთა 80%-ს აქვს ის დაინსტალირებული.
ონლაინ რეჟიმში, დეტალური დოკუმენტაცია ხელმისაწვდომია სხვადასხვა ფორმატში სისტემის კონფიგურაციისა და მართვისთვის.
FreeBSD-ზე აპლიკაციების დაინსტალირება შესაძლებელია ორი გზით:
- პაკეტის მენეჯერის გამოყენებით (დაწყებული 9.1 ვერსიიდან, ნაგულისხმევად შემოთავაზებულია ახალი, უფრო მოქნილი პაკეტის განხორციელება, რომელიც პრაქტიკულად შეესაბამება პორტებში არსებულ ვერსიებს);
- პორტების კოლექციის გამოყენებით.
Ports Collection - ავტომატური სისტემა წყაროდან პროგრამული უზრუნველყოფის შესაქმნელად - მნიშვნელოვნად ამარტივებს ინსტალაციის პროცესს. ამ დროისთვის 33000-ზე მეტი განაცხადია. საკმარისია build-ის პარამეტრების დაყენება მენიუდან საჭირო ელემენტების არჩევით და აღსრულების პროცესის დაწყება.
Linux ოპერაციული სისტემები
Linux, BSD-სგან განსხვავებით, მხოლოდ OS-ის ბირთვია. 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 განაწილების საფუძველზე, სტაბილური სერვერის OS.
- PCLinuxOS არის პორტატული LiveCD დისტრიბუცია.
თითოეული Linux შეიქმნა კონკრეტული ამოცანებისთვის. Gentoo-სა და Arch-ის ინსტალაცია მოითხოვს უამრავ გამოცდილებას დამოკიდებულების და მძღოლის პრობლემების გადაჭრაში. Ubuntu და Debian დისტრიბუციები შედარებით მარტივი ინსტალაციაა.
Linux-ის არაფორმალური საზოგადოების გამოცდილი სპეციალისტების რჩევები გვეხმარება გავიგოთ სისტემასთან მუშაობის სირთულეები. Linux-ისთვის დაწერილი აპლიკაციების უმეტესობის ჩამოტვირთვა თავისუფლად შეიძლება ინტერნეტის საცავებიდან.
შედარება FreeBSD და Linux
ორივე BSD ოჯახი და Linux ყველაზე ხშირად განვითარებულია არაკომერციულ საფუძველზე და ხელმისაწვდომია უფასო გამოყენებისთვის. მომხმარებლებს შეუძლიათ მიიღონ წყაროს კოდები და შეცვალონ მათი შეხედულებისამებრ.
ორივე FreeBSD და Linux დისტრიბუცია არის UNIX-ის მსგავსი ოპერაციული სისტემები. Linux თავდაპირველად შეიქმნა Linus Torvalds-ის მიერ, როგორც უფასო ალტერნატივა 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 გუნდის მიერ. მაშინ როცა ლინუქსი მხოლოდ ბირთვია. მაგრამ უკვე კონკრეტული განაწილების ნაკრები შეიცავს, გარდა ბირთვისა, პროგრამული უზრუნველყოფის გარკვეულ კომპლექტს, რომელიც ხშირად გროვდება სხვადასხვა წყაროდან.
FreeBSD-ისა და Linux-ის გამოყენება
საინტერესოა, რომ ორივე FreeBSD და Linux არის მრავალი სხვა ღია კოდის და საკუთრების სისტემის ცენტრში და გამოიყენება სხვადასხვა მოწყობილობებზე.
მაგალითად, FreeBSD არის შემდეგი პროდუქტების საფუძველი:
- FreeNAS არის ოპერაციული სისტემა ქსელის შესანახად.
- pfSense არის firewall განაწილება.
- m0n0wal არის ჩაშენებული firewall განაწილების ნაკრები.
- დარვინი არის macOS, iOS სისტემების ბირთვი.
- Junos არის Juniper Networks-ის ქსელური აღჭურვილობის ოპერაციული სისტემა.
- Isilon Systems-ის OneFS არის ოპერაციული სისტემა NAS-ისთვის Dell EMC-ისგან.
- Netflix Open Connect appliances - სტრიმინგის სერვერები.
- სათამაშო კონსოლები 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 აწარმოებს ზოგიერთ სერვის სერვერს.
თქვენ შეგიძლიათ დააინსტალიროთ და შეამოწმოთ ნებისმიერი OS ჩვენს ვირტუალურ აპარატებზე და კომპანიის სპეციალისტები ყოველთვის გაგიწევენ კვალიფიციურ მხარდაჭერას.
თანამედროვე ღია კოდის პროგრამული უზრუნველყოფის სფეროში, სიტყვა "Linux" პრაქტიკულად გახდა "ოპერაციული სისტემის" კონცეფციის სინონიმი, თუმცა ცოტამ თუ იცის, რომ სინამდვილეში ის შორს არის დღეს Unix-ის მსგავსი ერთადერთი ოპერაციული სისტემისგან, რომლის წყაროს კოდებიც ხელმისაწვდომია. ყველასთვის.
1999 წელს, IOSC-ის მონაცემებით, ინტერნეტთან დაკავშირებული ყველა აპარატის თითქმის მესამედი მუშაობდა Linux-ზე, ხოლო თითქმის 15% მუშაობდა FreeBSD-ზე. როგორი სისტემაა ეს და დღემდე მხოლოდ რამდენიმე თანამედროვე კომპიუტერის მომხმარებელმა იცის, მიუხედავად მისი ყველა უპირატესობისა და ერთ დროს ფართო გამოყენებისა. აღსანიშნავია ის ფაქტი, რომ ამ სისტემაზე აქტიურად მუშაობს ვებ სერვისების სფეროში მსოფლიოს მრავალი ლიდერი. კერძოდ, უნდა აღინიშნოს, რომ Yahoo სისტემა დღეს დაფუძნებულია FreeBSD-ზე. რას აძლევს ეს მომხმარებლებს, მათ თავად არ იციან და არც ფიქრობენ, მაგრამ სისტემის მფლობელები დარწმუნებულნი არიან, რომ ეს სწორი გადაწყვეტილებაა.
რა არის BSD?
BSD ნიშნავს Berkeley Software Distribution-ს. ეს იყო პროგრამული უზრუნველყოფის სახელი, რომელიც გავრცელდა ბერკლიში საწყის კოდებში. აღსანიშნავია, რომ სტანდარტული UNIX ოპერაციული სისტემის ორიგინალური დამატება იყო ერთადერთი რამ, რასაც FreeBSD წარმოადგენდა. რა იყო ეს სისტემის ამჟამინდელ ვერსიასთან შედარებით?
BSD-Lite-ის 4.4 ვერსიის საფუძველზე შეიქმნა რამდენიმე ღია კოდის ოპერაციული სისტემა. კერძოდ, ამ სისტემების შემადგენლობაში შედიოდა სხვა პროექტების შემუშავება, რომელთა შორის 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-სთან. ამ კონტრაქტის მიზანია სხვადასხვა საკომუნიკაციო პროტოკოლების განახლება. რომელზედაც მხარდაჭერილი იყო სააგენტოს კომპიუტერული ქსელი ...
1980-იან წლებში რამდენიმე სამუშაო სადგურის კომპანია გაჩნდა, ბევრმა შეიძინა UNIX ლიცენზიები, ვიდრე ცდილობდნენ ნულიდან საკუთარი პროგრამული უზრუნველყოფის განვითარებას. კერძოდ, აღსანიშნავია Sun-ი, რომელმაც ეს გააკეთა და გადაწყვიტა საბოლოოდ გამოუშვა საკუთარი ოპერაციული სისტემა 4.2BSD ვერსიის საფუძველზე, რომელსაც ეწოდა SunOSTM. როდესაც UNIX კომპანია AT&T-მა საბოლოოდ გადაწყვიტა საკუთარი ოპერაციული სისტემის კომერციალიზაცია, საკმაოდ მკაცრი დანერგვა გაჩნდა - System III, რასაც დროთა განმავლობაში მოჰყვა System V-ის გამოშვება.
რა მიზეზით რჩება ეს ოპერაციული სისტემა გამოუცხადებელი?
არსებობს მრავალი მიზეზი, რის გამოც FreeBSD 10 დღეს ნაკლებად პოპულარულია:
- დეველოპერებს ყველაზე ხშირად აინტერესებთ საკუთარი კოდის ხარისხი და უფრო მისი გაპრიალება, ვიდრე რეკლამა.
- ზოგადად, Linux-ის პოპულარობა არის მრავალი გარე ფაქტორების შედეგი ამ პროექტთან დაკავშირებით, კერძოდ, ეს ეხება მედიას, ისევე როგორც კომპანიებს, რომლებმაც გადაწყვიტეს შექმნან საკუთარი ბიზნესი, ამ ოპერაციული სისტემის მომხმარებლებისთვის სერვისების მიწოდება. .
- BSD დეველოპერები აბსოლიტურად უფრო გამოცდილები არიან, ვიდრე Linux-ის დეველოპერები და, შესაბამისად, გაცილებით ნაკლებ ყურადღებას აქცევენ ჩვეულებრივი მომხმარებლებისთვის ცხოვრების გამარტივებას. სხვა სიტყვებით რომ ვთქვათ, საშუალო მომხმარებლისთვის FreeBSD-ის დაყენება უფრო რთულია, ვიდრე
- 1992 წელს UNIX-ის დეველოპერმა გადაწყვიტა უჩივლოს BSDI-ს, რომელიც აწვდიდა BSD / 386 ოპერაციულ სისტემას. ამ საქმეში ბრალდების მთავარი აზრი ის იყო, რომ OS შეიცავდა მოსარჩელის საკუთრებაში არსებულ დახურულ კოდს და, როგორც ჩანს, საქმე საბოლოოდ სასამართლოს მიღმა 1994 წელს მოგვარდა, მაგრამ მეორადი დავის მთელი კომპლექსი, დღესაც კი სიცოცხლეს წამლავს. მრავალი ადამიანის.
- ითვლება, რომ თავად BSD პროექტები განსხვავდება და შესაძლოა კონფლიქტიც კი იყოს ერთმანეთთან. ეს მოსაზრება ეფუძნება დიდი ხნის წინ მომხდარ მოვლენებს.
რომელია უკეთესი - Linux თუ BSD?
დღეს, Apache სერვერის დაყენების ყველაზე გავრცელებული არჩევანია FreeBSD, ვიდრე სხვა სისტემებისთვის ტრადიციული Linux სისტემის ნაცვლად. საშუალო მომხმარებლისთვის, ამ სისტემებს შორის განსხვავება საოცრად მცირეა, რადგან ორივე პროდუქტი დაფუძნებულია UNIX-ზე. ორივე სისტემა შემუშავებულია არაკომერციულ საფუძველზე.
ვის ეკუთვნის BSD?
აღსანიშნავია, რომ არ არსებობს კონკრეტული პირი ან კომპანია, რომელიც ფლობს BSD დეველოპმენტს. ამ სისტემის შემუშავება და შემდგომი გავრცელება ახორციელებს მაღალკვალიფიციური და ამავდროულად მთელი მსოფლიოდან შეკრებილი პროექტის სპეციალისტების მთელი ჯგუფის მიერ. ზოგიერთი BSD კომპონენტი არის ცალკეული პროექტები, რომლებიც ღია წყაროა, რომლებსაც აქვთ საკუთარი კანონები და განვითარების გუნდები.
რა უნდა აირჩიოთ?
ამ ოპერაციულ სისტემებს შორის არჩევანი მართლაც საკმაოდ რთულია, ამიტომ არსებობს რამდენიმე რჩევა, რომელიც საშუალებას გაძლევთ აირჩიოთ რომელი ვარიანტია ოპტიმალური - Linux თუ FreeBSD. ბრძანებები ორივე შემთხვევაში საკმაოდ მსგავსია, ამიტომ არჩევანი ყველაზე ხშირად შეიძლება ეფუძნებოდეს შემდეგს:
- თუ თქვენ უკვე იყენებთ გარკვეულ ღია კოდის OS-ს, მაშინ არც კი უნდა შეცვალოთ რაიმე.
- FreeBSD სისტემებს შეუძლიათ ბევრად უკეთესი მუშაობა, მაგრამ ეს წესი არ არის უნივერსალური.
- BSD სისტემებს საკმაოდ კარგი რეპუტაცია აქვთ, განსაკუთრებით მაშინ, როცა საქმე სანდოობას ეხება.
- BSD პროექტებს აქვთ უკეთესი რეპუტაცია მათი მაღალი ხარისხისა და ხელმისაწვდომი დოკუმენტაციის სისრულისთვის.
- BSD–ს შეუძლია გამოიყენოს Linux–ის შესრულებადი ფაილების დიდი უმრავლესობა, ხოლო Linux–ს არ შეუძლია გამოიყენოს ბევრი BSD შესრულებადი.
უზრუნველყოფს ტექნიკურ მხარდაჭერას და მომსახურებას FreeBSD - პორტებისა და სისტემებისთვის - FreeBSD Mall, Inc.
BSD ოჯახის უფასო დისტრიბუციის ოპერაციული სისტემების სამყაროში მოვლენები: FreeBSD, OpenBSD და NetBSD, დიდი ხანია მიიპყრო OS დეველოპერების ყურადღება. ინფორმაცია ასეთი სისტემების შესაძლებლობების, უპირატესობებისა და უარყოფითი მხარეების შესახებ, ისევე როგორც ინფორმაცია მათი კომერციული დანერგვის შესახებ (BSD / OS) სასარგებლო იქნება, როდესაც მომხმარებელი კიდევ ერთხელ დადგება კითხვის წინაშე: იყიდოს კომერციული Unix სისტემა თუ გადადგას ნაბიჯი უფასო მიმართულებით. პროგრამული უზრუნველყოფა. გარდა ამისა, სტატია შეიძლება იყოს დაინტერესებული ყველასთვის, ვისაც სურს იცოდეს Unix OS-ის ისტორია.
BSD Unix-ის ისტორია დაიწყო, როდესაც Unix ოპერაციული სისტემა მოვიდა ბერკლის უნივერსიტეტში (კალიფორნია, აშშ) 1974 წელს. იმ დროისთვის, ეს ოპერაციული სისტემა უკვე რამდენიმე წლის განმავლობაში იყო განაწილებული Bell Technical Labs-ის (BTL) მიერ ნომინალური გადასახადით უნივერსიტეტებსა და სხვა საგანმანათლებლო დაწესებულებებს შორის, რომელმაც მოახერხა მომხმარებელთა სიმპათიის მოპოვება, რომლებსაც მოსწონდათ სისტემის ღიაობა: Unix იქნა მიწოდებული. საწყის კოდში (BTL მხარდაჭერისა და გარანტიების გარეშე) და მომხმარებლებს საშუალება ჰქონდათ დამოუკიდებლად შეესწავლათ, შეესწორებინათ და გაეფართოვებინათ იგი. ამ ყველაფერმა გააჩინა სურვილი, გაეზიარებინათ თავიანთი ნამუშევრები Unix-ის სხვა ენთუზიასტებთან და მრავალი თვალსაზრისით ჩამოაყალიბა კონკრეტული აზროვნება და Unix კულტურა. უნდა აღინიშნოს, რომ Bell Technical Labs-ის თანამშრომლები ძალიან გონივრულად მოიქცნენ (შესაძლოა, არც კი გააცნობიერეს), რომ Unix-ს თავისუფლად ცურვის საშუალება მისცეს. Freedom-მა გაუწია მომსახურება როგორც თავად სისტემას, ასევე მის მომხმარებლებს - Unix-ზე ბევრი პროფესიონალი გაიზარდა, რომ აღარაფერი ვთქვათ ამ OS-თან დაკავშირებულ თემებზე დაცული დიპლომების რაოდენობაზე. ასე რომ, შეიძლება ჩაითვალოს, რომ Unix OS კომერციულ სამყაროში შევიდა სრული საუნივერსიტეტო განათლებით. სხვათა შორის, სულ ახლახან BSDI-მ გადაწყვიტა ასეთი ნაბიჯის გადადგმა - წყაროს კოდის გადაცემა საგანმანათლებლო დაწესებულებებისთვის. მაინტერესებს ისტორია განმეორდება?
მაგრამ დავუბრუნდეთ ბერკლის. სწორედ იქ დაიბადა ბევრი იდეა, რომელიც ახლა საყოველთაოდ მიღებულია - TCP/IP პროტოკოლის მხარდაჭერა Unix-ში, ვირტუალური მეხსიერების სისტემა, სწრაფი ფაილური სისტემა (FFS), ex და vi რედაქტორები, BSD სოკეტები (ქსელის აპლიკაციის პროგრამირების ინტერფეისი). ), გაგზავნეთ ფოსტა, csh და მრავალი სხვა. უნივერსიტეტმა ასევე მიაწოდა მსოფლიოს დიდი სპეციალისტები, რომლებმაც მრავალი თვალსაზრისით ჩამოაყალიბეს Unix-ის განვითარება - წარმოიდგინეთ ერიკ ოლმანი, ბილ ჯოი ან ჩაკ ჰეილი. მათ პირველებმა მიიღეს Unix ტექსტები, რომლებიც "დასახლდნენ" ბერკლიში. Unix შეიქმნა აქ კომპიუტერული სისტემის კვლევის ჯგუფის (CSRG) მიერ, რომელიც სამწუხაროდ დაიშალა 1992 წელს. თუმცა, მისი საუკეთესო ტრადიციები განაგრძო BSDI (Berkeley Software Development, Inc.) და FreeBSD და NetBSD განვითარების ჯგუფებმა. ახლახან დაემატა OpenBSD პროექტის გუნდი.
1. ყველაფერი დაიწყო 386BSD-ით
იმ დროს არსებობდა BSD Unix-ის რამდენიმე ვერსია, რომელიც როუმინგში იყო მსოფლიოში, მაგრამ მათ ყველას ჰქონდათ ერთი საერთო: მათ გამოსაყენებლად სჭირდებოდათ ორიგინალური Unix კოდის ლიცენზია. BSD კოდის უმეტესი ნაწილი დაიწერა ბერკლიში და ერთ დღეს ვიღაცამ შენიშნა, რომ ორიგინალური კოდის დიდი ნაწილი არ იყო დარჩენილი; ასე რომ, გაჩნდა იდეა, რომ შეგვექმნა უფასო Unix და დაიწყო მისი გავრცელება ქსელში (Net distribution).
უილიამ და ლინა ჯოლიცებმა გადაწყვიტეს გადაეწერათ სისტემის ნაწილები, რომლებიც არ არსებობდა ღია კოდის BSD Unix-ის შესაქმნელად. შედეგი იყო 386BSD ვერსია 0.0. ჯერ არ იყო მზად გამოსაყენებლად, 386BSD-ს ჰქონდა ერთი უდაო ღირსება: მას აღარ სჭირდებოდა საშინელი წყაროს ლიცენზია სისტემის მოქმედი ვერსიის შესაქმნელად. 386BSD 0.1 მალევე მოჰყვა (მაშინ Linux, უფასო Unix სისტემების ოჯახის კიდევ ერთი წევრი, წელიწადზე მეტი იყო). ბევრმა ადამიანმა, რომელთაც სურდათ გაეკეთებინათ კოდი, რომელიც უკვე იცნობდა, გადაწყვიტა დაეწყო 386BSD 0.1-ის გამოყენება და დაყენება. შედეგად, 1992 წლის ივნისიდან მოყოლებული, სისტემაში გაკეთდა დიდი რაოდენობით შესწორებები და გაუმჯობესება. ბევრ FTP სერვერს ჰქონდა არაოფიციალური პაჩკიტი (შესწორებების ნაკრები), რამაც 386BSD უფრო სტაბილური და გამოსაყენებელი გახადა - სისტემაში ბევრი პრობლემა მოგვარდა პაჩკიტით. მაგრამ დღეს, 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- მიმდინარე. FreeBSD-სა და OpenBSD-ს აქვთ იგივე განლაგება. ოფიციალურ გამოშვებას აქვს ვერსიის ნომერი და მოიცავს კარგად გამართულ უტილიტებს, ბირთვს, წყაროებს და ინსტალაციის ინსტრუმენტებს. გამოშვება არის ბალანსი მახასიათებლებსა და სტაბილურობას შორის - უფრო ადვილია ინსტალაცია, ვიდრე მიმდინარე გამოშვება. ასეთი ვერსიები კარგად არის გამართული და შედარებით იშვიათად ჩნდება, ამიტომ ისინი შესაფერისია მათთვის, ვისაც სურს ჰქონდეს სტაბილური სამუშაო სისტემა. ამ ვერსიების შენარჩუნება უფრო მოსახერხებელია, რადგან ყოველთვის ნათელია, რა არის სასწორზე. ყველაზე დიდი პრობლემა ოფიციალურ ვერსიებთან არის ის, რომ მომხმარებელი არ იღებს წვდომას წყაროს კოდის ბაზაზე უახლესი გაუმჯობესებებით და შესწორებებით. ფორმალური ვერსიის ინსტალაცია მარტივია - თითოეულ პლატფორმას აქვს დეტალური ინსტრუქციები, ჩატვირთვის დისკის სურათები ან miniroot ფაილური სისტემები. როგორც წესი, არსებობს წინა ვერსიიდან ახალზე მარტივი მიგრაციის პროცედურა.
NetBSD-current-თან დაკავშირებით სიტუაცია სრულიად განსხვავებულია. მიმდინარე ვერსია ჩნდება ყოველ ღამე და წარმოადგენს NetBSD წყაროს ხის ანაბეჭდს, რომელიც ხელახლა უნდა გადაიწეროს თქვენს პლატფორმაზე. იმის გამო, რომ მუშაობა მუდმივად მიმდინარეობს, მიმდინარე ვერსია ზოგჯერ არ არის მთლიანად გამართული, შეიძლება შეიცავდეს შეცდომებს, შეიძლება არც კი შედგეს. მიმდინარე ვერსია სასარგებლოა დრაივერის დეველოპერებისთვის, სისტემის პროგრამული უზრუნველყოფის შემქმნელებისთვის და მათთვის, ვინც წვლილი შეიტანა NetBSD-ის შექმნაში. ამჟამინდელი ვერსია დეველოპერებს საშუალებას აძლევს "ერთად შეაჩერონ", დაიჭირონ შეცდომები და სწრაფად შეიტანონ ცვლილებები. რაღაც მომენტში, მიმდინარე ვერსია იწყებს გადაქცევას ფორმალურ გამოცემაში, ტარდება ბეტა ტესტირება და ამ ფილიალიდან იზრდება ახალი მიმდინარე ვერსია და ა.შ. ამრიგად, განვითარება არ ჩერდება მყისიერად და ამავე დროს არც ერთი ეტაპი. იმალება საზოგადოებისგან - ყოველთვის შეგიძლიათ შემოგთავაზოთ თქვენი საკუთარი ცვლილებები და დამატებები, რომლებიც (თუ ისინი აზრს იძენენ) ჩაირთვება მიმდინარეში.
NetBSD პროექტი ცდილობს დაიცვას ინდუსტრიის სტანდარტები, როგორიცაა POSIX და სტანდარტი 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 არაოფიციალური პაჩის ნაკრებიდან, უფრო სწორად, პაჩკიტიდან, რომელსაც ხელმძღვანელობდნენ ნეიტ უილიამსი, როდ გრაიმსი და ჯორდან ჰაბარდი. გარდა ამისა, განვითარებაში მონაწილეობდნენ დევიდ გრინმენი და ჯულიან ელიშერი, თუმცა ისინი ოფიციალურად შეუერთდნენ პროექტს განხორციელების დაწყებიდან მხოლოდ ერთი თვის შემდეგ. ვინაიდან პაჩკიტის საშუალებით სამუშაოს ორგანიზებამ დღე ვეღარ დაზოგა, პროექტის მთავარი მიზანი იყო 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) Tape-ზე ბერკლიდან და დაემატა კომპონენტები 386BSD-დან და Free Software Foundation-დან. პირველი ვერსიისთვის წარმატება საკმაოდ მნიშვნელოვანი იყო და მალე, 1994 წლის მაისში, ძალიან წარმატებული ვერსია 1.1 დაიბადა.
თუმცა, შემდეგ ღრუბლებმა დაიწყეს ჰორიზონტზე შეკრება. Novell-მა, AT&T-ის მემკვიდრემ, დაიწყო სასამართლო პროცესი Berkeley Net / 2 ფირზე კოდის ფრაგმენტების აკრძალვის გამო, რომელიც წარმოიშვა AT&T-ში. ბერკლის უნივერსიტეტი იძულებული გახდა გამოექვეყნებინა "მსუბუქი" ვერსია, სახელწოდებით BSD4.4-Lite და რეკომენდაცია გაუწია მასზე გადართვას ყველა Net / 2 მომხმარებელს. ამიტომ, 1994 წლის ივლისის ბოლოს, FreeBSD პროექტი წყვეტს FreeBSD-ის მიწოდებას, მაგრამ, სალიცენზიო ხელშეკრულების თანახმად, აქვს უფლება გამოუშვას სხვა ვერსია "X-საათამდე". შედეგი არის FreeBSD 1.1.5.1 - ერთი წლის შედეგი Net / 2-ზე. ამ ვერსიას ჰქონდა უკეთესი შესრულება, ვიდრე ყველა წინა, ჰქონდა უფრო მაღალი საიმედოობა და თავისთავად შესანიშნავი პროდუქტი იყო.
მაგრამ ახლა დეველოპერებს უნდა დაეწყოთ ყველაფერი თავიდან, ახალი და არასრული BSD 4.4-Lite ნაკრების საფუძველზე. სხვადასხვა სამართლებრივი შეზღუდვების გამო, ბერკლის CSRG-ის გუნდმა ამოიღო ბევრი კოდი, რომელიც გამოყენებული იყო ჩამტვირთავი, გაშვებადი სისტემის შესაქმნელად და სინამდვილეში Intel x86-ის პორტი ძალიან არასრული იყო. FreeBSD Project-მა კვლავ დაიწყო მუშაობა 1994 წლის დეკემბერში და უკვე 1995 წლის იანვარში FreeBSD ვერსია 2.0 გამოჩნდა ინტერნეტში და CD-ზე. გარკვეული უხეში კიდეების მიუხედავად, სისტემამ დიდი წარმატება მოიპოვა და მალევე მოჰყვა უფრო სწრაფად და მარტივად დასაყენებელი 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 მბ) სტრიქონში. პროექტის მიზანია უსაფრთხოების პრობლემებისგან თავის დაღწევა, აღმოჩენილი შეცდომების გამოსწორება და საერთო სტილის გაუმჯობესება. წყაროს კოდის ხე დაყოფილია ცალკეულ ნაწილებად, რომლებიც განიხილება სხვადასხვა პროგრამირების გუნდის მიერ; ყველა შესწორება არაერთხელ შემოწმდება დამოუკიდებელი ექსპერტების მიერ. ეს ყველაფერი იძლევა იმედს, რომ FreeBSD გახდება უფრო უსაფრთხო სისტემა. სხვათა შორის, ბოლო ექვსი თვის განმავლობაში BUGTRAQ საფოსტო სიის გაანალიზების შემდეგ, ხედავთ, რომ კომერციული ოპერაციული სისტემები, როგორიცაა Solaris, IRIX, რომ აღარაფერი ვთქვათ NT, მნიშვნელოვნად აღემატება FreeBSD-ს უსაფრთხოების კრიტიკულ პროგრამებში შეცდომების რაოდენობის მიხედვით. დამატებითი ინფორმაცია FreeBSD აუდიტის პროექტის შესახებ შეგიძლიათ იხილოთ: 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-ის მსგავსი PC სისტემა ამ მხრივ. OpenBSD-ის უახლესი ვერსია არის 2.0, 2.1 მალე გამოვა (CD და FTP სერვერებზე).
5. Net / Free / OpenBSD ფუნქციები
რა არის დღეს უფასო განაწილების სისტემების BSD Unix ოჯახი?
FreeBSD არის Unix-ის მსგავსი ოპერაციული სისტემა კომპიუტერებისთვის Intel-ის არქიტექტურაზე დაფუძნებული, რომელიც მოიცავს 386, 486 და Pentium პროცესორებს. გარდა ამისა, NetBSD / OpenBSD მხარს უჭერს ბევრ სხვა პლატფორმას. სამივე სისტემა გთავაზობთ ბევრ მახასიათებელს, რომლებიც ადრე მხოლოდ უფრო მძლავრ და ძვირადღირებულ მანქანებზე იყო ხელმისაწვდომი.
6. განხორციელების თავისებურებები
ძირითადი განაწილების გარდა, FreeBSD გთავაზობთ რამდენიმე ასეული დასახელების პორტირებული პროგრამული პროდუქტების დიდ კოლექციას. სიაში შედის ქსელის პროგრამული უზრუნველყოფა, პროგრამირების სისტემები, თამაშები და სხვა. სრული კოლექცია იკავებს მხოლოდ 10 მბ ადგილს დისკზე, რადგან ის შეიცავს მხოლოდ ცვლილებების სიებს, რომლებიც უნდა განხორციელდეს წყაროს კოდში კომპილაციამდე. ინსტალაციისთვის უბრალოდ აკრიფეთ ბრძანება "make", რის შემდეგაც სისტემა ავტომატურად აიღებს პროგრამის საბაზისო ვერსიას CD-დან ან FTP სერვერიდან, შეიტანს საჭირო ცვლილებებს და დააკომპლექტებს. მათთვის, ვინც არ აპირებს პროგრამების დამოუკიდებლად შედგენას, შესაფერისია მზა პროგრამული უზრუნველყოფის (პაკეტების) კოლექცია. პროგრამის დასაყენებლად, თქვენ უნდა აკრიფოთ ერთი ბრძანება "pkg_add" არქივის სახელით, რომელიც შეგიძლიათ იხილოთ CD ან FTP-ზე.
FreeBSD არის ფუნქციებით მდიდარი, საიმედო და სწრაფი. შესაძლოა, უფასო BSD სისტემების მთელი ოჯახის ეს სისტემა ახლა ყველაზე დინამიურად ვითარდება. დიდი ყურადღება ეთმობა სხვა სისტემებთან თავსებადობას და გამოყენებადობას. თუ მომხმარებელი მუშაობს x86-ზე, მაშინ ყურადღება უნდა მიაქციოთ FreeBSD-ს - ეს საშუალებას მოგცემთ ძალიან შეუფერხებლად შეხვიდეთ BSD სისტემების სამყაროში. NetBSD უფრო მეტ ყურადღებას ამახვილებს კროს-პლატფორმის მხარდაჭერაზე, ხოლო OpenBSD ცდილობს დააკავშიროს FreeBSD-ისა და NetBSD-ის საუკეთესოები სისტემის უსაფრთხოებაზე ფოკუსირებით. გარდა შესანიშნავი სამუშაოსა, რომელიც CSRG-მ შეასრულა, დეველოპერულმა გუნდებმა დახარჯეს მრავალი ათასი საათი სისტემების სრულყოფაზე მაქსიმალური შესრულებისა და საიმედოობისთვის. მიუხედავად იმისა, რომ კომერციული გიგანტები ებრძვიან მას PC ოპერაციული სისტემის სფეროში, 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 სისტემებზე, მაგრამ აზრი აქვს ასევე აღინიშნოს Berkeley Software-ის კომერციული BSD / OS ვერსია, DesingBSD / OS. CSRG-ის რამდენიმე წამყვანმა ექსპერტმა ჩამოაყალიბა BSD Inc. 1991 წელს, რათა შეემუშავებინა BSD ტექნოლოგია და მიეტანა იგი კომერციულ მომხმარებლებს.
BSD / OS არის სრულად გამორჩეული, POSIX-თან თავსებადი Unix სისტემა 386, 486 და Pentium პროცესორებისთვის. სისტემა ეფუძნება ბერკლის უნივერსიტეტის პროგრამულ უზრუნველყოფას, ასევე BSDI-ში შემუშავებულ სხვა წყაროებსა და კომპონენტებს. პირველი BSD / OS ვერსია მიეწოდება მომხმარებელს 1993 წლის მარტში. დღეს BSDI ინტერნეტ სერვერი, რომელიც დაფუძნებულია BSD / OS-ზე, ფართოდ არის აღიარებული თავის კლასში სისტემებში და მიღებული აქვს რამდენიმე ჯილდო (მაგალითად, InfoWorld Top Score Award 1995 წელს). სხვა BSD სისტემების მსგავსად, ეს OS შეიძლება იყოს 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 კომპანიის სავაჭრო ნიშანი, ამიტომ სხვა სისტემები, რომლებიც არ არიან უფლებამოსილი გამოიყენონ იგი, მოიხსენიებენ თავიანთ პროდუქტებს, როგორც Unix-ის ან თუნდაც "UN * X-ის მსგავსი". მაშასადამე, არცერთ ჩამოთვლილ OS-ს არ შეიძლება ოფიციალურად ეწოდოს Unix, მაგრამ გაუარესდა თუ არა ისინი?
დღეს, უფასო ოპერაციული სისტემები დინამიურად ვითარდება, არანაირად არ ჩამოუვარდება და ბევრ რამეში აჭარბებს კომერციულ კონკურენტებსაც კი. უფრო მეტიც, მომხმარებლებს ეძლევათ შანსი, რომ პირადად გავლენა მოახდინონ სისტემის განვითარებაზე - საკმარისია პერსონალში კარგი პროგრამისტები ჰყავდეთ, რომ გახდნენ დამოუკიდებელი ოპერაციული სისტემის გამყიდველისგან. თქვენ არ მოგიწევთ რამდენიმე კვირის ლოდინი, თუ აღმოაჩენთ რაიმე უზუსტობას ან რაიმეს გაუმჯობესებას ან დამატებას საჭიროებს. დეველოპერების დახურული გუნდის ნაცვლად (რამდენმა ადამიანმა იცის Windows 95-ის შემქმნელების სახელები?), არის ენთუზიასტების საზოგადოება, რომელიც ღიაა თანამშრომლობისთვის.
თქვენ შეგიძლიათ აირჩიოთ თქვენთვის ყველაზე შესაფერისი ოპერაციული სისტემა: FreeBSD, OpenBSD, Linux, NetBSD ან სხვა. მაგრამ რაც არ უნდა აირჩიოთ, ეს კარგი გარიგებაა. ბევრი მცირე ბიზნესი, ინტერნეტ სერვისის პროვაიდერი, სხვა ორგანიზაციები და მომხმარებლები უარს ამბობენ ფულის დახარჯვაზე იმაზე, რაც შეიძლება უფასოდ მიიღოთ და სულ უფრო ხშირად იყენებენ უფასო Unix სისტემებს. გეშინიათ, რომ ვერ შეძლებთ თქვენთვის საჭირო პროგრამული უზრუნველყოფის პოვნას? პირველ რიგში, თქვენი ინტერნეტ სერვისებისთვის, მეორეც, შეგიძლიათ შეიძინოთ პროგრამული უზრუნველყოფა BSD / OS და / ან Linux-ისთვის და გამოიყენოთ იგი თქვენს სისტემაში - ორობითი თავსებადობა კარგად არის გამართული. გარდა ამისა, ბევრი კომერციული დეველოპერი ახლა მიმართავს უფასო BSD სისტემებისკენ.
ლიტერატურა
ვ.კოლონცოვი. იპოვეთ, შეამოწმეთ და გაანეიტრალეთ. ღია სისტემები. - 1996, # 6, გვ. 58-63.
დამატებითი ინფორმაცია BSD ოპერაციული სისტემების შესახებ
386BSD - BSD-ის ძველი ვერსიები ახლა ფოკუსირებულია ექსკლუზიურად აკადემიურ და კვლევით საზოგადოებაზე, რომელიც ნაწილდება Dr. დობის ჟურნალი დისკებზე.
FreeBSD - Intel პლატფორმის BSD ვერსია გამიზნულია ფართო გამოყენებისთვის, განაწილებულია 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 ცხოვრობდა, ცხოვრობს და იცხოვრებს
ეს შენიშვნა წარმოიშვა ერთი სისტემიდან მეორეზე მრავალი გადასვლის დროს, მათი ერთობლივი გამოყენების მრავალი წლის განმავლობაში (IT ვადებში), ისევე როგორც თემაზე: რა სისტემაზე დავაყენო ახალი მანქანა? მისთვის უშუალო იმპულსი იყო მიმოწერა უამრავ ავტორთან და იდეალურ განაწილებაზე ოცნებები, რომლებიც ამდენი ხნის განმავლობაში არ იყო განხილული. მაგრამ პირველი, რამდენიმე გაფრთხილება
სასწრაფოდ უნდა გაგაფრთხილო - სათაურად წარმოდგენილ კითხვაზე პასუხი არ იქნება. იმიტომ რომ მე თვითონ არ ვიცნობ მას. მაგრამ იმის გამო, რომ მე მივყვები დიდი რომაელი ისტორიკოსის ანდერძს - შემიძლია დავდო. იმიტომ, რომ ორივე სისტემა მიყვარს და მით უმეტეს, ორივე სისტემას ვიყენებ ყოველდღიურ ცხოვრებაში - ხან ერთად, ხან ცალ-ცალკე, დავალებების, გარემოებების და უბრალოდ ჩემი განწყობის მიხედვით.
და კიდევ ერთი რამ: არცერთი სიტყვა არ იქნება ნათქვამი Linux-ის ან FreeBSD-ის სერვერების, ლოკალური ქსელის კვანძების და მსგავსი სისტემის ადმინისტრატორის საკითხებზე გამოყენებაზე. და ექსკლუზიურად - მომხმარებლის შესახებ, ანუ დესკტოპის, მათი თვისებების შესახებ. მკითხველთა გარკვეული კატეგორიის რეაქციის მოლოდინში, მზად ვარ ტეგით გამოვყო ბოლო ფრაზა და გაიმეორე ორჯერ და სამჯერ :-)სუბიექტური შესავალი
მალე ოთხი წელი გავიდა მას შემდეგ, რაც FreeBSD და Linux მონაცვლეობდნენ ჩემს აპარატებზე (სახლი და სამუშაო) რეგულარული ინტერვალებით. ან მშვიდობიანად თანაარსებობენ ერთ, ცალკე აღებულ სისტემურ ერთეულში. და ამ ხნის განმავლობაში შევნიშნე საინტერესო ნიმუში.
იმ პერიოდებში, როდესაც მე მაქვს FreeBSD ჩემს აპარატზე, ჩემი სამუშაო დრო დაახლოებით ასე ნაწილდება: 90% - პრაქტიკული სამუშაო (არ აქვს მნიშვნელობა რა არის ამ მომენტში), და 10% - მეტ-ნაკლებად არაჯანსაღი ექსპერიმენტები სისტემაზე. როგორც კი ზოგიერთი Linux ჩაჯდება მყარი დისკის კუთხეში - და ექსპერიმენტების დროის წილი მაშინვე 50%-მდე ხტება. და იმ პერიოდებში, როდესაც მე ვაშენებდი Linux-ს ნულიდან, ექსპერიმენტული რეჟიმი რეალურად გახდა მუდმივი.
და საკუთარ თავს დავუსვი კითხვა - რატომ? და - ჩემთვის - ვუპასუხე: FreeBSD არის თანმიმდევრული და ჰარმონიული სისტემა, რომელშიც საწყისი პარამეტრების კომპლექსის შემდეგ არ არის რაიმეს დამატება ან გამოკლების სურვილი. შემთხვევითი არ არის, რომ მოძრაობა, რომელიც დროდადრო ლინუქსის მომხმარებელთა ფართო სპექტრს მოიცავს, პრაქტიკულად არ განვითარდა FreeBSD სამყაროში: იენს შვეიხარდტის ცნობილი ნაშრომი (არსებული) უფრო მეტად არის sysinstall-ის ავტომატური ალტერნატივის აღწერა. , ვიდრე ხელით შექმნათ საკუთარი სისტემა ნულიდან.
Linux-ს არ შეუძლია ასეთი შინაგანი ჰარმონიის დემონსტრირება. და ამიტომ, უკვე დაყენებულ სისტემაში რაღაცის შეცვლის, ყველაფრის გაუმჯობესება, დამატება, გაწმენდა ან თუნდაც უბრალოდ ხელახლა აშენების სურვილი მუდმივად ჩნდება და მხოლოდ დროის ნაკლებობით იძლევა.
თუმცა, ეს არ ნიშნავს იმას, რომ მე ცალსახად ვთვლი, რომ FreeBSD არის საუკეთესო სისტემა სამუშაოსთვის. რადგან ჩემი ნამუშევარი, სხვა საკითხებთან ერთად, შედგება კომპიუტერის ირგვლივ სხვადასხვა ნოტების შექმნაზე. ნაკვეთები, რომლებიც ახორციელებენ იმავე არაჯანსაღ ექსპერიმენტებს სისტემაზე, რომლის გაკეთებაც Linux-ს ძალიან უხდება - და რომელიც FreeBSD-ს არ აქვს.
თუმცა, ვიმეორებ, ეს ყველაფერი წმინდა სუბიექტურია, რადგან ყველა არ არის დაკავებული კომპიუტერების ირგვლივ ნოტების შედგენით. და ამიტომ შევეცდები უფრო ობიექტური შედარება გავაკეთო.ობიექტივიზმის პირველი მცდელობა: „რკინა“
რა სჭირდება მომხმარებელთა უმეტესობას ოპერაციული სისტემისგან, როგორც ასეთი? უპირველეს ყოვლისა, რა თქმა უნდა, ტექნიკის მხარდაჭერა, რომელიც, როგორც მოგეხსენებათ, არ განიცდის ერთფეროვნებას დესკტოპ პერსონალურ კომპიუტერებზე.
ითვლება, რომ Linux მხარს უჭერს ტექნიკის უფრო ფართო სპექტრს, ვიდრე FreeBSD. მართლაც, ამ უკანასკნელისთვის, ჩვენ ვერ ვიპოვით, ვთქვათ, პრინტერის დრაივერებს მწარმოებლისგან. თანამედროვე ვიდეო ბარათების სრული მხარდაჭერა ხორციელდება მხოლოდ იმ შემთხვევაში, თუ ისინი NVIDIA-დან არიან (და მაშინაც კი, მიმოხილვების თანახმად, ისინი მნიშვნელოვნად უარესია, ვიდრე Linux-ისთვის). ალბათ ამ OS-ში იქნება დაძაბულობა და ე.წ. win - მოდემი. ეს არის ერთის მხრივ.
მეორეს მხრივ, Linux-ში ATA RAID და სერიული ATA კონტროლერების ყველა ბედნიერ მფლობელს ბოლო დრომდე უწევდა ყველა სახის ხრიკების გამოყენება. უფრო მეტიც, ის ყოველთვის არ არის წარმატებული, განსაკუთრებით იმ შემთხვევაში, თუ ასეთ კონტროლერებზე მიმაგრებული დისკები უნდა გამოეყენებინათ ჩატვირთვის მოწყობილობებად. სინამდვილეში, სიტუაცია ნორმალიზებულად შეიძლება ჩაითვალოს მხოლოდ 2.6.X-ის უახლეს ბირთვებში ...
FreeBSD-ში მე-5 ფილიალი, მეტ-ნაკლებად პარალელურად, რომელზედაც ზის მყარი დისკი IDE-ოჯახის კონტროლერი: CAM-ის (Common Access Method) წყალობით ნებისმიერ შემთხვევაში იქნება შესაძლებელი მასთან მუშაობა და თუ ის ასევე სწორად არის იდენტიფიცირებული, მაშინ მისგან ჩამოტვირთვის არანაირი დაბრკოლება არ იქნება. მე-4 ფილიალში კი - "ერთსა და იმავე ასაკის" ATA RAID კონტროლერებზე არასდროს შემხვედრია პრობლემები.
კიდევ ერთი მაგალითია ხმის ბარათები. ყველა ის, ვინც მეტ-ნაკლებად გავრცელებულ ჩიპებზეა დაფუძნებული, მუშაობდა FreeBSD-ში ოდნავი ძალისხმევის გარეშე (ხელები ან აზრები). იგივე შეიძლება ითქვას "ჩიპსეტის" ხმაზე. Linux-ში მსგავსი მოწყობილობები ხშირად მოითხოვდნენ არც თუ ისე ტრივიალურ მანიპულაციებს ALSA დრაივერებით, რადგან ახლა ისინი ჩაშენებულია ბირთვში. თუმცა, ამ უკანასკნელ შემთხვევაშიც კი, არ შეიძლება გარკვეული კორექტირების მოქმედებების გარეშე. მაგრამ ეს უკვე ობიექტივიზმის მეორე მცდელობის საგანია.
და "რკინის" ობიექტივიზმის შედეგი, მე ასე ჩამოვაყალიბებდი: შესაძლოა Linux მხარს უჭერს ყველა სახის აღჭურვილობის უფრო ფართო სპექტრს (მათ შორის ზოგიერთი ეგზოტიკური), მაგრამ ყველა "ტექნიკის", რომელსაც მხარს უჭერს FreeBSD (და ეს თითქმის ყველა სტანდარტია. და ფართოდ გავრცელებული "რკინა"), გამოყენება, უმეტეს შემთხვევაში, უფრო ადვილია. და აქ ჩვენ შეუფერხებლად გადავდივართ მომხმარებლისთვის მეორე საინტერესო მომენტზე, განსაკუთრებით დამწყებთათვის (და არა დამწყებებმა დიდი ხანია გააკეთეს არჩევანი) მომენტისთვის, რომლის სახელია Setting.
გრძელვადიანი (და საგულდაგულოდ გაშენებული) მოსაზრება, რომ FreeBSD უფრო რთული დასაინსტალირებელი და კონფიგურაციაა, ვიდრე Linux, შეიძლება მივაწეროთ სხვა არაფერი, თუ არა გაუგებრობა. იმიტომ რომ რეალობასთან საერთო არაფერი აქვს.
დავიწყოთ ინსტალაცია. FreeBSD-ის ინსტალაცია სტანდარტული საშუალებებით (sysinstall უტილიტას გამოყენებით) ხორციელდება ნახევარ საათში, არ საჭიროებს აუცილებელ წვდომას ქსელში (თუმცა ეს ზედმეტი არ იქნება) და შედეგად იძლევა სრულად ფუნქციონალურ სისტემას კირიული კონსოლით. ფუნქციონირებადი dial-up (ან, სიტუაციის მიხედვით, lokalku), გაშვებული 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-ის „მისტერ კორის“) უკან დაბრუნებას KOI8-ზე პროგრესული „UTF კოდირებიდან, თუმცა“ ერთი, მაგრამ საკმაოდ დამაკმაყოფილებელი ბევრისთვის. ბევრი...
კონსოლის რუსიფიკაცია მჭიდროდ არის დაკავშირებული ამ სისტემაში მიღებული საწყისი ფაილების სტილთან. და აქ ხაზოვანი BSD სტილი მომხმარებლის თვალსაზრისით უფრო მარტივია, ვიდრე System V სტილის ინიციაცია, რომელიც მიღებულია Linux-ში, კონცეფციაზე დაყრდნობით. გაშვების დონეები, რომლის თარგმნამ როგორც "runlevels" შეიძლება სრულიად დააბნიოს დამწყები მომხმარებელი.
ბატონებო, ინდუსტრიული სერვერის ადმინისტრატორები ამტკიცებენ, რომ System V სტილი საშუალებას გაძლევთ მოქნილად დააკავშიროთ და გათიშოთ სხვადასხვა გაშვების სერვისები. არ ვიკამათებ. თუმცა, რამდენად ხშირად აწყდება დესკტოპის მომხმარებელი ასეთ ამოცანას? უფრო ხშირად, მისი მიზანია ერთხელ და სამუდამოდ მოკლას მრავალი სერვისი, რომელიც დისტრიბუციის შემსრულებლებმა სასიცოცხლოდ მიიჩნიეს მისი ბედნიერებისთვის...
შემთხვევითი არ არის, რომ ბევრი თანამედროვე Linux დისტრიბუცია იყენებს BSD სტილის ჩატვირთვას, რომლის მაგალითები, გარდა კლასიკური Slackware, CRUX და Gentoo. და Archlinux-ში runlevels-ის ცნება ზოგადად კარგავს თავის მნიშვნელობას, თუმცა შესაბამისი სიტყვები / etc / inittab ფაილში შეიძლება მოიძებნოს, პრაქტიკაში runlevels საერთოდ არ თამაშობს სისტემის გაშვებისას. მაგრამ System V-ის "პროგრესული" სტილის BSD სისტემებში დანერგვის მცდელობები არ შეინიშნება. ასეთად ნუ განიხილავთ სხვადასხვა სერვისების სკრიპტების დაჯგუფებას ერთ ქვედირექტორიაში / etc-ში FreeBSD მე-5 ფილიალში.
რაც შეეხება X - X-ის რუსიფიკაციას, როგორც მოგეხსენებათ, ის ასევე არის აფრიკაში X. და კირილიცას შრიფტით ფაილებში ბილიკების შეყვანის, კლავიატურის განლაგების გასწორების და ლათინურიდან კირილიცაზე გადასვლის მოქმედებები გარდაუვალი იქნება, არ აქვს მნიშვნელობა. რა OSes X არის თავზე.
მეორე შემთხვევა არის ხმის რეგულირება. FreeBSD-ში ეს მოითხოვს (ჩვეულებრივი ჩიპებისა და ჩიპსეტების აუდიოს დიდი უმრავლესობისთვის) ბირთვის კონფიგურაციაში ერთი (და იგივე ყველა შემთხვევაში) ხაზის დამატება და ამ უკანასკნელის ხელახლა კომპილაცია. ამის შემდეგ, თქვენ შეგიძლიათ უბრალოდ დაივიწყოთ ხმა - ის იმუშავებს ნებისმიერ დროს, ნებისმიერ ადგილას.
სხვათა შორის, შეგიძლიათ გააკეთოთ ბირთვის ხელახალი კომპილაციის გარეშე, ხმის მხარდაჭერის მოდული (როგორც თითქმის ყველა მოდული) შედგენილია FreeBSD-ში უშეცდომოდ, თქვენ უბრალოდ უნდა ჩატვირთოთ ხელით ან უზრუნველყოთ მისი ჩატვირთვა სისტემის გაშვებისას.
Linux-ზე: ჩვენ ვიწყებთ იმით, რომ იგივე ჩიპსეტი აუდიო (და ბარათების თანდათანობით გაქრობით, როგორიცაა SB AWE128, სასურველი ხდება ყველა მომხმარებლისთვის მუსიკაზე დამოკიდებულების ან კომპოზიციის პრეტენზიების გარეშე), აუცილებლად მოითხოვს ALSA დრაივერებს. საბედნიეროდ, ახლა ისინი ჩაშენებულია ბირთვში და უმეტეს დისტრიბუციაში შედის ნაგულისხმევ ბირთვებში მოდულების სახით. თუ არა, მაშინ ბირთვის ხელახლა კომპილაცია არ იქნება დიდი საქმე.
თუმცა, საქმე არ შემოიფარგლება მხოლოდ ბირთვის ხელახლა შედგენით. ასევე აუცილებელია შესაბამისი ALSA-ინსტრუმენტარიუმის დაყენება (და, როგორც წესი, მისი თავსებადობის საშუალებები ძველ ხმის სისტემა OSS-თან), შესაბამისი დემონის გააქტიურება და არც თუ ისე აშკარა საშუალებების გამოყენებით, უზრუნველყოს მისი "თვითგანკურნება". . და ამ ყველაფრის შემდეგ ისევ სიურპრიზების წინაშე დგახარ. მაგალითად, ALSA-სა და ხელოვნების (KDE ხმის სისტემა) მშვიდობიანი თანაარსებობის უხალისოდ. რა თქმა უნდა, ხალხი შეიძლება ამტკიცებდეს, რომ ეს არის KDE-ს პრობლემები, მაგრამ FreeBSD-ს ისინი საერთოდ არ აქვს.
სხვათა შორის, ინსტრუმენტების (და სხვა პროგრამების) დაყენების შესახებ ... ეს მოითხოვს პაკეტის მართვის სისტემას
აქ, ბოლო დრომდე, FreeBSD უდავოდ იკავებდა უპირატესობას. მისი პორტების სისტემა უზრუნველყოფდა სიმარტივისა და მოქნილობის შეუდარებელ კომბინაციას, ყოველთვის ტოვებდა პაკეტების შექმნის შესაძლებლობას წყაროდან ან ინსტალაციას ბინარებიდან. ამ მეთოდების კომბინაციის გამორიცხვის გარეშე. Linux-ის ყველა სიმდიდრედან ამ სფეროში, მხოლოდ Debian-ის აპტი, რომელიც ასიმილირებულია მრავალი rpm-ზე დაფუძნებული დისტრიბუციის სიღრმეში, შეიძლება შედარება პორტებთან. თუმცა, მიუხედავად იმისა, რომ apt ითვალისწინებს საკუთარი პაკეტების შექმნის უნარს, მისი მთავარი მეთოდია წინასწარ კომპილირებული ბინარების გამოყენება, რომლებიც აწყობილია მათი დამოკიდებულების შესახებ შემნახველის იდეების შესაბამისად.
ახლა სიტუაცია შეიცვალა და Source Based Linux დისტრიბუციებში ფართოდ გამოიყენება პორტის მსგავსი სისტემები, რომლებიც განვითარდა მათი FreeBSD პროტოტიპის ძლიერი გავლენის ქვეშ: Gentoo portages, Sorcery from Sorcerer, CRUX პორტები, Archlinux Building System სადისტრიბუციო ნაკრებიდან. მოქნილობა, მოწყობილობის კონფიგურაციის ან გამჭვირვალობის გლობალიზაცია, გამოყენება და მოდერნიზაცია. გარდა ამისა, მათი განვითარების ათწლეულის განმავლობაში, FreeBSD პორტები გახდა ძალიან შრომატევადი და ძნელად დასანახი სტრუქტურა, მისი განახლება ცალკეა. ამოცანა, რომელიც თავად აღარ არის საბაზისო სისტემის ნაწილი, არამედ პორტების სისტემის ნაწილი).
და აქ მიზანშეწონილია ორიოდე სიტყვის თქმა კიდევ ერთ ფართოდ გავრცელებულ ლეგენდაზე - თითქოს წყაროდან აშენება პორტის მსგავსი საკონტროლო კომპლექსების საშუალებით ყოველთვის მივყავართ "სუფთა" (ანუ არასაჭირო კომპონენტებისგან თავისუფალი) სისტემამდე. ეს ყოველთვის ასე არ არის.
პირველ რიგში, პორტების (და მათი კლონების) ბუნებით, ხშირად არის დაინსტალირებული კომპონენტების სიჭარბე. სახელმძღვანელოს მაგალითია cvs-up, რომელიც განახლებისთვის საჭიროებს როგორც საბაზისო სისტემას, ასევე FreeBSD პორტებს: ორობითი ფორმით, ეს არის მსუბუქი კომპაქტური პაკეტი, რომელიც არ ამძიმებს მომხმარებელსაც კი მოდემის კავშირით. პორტების საშუალებით აშენებისას, ის ატარებს მოდულის განაწილებას (რადგან მასზე წერია), რაც არავის გამოადგება, გარდა ამ პროგრამირების ენის მიმდევრებისა.
ის, რაც ყოველთვის მაკვირვებდა FreeBSD პორტების შესახებ, არის ჩემი საყვარელი რედაქტორის ჯოის კონსტრუქციის მდგომარეობა. რაც, როგორც დამოკიდებულება, აუცილებლად მოითხოვდა GNU-ს 3.80 ვერსიას, თუმცა მისი საკუთარი მარკა შედის FreeBSD Distributions-ში და მისი ხელით შედგენა არ არის რთული.
ზოგადად, პაკეტის ინსტალაციის "სისუფთავე" ძალიან არის დამოკიდებული პორტის კონკრეტულ განხორციელებაზე. ცოტა ხნის წინ ახალ ამბებში აღმოვაჩინე შეტყობინება ახალი ფანჯრის მენეჯერის შესახებ, სახელწოდებით edo - პატარა, როგორც თქვეს, კომპაქტური და სწრაფი. ის ასევე იქნა ნაპოვნი FreeBSD პორტებში, საიდანაც გადავწყვიტე მისი აშენება. შედეგად, ამ პატარამ :–) WM-მა წაიღო (როგორც დამოკიდებულების დამოკიდებულება) მეტი არაფერი, ვიდრე MySQL...
თუმცა, თუ ფიქრობთ, რომ პორტების ეს ქცევა FreeBSD-ის მახასიათებელია და მათი Linux კლონების შემქმნელებმა გაითვალისწინეს წარსულის შეცდომები, მაშინ გარწმუნებთ, რომ ეს ყოველთვის ასე არ არის. უფრო მეტიც, Linux-ში სიტუაციას ამძიმებს საბაზისო სისტემის თავისებურებები, უფრო სწორედ, მისი ცალკეული კომპონენტების შემუშავების შეუსაბამობა.
ნებისმიერმა, ვინც ოდესმე შეადგინა Linux ნულიდან, იცის, რომ Base Linux-ის პაკეტების ზოგიერთი ვერსია აშენდება მხოლოდ გარკვეული (არავითარ შემთხვევაში უახლესი) უტილიტების ვერსიებით, როგორიცაა autoconf და automake, კატეგორიულად უარს ამბობს ამის გაკეთებაზე მათი სხვა ვერსიებით (თუნდაც უფრო უახლესი და პროგრესული).
წყაროზე დაფუძნებული Linux დისტრიბუციების შემქმნელები ზოგჯერ ამ სირთულის ირგვლივ ამუშავებენ და იძულებით ამატებენ შარშანდელი ჩამოსხმის პაკეტებს დამოკიდებულების ჩამონათვალში ასეთი "სლიური" ავტოკონფირმაციისა და ავტომატური შექმნის პაკეტებს, ხოლო თავად საბაზისო ნაკრები მოიცავს მათ მიმდინარე ვერსიებს. შედეგად, მაგალითად, Gentoo-ში, bootstrapping-ის ან emerge system-ის შესრულებისას, გაგიკვირდებათ, რომ სისტემა ინტერნეტში ტრიალებს წვერიანი, როგორიცაა კარლ მარქსი, autoconf, თუმცა მისი ახალი ვერსია ახლახან განლაგდა სცენაზე1. ტარბოლი. და თუ გახსოვთ, რომ ბევრს სჯერა, რომ ჭეშმარიტად სტაბილური Linux-ის ბირთვი შეიძლება შეიქმნას მხოლოდ gcc ვერსიით 2.9.X, რაც იწვევს სისტემაში ორი შემდგენელის არსებობას, მაშინ რა სახის "სუფთა" კონსტრუქციაზე შეიძლება ვისაუბროთ მაინც. ?
თუმცა, გონივრული ბალანსის მიღწევა წინასწარ კომპილირებული პაკეტების განლაგებას, პორტის მსგავსი სისტემიდან მათ ინსტალაციასა და თვითშეკრებას შორის სრულიად ცალკე თემაა. ამასობაში, მე გავბედავ ჩამომეყალიბებინა კიდევ რამდენიმე "ლინზა":
- FreeBSD, პოპულარული რწმენის საწინააღმდეგოდ, მნიშვნელოვნად ადვილია ადგილობრივად კონფიგურაცია და ადმინისტრირება. თუნდაც იმის გათვალისწინების გარეშე, რომ ის ერთია და ბევრი ლინუქსია;
- ამის საპირისპიროდ, FreeBSD პორტების სისტემას ამჟამად (განსხვავებით უახლესი წარსულისგან) არ აქვს მნიშვნელოვანი უპირატესობები Source Based Linux დისტრიბუციების მსგავს ინსტრუმენტებთან შედარებით.
თუ გულდასმით გამოთვლით ორივე ოპერაციული სისტემის ზემოაღნიშნულ დადებით და უარყოფით მხარეებს, შეგიძლიათ მიხვიდეთ დასკვნამდე, რომ მათ შორის ქულა თანაბარია. შესაძლოა, FreeBSD-ისთვის უმნიშვნელო პოზიციური უპირატესობით, მაგრამ იმდენად უმნიშვნელო, რომ სავსებით გონივრული იქნება ფრეზე დათანხმება. თუმცა, თითოეული OS დაინსტალირებული, კონფიგურირებული და გაფართოებულია აპლიკაციების მიერ არა საკუთარი გულისთვის, არამედ პრაქტიკული გამოყენებისთვის. და ამიტომ გასათვალისწინებელია მათი მომხმარებლის თვისებებთან შედარებით
აქ, დასაწყისისთვის, მე გავბედავ გამოვთქვა მაცდური, რომელიმე განსახილველი სისტემის ფანატიკოსების თვალსაზრისით, მოსაზრება (თუმცა, ფანატიკოსები ნებისმიერ მოსაზრებას, რომელიც არ ემთხვევა საკუთარ აზრს, მიიჩნევენ მაცდუნებლად). კერძოდ:
გრაფიკული მომხმარებლისთვის, მცირე განსხვავებაა FreeBSD-სა და Linux-ს შორის.
ასეთი მომხმარებელი დროის უმეტეს ნაწილს X-ში ატარებს და მისთვის არანაირი მნიშვნელობა არ აქვს, რომელ ოპერაციულ სისტემაზე მუშაობს ეს X. მას მხოლოდ ეჩვენება, რომ მუშაობს Linux-ში ან FreeBSD-ში (NetBSD, OpenBSD - მე გავბედავ ამ სიის გაფართოებას). ფაქტობრივად, ის მუშაობს KDE-ში (Gnome, XFce, WindowMaker - დაამატეთ საჭირო). და თუ მას არ მოუწია ოპერაციული სისტემის წინასწარ ინსტალაცია და კონფიგურაცია, მას ექნებოდა შანსი არასოდეს გაეგო, რომელ POSIX-თან თავსებადი სისტემებიდან მუშაობს: მას ექნება იგივე ინტერფეისის ელემენტები, იგივე კონფიგურაციის ხელსაწყოები და აპლიკაციები. ..
ასე რომ, შედარებითი ასპექტით, ჩვენ შეგვიძლია ვისაუბროთ მხოლოდ კონსოლის რეჟიმში მუშაობაზე, ძირითადი ნაკრების სისტემის და მომხმარებლის კომუნალური საშუალებების გამოყენებით.
და აქ მე არ შემიძლია არ წარმოვთქვა ოდა FreeBSD ტექსტურ კონსოლზე და მისი მართვის ინსტრუმენტებზე. რომელიც მოიცავს მხოლოდ ორ ბრძანებას: vidcontrol და kbdcontrol, რომელთა დანიშნულება ცალსახად გამომდინარეობს სახელებიდან. და რომელიც საშუალებას გაძლევთ დააკონფიგურიროთ აბსოლუტურად ყველაფერი კონსოლში - ეკრანზე სიმბოლოების სიმკვრივიდან (ე.წ. გარჩევადობა) დამთავრებული საზღვრების ფერებამდე, რომლებიც განსხვავებულია თითოეული ვირტუალური ტერმინალისთვის.
Linux-ის მომხმარებელმა ჯერ უნდა გაარკვიოს კონსოლის მართვის ორი პაკეტიდან - kbd თუ კონსოლის ხელსაწყოები - რომელი გამოიყენება მის განაწილებაში. რა თქმა უნდა, ახლა ისინი თითქმის იდენტურია თავიანთი შესაძლებლობებით, მაგრამ თითოეულს აქვს ბრძანებების საკუთარი ნაკრები ოდნავ განსხვავებული სინტაქსით. და ზოგიერთი პარამეტრი (მაგალითად, ტექსტისა და ფონის ფერები) მოითხოვს მას გამოიყენოს ბრძანებები, რომლებიც არ შედის არცერთ პაკეტში. და რაღაც (მაგალითად, იგივე საზღვრის ფერები) კვლავ მიუწვდომელი დარჩება მისთვის.
იგივე ეხება ორივე სისტემის ძირითად ბრძანებებს. FreeBSD Distributions არის მონოლითი, რომელიც მჭიდროდ არის მიბმული ბირთვთან და მოიცავს ყველაფერს, რაც მომხმარებელს შეიძლება დასჭირდეს სისტემის ადმინისტრირებისა და გამოყენებისთვის (და ადგილობრივი დესკტოპის ადმინისტრირება ისეთივე მომხმარებლის ამოცანაა, როგორც ტექსტის დამუშავება ან ფაილების მანიპულირება).
რა თქმა უნდა, Linux-ს აქვს კლასიკური Unix უტილიტების იგივე ნაკრები (უფრო ზუსტად, FreeBSD-ის მსგავსად, მათი კოლეგები). თუმცა, ეს არის ზუსტად დაშლილი პაკეტები, რომლებიც შემუშავებულია GNU Project-ის მიერ, არსებითად დამოუკიდებელი ოპერაციული სისტემისგან. და უკვე ამის გამო, ისინი არც ისე მჭიდროდ არიან ინტეგრირებულნი მასთან და ერთმანეთთან.
რა არის FreeBSD კონსოლის რეჟიმში წამყვანი? ჩემი აზრით, აბსოლუტურად. მაგრამ მხოლოდ იმ შემთხვევაში, თუ ჩვენ ვსაუბრობთ წმინდა ტექსტურ კონსოლზე. თუ თვალს მივაპყრობთ ე.წ. გრაფიკული კონსოლი (განხორციელებული Frame Buffer-ის მიერ), მაშინ ყველაფერი ცოტა სხვანაირად გამოიყურება.
დასაწყისისთვის, FreeBSD გრაფიკული კონსოლი (ე.წ. რასტერული რეჟიმი) შემოიფარგლება ერთი გარჩევადობით 800x600 (აქ საუბარია პიქსელის რეალურ გარჩევადობაზე და არა სიმბოლოების სიმკვრივეზე). და მაშინაც კი, ზოგიერთ ჩიპზე ეს რეჟიმი საერთოდ არ მუშაობს, ზოგზე საკმაოდ საზიზღარი ჩანს. რეალურად, ვერც ერთ ვიდეო ბარათზე ვერ მივაღწიე ნორმალურ შედეგს რასტერულ რეჟიმში.
Linux-ში გრაფიკული კონსოლი უბრალოდ სასიამოვნოა თვალისთვის. VESA-თან თავსებადი აბსტრაქტული ბარათებისთვის Frame Buffer-ის მხარდაჭერითაც კი, რეზოლუციები შეიძლება იცვლებოდეს 640x480-დან 1280x1024-მდე, ფერის სიღრმე კი სტანდარტული დიაპაზონის ფარგლებში იცვლება. ეს უზრუნველყოფს არა მხოლოდ სურათების კომფორტულ ყურებას, არამედ ძალიან ღირსეულ (ჩემი აზრით, ღირსეულზე მეტი) ვიდეოს დაკვრას. ლინუქსის ბირთვში კარგად დანერგილი მშობლიური დრაივერების მქონე ბარათებს (Matrox, ATI, ჩიპსეტი ვიდეო ინტელისგან), ამას ემატება ეკრანის არასტანდარტული რეზოლუციების დაყენების შესაძლებლობა.
ბუნებრივია, არავინ იყენებს კონსოლს სურათების მანიპულირებისთვის და ძალიან ცოტაა ვიდეოების საყურებლად. რატომ ვანიჭებ ასეთ მნიშვნელობას გრაფიკულ კონსოლს? დიახ, იმიტომ, რომ შეუმჩნევლად, მაგრამ მოდის თხევადკრისტალური ჩვენების ეპოქა, რომელიც აღნიშნავს წმინდა ტექსტის რეჟიმის სიკვდილს (მაგრამ არა კონსოლის, როგორც ასეთი). რატომ - ვისაც უნახავს 80x25 სიმბოლოს სტანდარტული ტექსტის რეჟიმი 18 დიუმიან LCD-მონიტორზე, ფიზიკური მატრიცის გარჩევადობით 1280x1024, ადვილად მიხვდება. და როგორ გამოიყურებოდა ის ეკრანზე ასპექტის თანაფარდობით 16: 9, წარმოდგენაც კი მეშინია ...
და ბოლოს, არის კიდევ ერთი შეკითხვა, რომელიც მნიშვნელოვანია მომხმარებლისთვის - შესრულების შესახებ.
მოსაზრება, რომ FreeBSD უფრო სწრაფია, ვიდრე Linux, ისეთივე ტრადიციულია, როგორც მოსაზრება, რომ მისი კონფიგურაცია უფრო რთულია. თუმცა, ყველაფერი ასე ნათელია?
პირველ რიგში, ჩამოტვირთვის სიჩქარე განიხილება, როგორც ერთ-ერთი მთავარი კრიტერიუმი, რომლის კორელაცია განაცხადის შესრულების სიჩქარესთან გარკვეულწილად საეჭვოა. მახსოვს, რომ ოპერაციული სისტემების მნიშვნელოვანი რაოდენობადან, რაც ჩემს ცხოვრებაში ვნახე, MS DOS ყველაზე სწრაფად იტვირთებოდა :-)
მეორეც, მაშინაც კი, თუ ჩატვირთვის სიჩქარეს განვიხილავთ შესრულების ერთ-ერთ კრიტერიუმად, მხოლოდ FreeBSD მე-4 ფილიალი აჯობებს Linux-ს. მეხუთე ფილიალი იტვირთება ზუსტად იმდენ ხანს, როგორც ნებისმიერი Linux დისტრიბუცია, რომელიც იყენებს devfs მოწყობილობის ფაილურ სისტემას. რა თქმა უნდა, კეთილშობილური Linux-ის ოჯახში შეგიძლიათ აირჩიოთ ისეთი წარმომადგენლები, რომლებიც იტვირთება კიდევ უფრო დიდხანს, მაგრამ ეს არის ძალიან მოსახერხებელი სისტემები, დატვირთული ... დამწყებ სერვისების სიმრავლით (კერძოდ, kudzu-ს აპარატურის ავტოდეტექტორი) .
ჩემი წმინდა მომხმარებლის გამოცდილებიდან ვიტყოდი, რომ Linux-სა და FreeBSD-ს შორის მომხმარებლის ამოცანების შესრულების განსხვავება, როგორც წესი, ორგანოლეპტიკურად არ არის შესამჩნევი. ორი გამონაკლისის გარდა, რომელთაგან პირველი არის ფაილური ოპერაციები.
ცხადია, თითოეული OS-ის ფაილური ოპერაციების შესრულებაზე გავლენას ახდენს ორი ფაქტორი - დისკის ქვესისტემასთან ურთიერთქმედების განხორციელება (დესკტოპისთვის - კონკრეტულად ATA ინტერფეისით) და მხარდაჭერილი ფაილური სისტემის (ებ)ის ორგანიზება. და ეს არის ის, სადაც FreeBSD არის არახელსაყრელ მდგომარეობაში Linux-თან შედარებით.
ზემოთ აღინიშნა, რომ CAM-ის წყალობით FreeBSD-ში (ვსაუბრობთ მე-5 განშტოებაზე) მიღწეულია უნივერსალიზმი დისკის კონტროლერებთან მუშაობისას - ისეთი შთაბეჭდილება დამრჩა, რომ ნამდვილად არ აინტერესებს რომელ კონტროლერზეა დისკი (თუ მხოლოდ ის არის აღიარებული. BIOS-ის მიერ - მაგრამ ეს საჭიროა მხოლოდ მისგან ბირთვის ჩასატვირთად.) თუმცა, უნივერსალიზმისთვის უნდა გადაიხადოთ. და როგორც ჩანს, ამ შემთხვევაში გამოთვლა მოდის დისკის ოპერაციების სიჩქარის შემცირების სახით - თუმცა ამ საკითხზე სანდო ინფორმაცია ვერ ვიპოვე, ზოგადი მოსაზრებებიდან გამომდინარე, სიმართლეს ჰგავს.
ეს არის კითხვის პირველი მხარე. მეორე არის FreeBSD ფაილური სისტემა, რომელიც არის UFS და (ნაგულისხმევად მე-5 ფილიალში) მისი გაუმჯობესებული განახლება UFS2. ტრადიციულად, ამ OS-ში ორივე გამოიყენება ნაწილობრივ სინქრონულ რეჟიმში (noasync რეჟიმი), როდესაც ფაილის მეტამონაცემების ცვლილებები დაუყოვნებლივ იწერება დისკზე, ხოლო მონაცემთა ბლოკებში ცვლილებები ინახება RAM-ში.
Linux იყენებს ATA დისკებთან მუშაობის განსხვავებულ მოდელს: სხვადასხვა ტიპის კონტროლერებს აქვთ (ან არ აქვთ) საკუთარი მხარდაჭერა ბირთვში. ეს გამორიცხავს აშკარად მხარდაჭერილი მოწყობილობების გამოყენებას, მაგრამ მხარდაჭერილი მოწყობილობებისთვის, როგორც ჩანს, უკეთეს შესრულებას უზრუნველყოფს. ფაილური სისტემები (და Linux მხარს უჭერს რამდენიმე მათგანს, როგორც მშობლიურ) ნაგულისხმევად, ყველა (შესაძლოა, JFS-ის გარდა) გამოიყენება სრულად ასინქრონულ რეჟიმში (ასინქრონული რეჟიმი), როდესაც ორივე მონაცემი და მეტამონაცემები ინახება RAM-ში.
ამ ფაქტორების კომბინაციის შედეგად, ფაილური ოპერაციები მნიშვნელოვნად უფრო სწრაფია Linux-ზე, ვიდრე FreeBSD-ზე. სინამდვილეში, მე ყოველთვის მეეჭვებოდა ეს, მაგრამ მან მხოლოდ აჩვენა, თუ რამდენად მნიშვნელოვანია ამ მხრივ FreeBSD მე-5 ფილიალის ჩამორჩენა - თუნდაც SoftUpdates მექანიზმი, რომელიც შექმნილია ფაილების მანიპულაციების საიმედოობისა და შესრულების გაზრდისთვის, არ ზოგავს სიტუაციას. სხვათა შორის - FreeBSD მე-4 ფილიალში ასეთი ჩამორჩენა ადრე არ დაფიქსირებულა, რაც ირიბად ადასტურებს დისკის ქვესისტემასთან მუშაობის უარყოფით გავლენას (ამძიმებს სინქრონული ოპერაციების დეგრადაციას) - ის არ იყენებს CAM მოდელს (ყოველ შემთხვევაში, ასე იყო. არ გამოიყენება, როდესაც მე ვიყენებდი). მაგრამ Linux-ში ფაილური სისტემების ექსკლუზიურად ასინქრონული გამოყენებით, ჩემი დაკვირვებით, ფაილებთან მუშაობის სიჩქარე თითქმის არ არის დამოკიდებული დისკის აპარატურის მუშაობაზე.
დაპირებული გამონაკლისებიდან მეორე ეხება სვოპებს. რომლებიც Linux-ზე და FreeBSD-ზე მნიშვნელოვნად განსხვავებულად სრულდება. იმის გასარკვევად, თუ რა არის საკმარისი, გადავხედოთ ზედა ბრძანების გამოსავალს ორივე ოპერაციულ სისტემაში მომხმარებლის საშუალო დატვირთვით. Linux-ში ხედავთ, რომ საკმარისი რაოდენობით ოპერატიული მეხსიერებით, swap-სივრცის გამოყენების პროცენტი ნულისკენ მიისწრაფვის. მაგალითად, ჩემს ლეპტოპზე Linux-ით (512 მბ მეხსიერებით) ამ სტრიქონების დაწერის დროს, KDE ჩატვირთული, html რედაქტორი Quanta, konsole, konqueror-ის ორი ასლი და გაშვებული mplayer (mpeg და RealAudio-ს რეპროდუცირება), swap არ გამოიყენება. საერთოდ. დესკტოპზე FreeBSD-ით (1 გბ მეხსიერებით), იგივე დატვირთვის პირობებში, გამოყენებული სვოპ არე 10%-ზე ნაკლებია, თითქმის არასდროს იკლებს.
ეს გამოწვეულია იმით, რომ Linux მიმართავს შეცვლას მხოლოდ მაშინ, როდესაც RAM სავსეა, ხოლო FreeBSD-ში, ნებისმიერ შემთხვევაში (თუნდაც RAM-ის გადაჭარბებით), მეხსიერების გვერდები, რომლებზეც წვდომა არ ყოფილა გარკვეული პერიოდის განმავლობაში, იცვლება. დისკი. არსებითად, ოპერატიული მეხსიერება ამ OS-ში მოქმედებს, როგორც ერთგვარი ქეში სვოპ ზონისთვის (უფრო ზუსტად, ზოგადად ვირტუალური მეხსიერებისთვის). რაც ეფექტურია შეზღუდული მოცულობის გათვალისწინებით და გამართლებული იყო ძველ დროში, როდესაც პროცესორები ნელი იყო და მეხსიერება მწირი. დღესდღეობით, სვოპის გამოყენების ეს მოდელი ზოგიერთ სიტუაციაში იწვევს მუშაობის შენელებას. ამის მაგალითია KDE დესკტოპების დიდი რაოდენობით და მათ შორის პერიოდული გადართვით, სადაც ასეთი შენელება ჩანს შეუიარაღებელი თვალით.
ყოველივე ეს იწვევს Linux-ის უფრო მაღალ მიზნებს (დადგენილ ტესტებს) და განსაკუთრებით სუბიექტურ შესრულებას FreeBSD-თან შედარებით. თუმცა კიდევ ერთხელ უნდა ხაზგასმით აღვნიშნო - ჩვენ ვსაუბრობთ დესკტოპის სფეროზე: მძიმედ დატვირთულ სერვერზე, FreeBSD ქეშირების მექანიზმს შეუძლია აჩვენოს თავისი ძლიერი მხარეები და ამ სისტემებს შორის სიჩქარის კოეფიციენტები ზოგიერთ შემთხვევაში შეიძლება ზუსტად საპირისპირო აღმოჩნდეს.
ამ სტატიის დასაწყისშივე არ დავპირდი, რომ მის სათაურში დასმულ კითხვაზე ცალსახა პასუხის გაცემას. უფრო სწორედ, პირობა დადო, რომ არ იქნებოდა. მართლაც, ჩემთვის, მე ვერ ვხედავ ცალსახა პასუხს. მაგრამ თავს უფლებას მივცემ, რაღაც მონახაზი გავაკეთო მისთვის.
ის, რაც FreeBSD-ს იგებს არის ა) ინსტალაციის სიმარტივე, ბ) ლოგიკური კონფიგურაცია და გ) ლოკალური მასშტაბის ადმინისტრირების სიმარტივე. თუმცა, იგივე მახასიათებლები (ყოველ შემთხვევაში მათი უმეტესობა) ახლა დამახასიათებელია Linux ოჯახის საუკეთესო (ჩემი აზრით) თანამედროვე წარმომადგენლებისთვის (CRUX და Archlinux, გარკვეულწილად - Gentoo). თუმცა, გასაგები მიზეზების გამო, არ არის აუცილებელი მათგან ველოდოთ FreeBSD-ის შინაგან ჰარმონიასა და მთლიანობას უახლოეს მომავალში.
ამავდროულად, მე ვიცი FreeBSD ფაილური სისტემის არქაული ბუნება, განსაკუთრებით აშკარად ჩანს ReiserFS-ისა და XFS Linux-ის თანამედროვე განხორციელებებთან შედარებით. და თითქმის ერთთვიანი მუშაობა FreeBSD-დესკტოპის და Linux-ლეპტოპის - მანქანების თითქმის თანაბარი ნომინალური წარმადობით - ანუ პირისპირ, მარწმუნებს ამ უკანასკნელის უფრო სწრაფ შესრულებაში. მაგრამ რას უფრო მეტი წონა აქვს მომხმარებლისთვის - ეს ყველამ თავად გადაწყვიტოს. თუმცა, სამწუხაროდ, Linux, როგორც ჩანს, საუკეთესო არჩევანია დესკტოპის გამოყენებისთვის ამ მომენტში.
თუმცა, მინდა ხაზგასმით აღვნიშნო - ამ დროისთვის, რადგან FreeBSD 5.3-ის გამოშვებამ შესაძლოა მნიშვნელოვნად შეცვალოს სიტუაცია. თუმცა, რაც არ უნდა მოხდეს, მსურს მომავალი დავინახო როგორც ორივე ოპერაციული სისტემის ურთიერთგავლენა, ყველა პლიუსის ურთიერთშეთვისება და მინუსების აღმოფხვრა. ამიტომ ჩემს გაწელილ თხრობას საბჭოთა დროის სულისკვეთებით დავასრულებდი ლოზუნგით:
დემონი პინგვინთან ერთად - ძმები სამუდამოდ!
შესავალი
სისტემის დაწყება ორ ეტაპად იყოფა, რომლებიც მხოლოდ ირიბად არის დაკავშირებული ერთმანეთთან - მისი რეალურად ჩატვირთვა და ინიციალიზაცია.
ოპერაციული სისტემის ჩატვირთვა ნიშნავს შესასრულებლად სპეციალური პროგრამის გაშვებას, რომელსაც სისტემის ბირთვის (ან უბრალოდ ბირთვის) გამოსახულება ეწოდება. ბირთვის სურათი თითქმის ჩვეულებრივი ორობითი შესრულებადი ფაილია. და მისი გაშვების სპეციფიკა მხოლოდ იმაში მდგომარეობს იმაში, რომ თუ რაიმე სხვა პროგრამა გაშვებულია ნებისმიერი OS-ის კონტროლის ქვეშ, ფაილური სისტემიდან წაკითხვისას, რომელსაც ეს OS აღიქვამს როგორც მშობლიურ (მშობლიურ), მაშინ ბირთვი უნდა დაიწყოს ისე, თითქოს თავისთავად. , ყოველგვარი ოპერაციული სისტემის გარეშე (რადგან ეს არის ოპერაციული სისტემა) და მედიისგან, რომლის შესახებაც სისტემამ არაფერი იცის (რადგან ის თავად ჯერ არ არის დატვირთული). შემთხვევითი არ არის, რომ ინგლისურ ლიტერატურაში არის საყოველთაოდ მიღებული მეტაფორა ჩექმის პროცესისთვის, სახელწოდებით bootstrapping, რომელიც შეიძლება ისევე ალეგორიულად ითარგმნოს, როგორც "ფეხსაცმლის თასმებით აწევა". და მიუხედავად იმისა, რომ ყველას არ აქვს ეს წარმატება რეალურ ცხოვრებაში, POSIX სისტემების სამყაროში ეს პროცედურა რეგულარულად ტარდება - და, როგორც წესი, წარმატებით.
სისტემის ბირთვის სურათი შეიცავს ყველაფერს, რაც გჭირდებათ სუფთა ჩატვირთვისთვის. თუმცა, ეს შეიძლება შესრულდეს მხოლოდ ამ გზით მედიიდან ფაილური სისტემის გარეშე. და ამიტომ, ბირთვის პირდაპირი გაშვება, რამდენადაც მე ვიცი, გამოიყენება მხოლოდ ფლოპი დისკიდან ჩატვირთვისას. მყარი დისკიდან OS-ის ჩვეულებრივი გაშვებით, ამ საქმეში ასევე ჩართულია გარკვეული გარე ძალა - სპეციალური პროგრამა სახელწოდებით bootloader. ის იტვირთება სისტემის ბირთვს, პასუხისმგებელია ტექნიკის გამოვლენაზე, ობიექტის მოდულების ჩატვირთვაზე (დატვირთული ბირთვის მოდულები) და root ფაილური სისტემის მონტაჟზე (მხოლოდ წაკითხვაზე). იმავდროულად, ბირთვი იწყებს სისტემურ (ანუ, არ არის დაკავშირებული შესრულებად ფაილებთან) პროცესებს, რომლებიც მართავენ ვირტუალურ მეხსიერებას, ბუფერებს, მეხსიერების გვერდებს და ა.შ. რომელიც ასოცირდება დისკზე არსებულ შესრულებად ფაილთან) init პროცესი (/ sbin / init).
ამის შემდეგ ამოქმედდება init სისტემა. მისი როლი არის უზრუნველყოს შესაბამისი გაშვების სკრიპტების საშუალებით (ისინი ასევე არიან ინიციალიზაციის სკრიპტები), ფაილური სისტემების დამონტაჟება (და root-ის ხელახლა დამონტაჟება "წაკითხვის/ჩაწერის" რეჟიმში), ძირითადი სისტემის სერვისების ან დემონების გაშვება, ბრძანებების გამოძახება ტერმინალის მისაღებად. (getty-ის პროცესები) და მომხმარებლის ავტორიზაცია (შესვლა). სისტემის დაწყების დასასრული აღინიშნება ავტორიზაციის მოწვევით.
ვიზუალურად, დატვირთვისა და ინიციალიზაციის ეტაპები განსხვავდება ნაჩვენები შეტყობინებების ამა თუ იმ გზით ვიზუალური წარმოდგენით. მაგალითად, DragonFlyBSD-ში ჩატვირთვის პროგრესის შეტყობინებები ნაჩვენებია რადიკალური თეთრი სიმბოლოებით, რომლებიც ინიციალიზაციის ფაზაში იცვლება ჩვეულებრივი მდუმარე თეთრით.
ჩატვირთვა და ინიციალიზაცია არის პირველი, რასაც მომხმარებელი ხედავს ნებისმიერ OS-ში. მართალია, POSIX-თან თავსებადი სისტემის მომხმარებელი ასეთ სიამოვნებას გაცილებით იშვიათად იღებს, ვიდრე "ფანჯრის რაფა". სახლის Unix აპარატის ნორმალური ფუნქციონირება არის მისი ჩართვა დილით ადრე და გამორთვა გვიან საღამოს. (მართალია, ყველას აქვს საკუთარი წარმოდგენები "ადრეული" და "გვიან" შესახებ). და სერვისის Unix მანქანა საერთოდ არ უნდა გათიშოს - სრულ ფიზიკურ ამორტიზაციამდე. ისე, სისტემის გადატვირთვის აუცილებლობა Linux-ში ან BSD-ში მუშაობისას ძალზე იშვიათია. სინამდვილეში, მხოლოდ ახალი ბირთვის აღდგენისა და ხელახალი ინსტალაციის შემდეგ (ან root დანაყოფის გადაადგილება - მაგრამ ეს ზოგადად გამონაკლისი შემთხვევაა) - სისტემის ხელახალი კონფიგურაციის ყველა სხვა შემთხვევაში, შეგიძლიათ ამის გარეშე.
ასე რომ, როგორც ჩანს, რა აინტერესებს მომხმარებელს, როგორ იწყება სისტემა და რამდენი დრო სჭირდება მას? თუმცა, საჭიროა გარკვეული ნაბიჯები ამ პროცესის ორივე ეტაპის დასაყენებლად. სისტემის დაწყებისას არა მხოლოდ გამოჩნდება ეკრანი და, შესაძლოა, მენიუ ჩატვირთვის ოფციებით, არამედ იტვირთება ბირთვის მოდულები, რომლებიც შეესაბამება არსებულ აპარატურას, დამონტაჟებულია ფაილური სისტემები, გაშვებულია ინიციალიზაციის სკრიპტები, ჩნდება ვირტუალური ტერმინალები. გაიხსნა და ასე შემდეგ და ა.შ. რა თქმა უნდა, ყველა ამ მოქმედებიდან, რა თქმა უნდა, მხოლოდ ბირთვის ფაქტობრივი დატვირთვა არის აბსოლუტურად სავალდებულო - დანარჩენი შეიძლება შესრულდეს მოგვიანებით. თუმცა, არ იქნება უკეთესი სისტემის კონფიგურაცია ისე, რომ მისი გაშვების პროცედურის დასრულებისთანავე მიიღოთ სრულიად მზა სისტემა, ვიდრე მოგვიანებით ხელით მიიყვანოთ ამ მდგომარეობაში?
გარდა ამისა, დატვირთვისა და ინიციალიზაციის პროგრესის გაგება არ იქნება ზედმეტი, თუ ამ პროცესში ხელით ჩაერევით. და ასეთი ჩარევის საჭიროება - სამწუხაროდ - დროდადრო ჩნდება საგანგებო სიტუაციებში ...
მოდით მივყვეთ DragonFly-ის ჩატვირთვისა და ინიციალიზაციის ძირითად ეტაპებს და ვნახოთ, რისი კონფიგურაცია სჭირდებათ, ასევე სად და როგორ (და რაც მთავარია - რატომ) შეიძლება მათ ჩარევა.
ჩატვირთვისა და ჩამტვირთველების შესახებ
მიზანშეწონილია სისტემის დაწყების შესწავლა დაიწყოს მისი პირველი ეტაპიდან - კერძოდ, რეალური დატვირთვით. როგორც უკვე აღვნიშნეთ, ამ ეტაპებს აკონტროლებს სპეციალური პროგრამა, რომელსაც რუსულად Bootloader ჰქვია. თუმცა ინგლისურად ამისთვის გამოიყენება ორი ტერმინი - loader და boot manager (რაც, როგორც დროთა განმავლობაში დავინახავთ, ოდნავ განსხვავებული რამაა, მაგრამ ახლა ეს არ არის მნიშვნელოვანი).
სინამდვილეში, ნებისმიერი ჩამტვირთველი მოიცავს ორ ან თუნდაც სამ შედარებით დამოუკიდებელ ნაწილს - თუნდაც განაწილებული იყოს როგორც ერთი პაკეტი, როგორიცაა Lilo ან GRUB. ამაში რომ დავრწმუნდეთ, წარმოვიდგინოთ, როგორ იშლება მანქანა „რკინის“, ასე ვთქვათ, დონეზე (იგულისხმება - ინტელთან თავსებადი პერსონალური მანქანა, სხვა არქიტექტურებზე ყველაფერი ცოტა სხვაგვარადაა).
უპირველეს ყოვლისა, კვების ბლოკის ჩართვის შემდეგ, ამოქმედდება პროგრამა, რომელიც ციმციმდება კომპიუტერის ROM-ში (BIOS). ის ამოწმებს აპარატურას, რის შემდეგაც პოულობს BIOS Setup-ში დაყენებულ მედიას, როგორც პირველ ჩატვირთვის მოწყობილობას (კონკრეტულად, მყარი დისკი), მასზე არის პირველი ფიზიკური ბლოკი, რომელიც შეიცავს ე.წ. Master Boot Record (MBR).
MBR-ის შინაარსი, პირველ რიგში, არის დისკის დანაყოფების ცხრილი, ოთხივე, რომელთაგან ერთ-ერთში ჩვენ ადრე დავაინსტალირეთ DragonFly. და მეორე - ზოგიერთი კოდი, რომელიც აკონტროლებს BIOS-ს მუშაობის ბოლოს. სტანდარტულ MBR-ში - ანუ ის იწერება "ახლად ხრახნილ" მყარ დისკზე ან აღდგენილია DOS-ის ბრძანების FDISK/mbr-ის შემდეგ - ამ კოდს შეუძლია მხოლოდ დისკის პირველი ფიზიკური დანაყოფის პოვნა (პირველადი დანაყოფი) და გადაცემის კონტროლი. მის ჩატვირთვის სექტორში. რაც სავსებით საკმარისია ოპერაციული სისტემების ჩატვირთვისთვის, როგორიცაა DOS ან Windows 9X / ME პირველი (ან მხოლოდ) დანაყოფიდან. მაგრამ აშკარად არ არის საკმარისი სხვა შემთხვევაში - მაგალითად, თუ დისკზე დაინსტალირებულია რამდენიმე ოპერაციული სისტემა, რომელიც, რა თქმა უნდა, ვერ ჯდება ერთ დანაყოფში.
ამიტომ, ნებისმიერი ჩამტვირთველი უნდა შეიცავდეს პროგრამას დაწერილი MBR-ზე. ვინაიდან ამ უკანასკნელის მოცულობა არის მხოლოდ 512 კბაიტი (ფიზიკური დისკის ბლოკის ზომა), რომელთაგან ზოგიერთი უკვე დაკავებულია დანაყოფის ცხრილით, ეს პროგრამა ვერ ახერხებს განსაკუთრებით მდიდარ ფუნქციებს. ჩვეულებრივ, მას შეუძლია ყველა გამოყენებული პირველადი დანაყოფის იდენტიფიცირება, მათი ჩამოთვლა და ნება მომხმარებელს აირჩიოს დანაყოფი ჩატვირთვისთვის და შემდეგ გადაიტანოს კონტროლი არჩეული დანაყოფის ჩატვირთვის სექტორში.
MBR-ის მსგავსად, დანაყოფის ჩატვირთვის სექტორი (Boot Record აღარ არის Master!) შეიცავს ინფორმაციას მისი დანაყოფის შესახებ (Disk Label), რაც დამოკიდებულია ამ OS-ში გამოყენებულ სქემაზე და საკონტროლო კოდზე, რომელიც აღებულია პროგრამაში ჩაწერილი. MBR. და ეს კოდი არის ჩამტვირთველის მეორე ნაწილი. მართალია, მისი შესაძლებლობები ასევე არ შეიძლება იყოს მდიდარი - ბოლოს და ბოლოს, დანაყოფის ჩატვირთვის სექტორის ზომა იგივეა 512 KB. და ამიტომ, მას აქვს მხოლოდ ერთი ფუნქცია - გადაიტანოს კონტროლი პროგრამაზე, რომელიც დევს ჩატვირთვის სექტორის მიღმა. რომელიც, ფაქტობრივად, უნდა იდენტიფიცირება OS root დანაყოფი და ფაილური სისტემა მას ატარებს, და შემდეგ, პირდაპირ ან ირიბად, ჩატვირთოს მისი ბირთვი.
ადვილი მისახვედრია, რომ ჩატვირთვის პირველ ორ კომპონენტს, ფაქტობრივად, არანაირი კავშირი არ აქვს რომელიმე ოპერაციულ სისტემასთან და საერთოდ არ არის ფაილური სისტემის ნაწილი. მაგრამ მესამე - ვარიანტები შესაძლებელია. ის შეიძლება შევიდეს ჩამტვირთავი OS-ის ფაილურ იერარქიაში, როგორიცაა Lilo, ან შეიძლება იყოს რაღაც დამოუკიდებელი მინი-OS, როგორიცაა GRUB (შემთხვევითი არ არის, რომ მკაცრად არის რეკომენდებული მისი დაყენება საკუთარ დისკის დანაყოფზე, რომელიც ნაგულისხმევად არ არის დამონტაჟებული რომელიმე ოპერაციული სისტემის root-ზე, რომელსაც ის ჩაიტვირთება). და რაც შეეხება ჩვენი გმირის ჩამტვირთველ მოწყობილობას - DragonFlyBSD?
ჩატვირთვის ეტაპები
ამ OS-ში გამოიყენება პროგრამა სისტემის ჩატვირთვისთვის, რომელიც საერთოა ყველა BSD ოპერაციული სისტემისთვის. მას აქვს საკუთარი სახელი და სახელი, უცნაურად საკმარისია, არის BSD Loader (თუმცა, როგორც ცოტა მოგვიანებით გაირკვევა, ეს გარკვეულწილად თვითნებურია).
უნდა მოვინანიო - FreeBSD-თან რამდენიმეწლიანი კომუნიკაციისა და მის დებთან (OpenBSD და თუნდაც NetBSD) დროდადრო გაცნობის გამო, რატომღაც არ მქონდა მიზეზი მათი ჩამტვირთველის მოწყობილობასთან გამკლავება. ისე, ის მშვენივრად იტვირთება მშობლიურ სისტემას - და შესანიშნავად (მაგალითად, FreeBSD). ის ასევე იტვირთება სხვა BSD სისტემებს - კიდევ უკეთესი. ის, რომ Linux-ს შეუძლია სტრესის გარეშე ჩატვირთვა, ზოგადად ძალიან კარგია. და ის, რაც ასევე შეუძლია Windows-ის ჩატვირთვას, მხოლოდ უფასო აპლიკაციაა ...
როგორც ბედნიერი იგნორირება ვიქნებოდი, თუ როგორმე, FreeBSD-ის Toshiba-ს ლეპტოპზე დაყენებასთან დაკავშირებით, BSD Loader-ის ოფციებით ცოტა არ იყოს გათხრა. და შემდეგ აღმოჩნდა, რომ ეს არის პროგრამა ძლიერი ინტერაქტიული შესაძლებლობებით და პერსონალურად მორგების შესაძლებლობითაც კი. რა თქმა უნდა, არ შევადაროთ GRUB-ს, მაგრამ თუ არ ჩაატარებთ მრავალ მყარ დისკზე მრავალრიცხოვან ოპერაციულ სისტემას, ჩამტვირთავი ფუნქციები საკმარისზე მეტია. რის დემონსტრირებას შევეცდები ქვემოთ DragonFlyBSD OS-ის მაგალითის გამოყენებით. თუმცა, თითქმის ყველაფერი, რაც ითქვა, მართალია ყველა სხვა BSD სისტემისთვის (და FreeBSD - და "თითქმის" პუნქტის გარეშე).
DragonFly boot loader-ის მთავარი მახასიათებელი (თუმცა თითქმის ყველაფერი, რაც ითქვა, მოქმედებს ყველა სხვა BSD სისტემისთვის - და FreeBSD-სთვის და დათქმის გარეშე "თითქმის"), რაც განასხვავებს მას Lilo-სგან და, უფრო მცირე ზომით, GRUB-ისგან, არის ის, რომ ის არ ფარავს მის მრავალკომპონენტიან ბუნებას, მათ შორის ოთხი (თითქმის) დამოუკიდებელი პროგრამის ჩათვლით.
ჩამტვირთველის პირველი ნაწილი (ე.წ. boot0) არის პროგრამა, რომელიც იწერება სისტემის ინსტალაციის დროს დისკის ჩატვირთვის სექტორში, საიდანაც ჩაიტვირთება მანქანა BIOS-ის პარამეტრების მიხედვით. ჩვეულებრივ, ეს არის Master პირველ IDE არხზე (აქ არ ვისაუბრებთ SCSI დისკებზე), მაგრამ ვარიანტები შესაძლებელია (მაგალითად, თუ გაქვთ აპარატურა ATA RAID ან დამატებითი ATA კონტროლერები). ეს პროგრამა პასუხისმგებელია ჩატვირთვის ეტაპის პირველ ეტაპზე, რომელიც კითხულობს დისკის ძირითადი დანაყოფების ცხრილს, აჩვენებს მათ სიას (თუ არის ერთზე მეტი დანაყოფი), მომხმარებლის არჩევისთვის გარკვეული ლოდინის პერიოდი (ნაგულისხმევად, წინა სესიაზე არჩეული დანაყოფი იქნება ჩამტვირთავი) და ამის შემდეგ (ან ფიქსირებული ლოდინის პერიოდის შემდეგ), კონტროლის გადატანა არჩეული (ან ნაგულისხმევი) დანაყოფის ჩატვირთვის სექტორში დაწერილ კოდზე. განყოფილება შეირჩევა ღილაკების დაჭერით F1—F4). თუ ორი დისკია, დააჭირეთ ღილაკს F5ის უბრალოდ გადასცემს კონტროლს მეორე მათგანის ჩატვირთვის სექტორში - და იქ მოვლენები მიედინება იმისდა მიხედვით, თუ რა წერია მასში: თავად boot0-ს არ შეუძლია წაიკითხოს დანაყოფები მეორე ფიზიკურ დისკზე.
დანაყოფების სიაში შედის მათი სახელები ფაილური სისტემის ტიპის იდენტიფიკატორების მიხედვით, მაგალითად:
F1 DOS F2 Linux F3 BSD F5 Drive 1
ბოლო დრომდე, BSD Loader-ს არც გაფართოებული DOS-ის შიგნით არსებული ლოგიკური დანაყოფების ამოცნობა შეეძლო და არც ოპერაციული სისტემის ჩატვირთვა მათგან. თუმცა, ახლა სიტუაცია აშკარად შეიცვალა: ეს შეიძლება დავასკვნათ შეტყობინებებიდან DragonFlyBSD გაფართოებულ განყოფილებაში დაყენების შესაძლებლობის შესახებ (ერთადერთი, რამდენადაც მე ვიცი, BSD სისტემებიდან, რომელსაც შეუძლია ამის გაკეთება). შესაძლებელია თუ არა სისტემის ინსტალაციის წარმოდგენა სტანდარტული საშუალებებით ჩატვირთვის შესაძლებლობის გარეშე?
პრინციპში, BSD ჩამტვირთველის პირველი ნაწილის არსებობა არასავალდებულოა: ის შეიძლება შეიცვალოს Linux-ის ჩამტვირთველით (იგივე Lilo, რომელიც კონტროლს გადასცემს BSD slice ჩატვირთვის სექტორს "ჯაჭვში") ან მულტი- სისტემა GRUB, რომელსაც უშუალოდ შეუძლია იმუშაოს ფაილურ სისტემებთან და იტვირთოს ბირთვები სხვადასხვა ოპერაციული სისტემებით.
მეორე ნაწილი (boot1) განთავსებულია პირველადი დანაყოფის ჩატვირთვის სექტორში, რომელიც ატარებს BSD სისტემას (BSD slice). ანუ, boot0 და boot1 დევს არა მხოლოდ ფაილური სისტემის მიღმა, არამედ, ფაქტობრივად, თავად BSD ნაჭერის გარეთ. მესამე ნაწილი (boot2) უკვე დევს ნაჭერის შიგნით, მაგრამ არ შედის მის არცერთ ლოგიკურ დანაყოფში.
ჩამტვირთველის მეორე და მესამე ნაწილები, არსებითად, არის ერთი პროგრამა, რომელიც იყოფა მხოლოდ დანაყოფის ჩატვირთვის სექტორის ზომის შეზღუდვების გამო (512 ბაიტი). ასე რომ, boot1 ამოცანა მოიცავს მხოლოდ BSD ნაჭრის იდენტიფიცირებას, მასზე boot2-ის პოვნას და მასზე კონტროლის გადაცემას. და მან, ცოტა ხნის ლოდინის შემდეგ, უნდა დაადგინოს root ფაილური სისტემა, იპოვოს მასზე და გაუშვას ორობითი შესრულებადი ფაილი - / boot / loader, რომელიც ქმნის ჩამტვირთველის მეოთხე ნაწილს; მკაცრად რომ ვთქვათ ტერმინი BSD ჩამტვირთავივრცელდება მხოლოდ ამ პროგრამაზე.
ამრიგად, თქვენ ხედავთ, რომ BSD ჩამტვირთველის პირველი სამი ნაწილი (boot0, boot1 და boot2) მდებარეობს დაინსტალირებული BSD OS-ის ფაილური სისტემების გარეთ. რომელშიც ვიღებთ მხოლოდ ჩამტვირთველის გაშვებიდან დაწყებული, რეგულარული შესრულებადი ფაილი, რომელიც მოთავსებულია root ფაილური სისტემის სპეციალურ დირექტორიაში / ჩატვირთვაში.
მართალია, / boot დირექტორიაში (ეს არის ჩამტვირთველის "ნაგულისხმევი" ადგილმდებარეობა), მის შესრულებად ფაილთან ერთად, ასევე შეგიძლიათ ნახოთ ფაილები სახელწოდებით boot0, boot1 და boot2. მაგრამ ისინი მხოლოდ შესაბამისი კოდის ასლებია, რომლებიც მდებარეობს (და მუშაობს) BSD ფაილური სისტემის გარეთ. მათი მიზანია გადაუდებელი შემთხვევების შემდეგ ჩატვირთვის უნარის აღდგენა.
ჩამტვირთველის ამოცანაა ბირთვის და ნაგულისხმევი მოდულების ნაკრების სწრაფად ჩატვირთვა, რის შემდეგაც იგი აჩვენებს მის მენიუს პროექტის ლოგოთი, რომელზედაც შეგიძლიათ ამოიცნოთ ჭრიჭინა (ეშმაკი ჩაანაცვლეთ ფრიბსდ-დან პიტჩფორკით). მენიუ შეიცავს შემდეგ ელემენტებს:
- ჩატვირთეთ DragonFly- ბირთვის ნორმალური ჩატვირთვა ყველა დაყენებული (ვის მიერ და სად არის - განხილული) მოდულით, ფაილური სისტემების დამონტაჟება და დადგენილი გაშვების სკრიპტების დამუშავება;
- ჩატვირთეთ DragonFly ACPI გამორთულით- იგივე, მხოლოდ acpi მოდულების გამორთვის შემთხვევაში, რაც ზოგჯერ შეიძლება საჭირო გახდეს ზოგიერთ ლეპტოპზე;
- ჩატვირთეთ DragonFly უსაფრთხო რეჟიმში- ჩატვირთვა უსაფრთხო რეჟიმში, ანუ მოდულების შეერთების გარეშე;
- ჩატვირთეთ DragonFly ერთი მომხმარებლის რეჟიმში- ჩატვირთვა ერთი მომხმარებლის რეჟიმში, რომელშიც დამონტაჟებულია მხოლოდ root ფაილური სისტემა (და მაშინაც კი მხოლოდ წაკითხვისთვის) და ინიციალიზაციის ეტაპი იგნორირებულია;
- ჩატვირთეთ DragonFly ხმამაღალი ჭრით- ნორმალური ჩამოტვირთვა, მაგრამ დეტალური შეტყობინებების გამომავალი;
- გაქცევა ჩამტვირთველის მოთხოვნაზე- გასვლა bootloader ბრძანების ხაზში;
- გადატვირთვა- კარგი, ეს ჩვენ ვიცით, როგორც სამი თითი, მხოლოდ უკეთესი.
თუ არჩევანს არ გააკეთებთ, ნაგულისხმევი ვარიანტი ათ წამში დაიწყებს ჩატვირთვას. რისი თავიდან ასაცილებლად (და მეტი დრო მიიღეთ ფიქრისთვის), უბრალოდ დააჭირეთ Spacebar- ათვლა შეჩერდება და არ იქნება გადმოტვირთვა მკაფიო არჩევამდე.
შერჩევის ან შეზღუდვის ვადის გასვლის შემდეგ, იწყება ტექნიკის იდენტიფიკაციის საკმაოდ ხანგრძლივი პროცესი, რომლის დროსაც ეკრანზე გამოსახულია მრავალი ბირთვის შეტყობინება - ჩვეულებრივი შეტყობინებებისგან განსხვავებით - სიმბოლოების ნათელი თეთრი "ფერი". ეს შეტყობინებები ძალიან საინტერესოა, მაგრამ არც ისე ადვილი წასაკითხი. რაც, თუმცა, არ არის საშინელი - მომავალში მათი ნახვა შესაძლებელია dmesg ბრძანებით. ამის შემდეგ, დამონტაჟდება root ფაილური სისტემა და მისგან (ჩვეულებრივი შესრულებადი ფაილით / sbin / init) იწყება init პროცესი, შესრულებულია გაშვების სკრიპტები. ამის აღსანიშნავად, ბირთვის შეტყობინებების ნათელი თეთრი ფერი იცვლება ჩვეულებრივ ნაცრისფერში - ჩატვირთვის ფაზა, რომელიც ჩვენ ამ მომენტში გვაინტერესებს, დასრულდა.
ჩატვირთვის პროცესის ინტერაქტიული კონტროლი
ჩნდება კითხვა - შეუძლია თუ არა მომხმარებელს გავლენა მოახდინოს ჩამოტვირთვის პროცესზე? პასუხი იქნება დიახ. ჩატვირთვის სისტემის მუშაობისას მომხმარებელს სამჯერ ეძლევა არჩევანის თავისუფლება: boot0-ის საწყის ეტაპზე ჩატვირთვის დანაყოფის არჩევა, boot2 ეტაპზე ინტერაქტიული კონტროლის არჩევა და ჩატვირთვის რეჟიმის არჩევა ჩატვირთვის დაწყებისთანავე. და ყველა ამ შემთხვევაში მომხმარებელს შეუძლია ხელით ჩაერიოს პროცესში. Რისთვის? ეს სხვა კითხვაა და მასზე პასუხი, იმედია, მომდევნო პრეზენტაციიდან გაირკვევა.
ჩატვირთვის განყოფილების არჩევით, ყველაფერი ნათელია: ის საშუალებას გაძლევთ ჩატვირთოთ ერთ-ერთი OS, თუ რამდენიმე მათგანი დაინსტალირებულია მოცემულ მანქანაზე. მაგრამ boot2 ოპერაციის ეტაპზე შეგიძლიათ შეწყვიტოთ მისი შესრულება, უფრო სწორად, თავიდან აიცილოთ ჩამტვირთველის დაწყება. ამისათვის, BSD დანაყოფიდან ჩატვირთვის არჩევასა და ბირთვისა და მოდულების ჩატვირთვის შესახებ შეტყობინებების გამოჩენას შორის პაუზაში (ეს პაუზა მონიშნულია ეკრანზე მოციმციმე _ სიმბოლოს გამოჩენით), დააჭირეთ ნებისმიერ ღილაკს. საპასუხოდ, მოჰყვება ფორმის მოთხოვნა:
>> BSD / i386 BOOT ნაგულისხმევი: 0: რეკლამა (0, a) / boot / loader boot:
და სწრაფი ხაზი, შეგიძლიათ მიუთითოთ ჩატვირთვის ვარიანტი, გარდა ნაგულისხმევი. მაგალითად, შეგიძლიათ პირდაპირ ჩატვირთოთ სისტემის ბირთვის გამოსახულების ფაილი. ამას შეიძლება ჰქონდეს გარკვეული აზრი ბირთვის აღდგენის შემდეგ - თუ ახალი არ არის საკმარისად კონფიგურირებული ჩატვირთვისთვის (მაგრამ - სამწუხაროდ - საკმარისია კომპილაციისთვის).
ამისათვის თქვენ უნდა ააწყოთ გზა ძველი ბირთვისკენ ნაგულისხმევი ვერსიის გამოსახულებაში და მსგავსებაში. ანუ მიუთითეთ:
- დისკის ნომერი მანქანაში იმის მიხედვით, რაც BIOS-ს ესმის (0 - ნაღდი ფულის პირველი, 1 - მეორე და ასე შემდეგ, კავშირის რიგის მიუხედავად);
- მისი ინტერფეისი - რეკლამის მაგალითში სიმბოლოა ATA დისკი (SCSI დისკისთვის ეს იქნება da, ფლოპი დისკისთვის - fd);
- IDE არხის ნომერი (0 - master, 1 - slave);
- დანაყოფი იმ გაგებით, რომელსაც იყენებს BSD Label, ეს არის ნაწილის ნაწილი, რომელიც დაცულია BSD root ფაილური სისტემისთვის (a;
- ძველი ბირთვის გამოსახულების ფაილის სახელია /kernel.old.
თუ დისკზე არის სხვადასხვა ტიპის რამდენიმე ძირითადი დანაყოფი, მაშინ არა-BSD ტიხრები გამოტოვებული იქნება და ასო a (ცხადია, ბირთვის სურათი შეიძლება იყოს მხოლოდ root ფაილურ სისტემაში) მიუთითებს ნაჭერის პირველ ქვეგანყოფილებაზე. იდენტიფიკატორი 165 (თუნდაც ის მეოთხე იყოს).
თუ ეჭვი გაქვთ ფაილის ზუსტ სახელთან დაკავშირებით (და შესაძლოა რამდენიმე მათგანი იყოს - ყოველი ახალი შეუმოწმებელი ბირთვის დაყენებამდე, რეკომენდებულია წინა ასლის გაკეთება, აშკარად გამოსადეგი), შეგიძლიათ შეიყვანოთ კითხვის ნიშანი მოთხოვნის ხაზში. , რომლის პასუხი იქნება root დირექტორიას სია (მაგრამ არა უფრო ღრმა - შიგთავსის ქვედირექტორიების ნახვა, თუნდაც იმავე ფაილურ სისტემაში, boot2-ზე ვერ მოხერხდება).
თუმცა, იგივე პროცედურა - ძველი ბირთვის ჩატვირთვა - შეიძლება (და უნდა იყოს, რადგან ეს ბევრად უფრო ადვილია) ჩამტვირთველის მეშვეობით შესრულდეს და ახლა გადავდივართ მისი ინტერაქტიული შესაძლებლობების გათვალისწინებაზე.
ჩამტვირთავი მენიუ გთავაზობთ რეჟიმების საკმარის არჩევანს სტანდარტული სიტუაციებისთვის, მაგრამ ის აშკარად არ მოიცავს ყველა არასტანდარტულს (სწორედ ამიტომ არიან). კერძოდ, მენიუში არ არის გათვალისწინებული ძველი ბირთვის ჩატვირთვის ვარიანტი. საბედნიეროდ, მენიუს ბოლო პუნქტი წყვეტს ამ პრობლემას (და მასთან ერთად ბევრ სხვასაც).
ასე რომ, მენიუს მეექვსე ელემენტის არჩევა - გაქცევა ჩამტვირთველის მოთხოვნაზე, - ჩვენ აღმოვჩნდებით ბრძანების თარჯიმანი loader 'a-ს გარემოში. მას აქვს გარსის მსგავსი ინტერფეისი - ბრძანებები თავიანთი ოფციებით და არგუმენტებით შეიყვანება მოთხოვნის შემდეგ, რომელიც ჰგავს
ინტერაქტიული მუშაობის მოხერხებულობის თვალსაზრისით - არა GRUB, რა თქმა უნდა: არც ავტომატური დასრულება და არც ბრძანების ისტორია, რედაქტირების შესაძლებლობები შეზღუდულია გასაღებით Backspace... მაგრამ მისი მთავარი როლით - ჩაშენებული ბრძანებების შეყვანა და შესრულება - მტვირთავი საკმაოდ კარგად უმკლავდება.
უფრო მეტიც, ამ ბრძანებებიდან საკმაოდ ბევრია: მათი სრული ჩამონათვალის მიღება შესაძლებელია ბრძანების სტრიქონში კითხვის ნიშნის შეყვანით. ასევე ხელმისაწვდომია დახმარება - დახმარების ბრძანება მოგცემთ მოკლე მინიშნებას, help command_name - უფრო დეტალური ინფორმაცია ბრძანება-არგუმენტის გამოყენების შესახებ. თუმცა, ბრძანების სინტაქსი ასევე ჭურვის მსგავსია, ამიტომ ამაში სირთულეები არ უნდა იყოს.
ჩაშენებული ჩამტვირთავი ბრძანებები შეიძლება დაიყოს სამ ნაწილად მათი მიზნის მიხედვით:
- ინფორმაციის მისაღებად;
- ჩამტვირთველის კონფიგურაცია;
- რეალურად ჩატვირთვის პროცესის გასაკონტროლებლად.
ბრძანებების პირველი ჯგუფიდან გაითვალისწინეთ შემდეგი: ls, lsdev, lsmod, show, სხვა. პირველი განკუთვნილია ძირეული ფაილური სისტემისა და მისი ქვედირექტორიების სანახავად, თუმცა, მხოლოდ ის, ვინც არ არის ცალკეულ ქვეგანყოფილებებში. მაგრამ რადგან ჩატვირთვისთვის აუცილებელი ყველა ფაილი არის თავად root-ის ქვედირექტორიებში (in / boot, / dev, / მოდულები), ეს შეზღუდვა არ არის მნიშვნელოვანი. ls -l ბრძანების ოფცია ჩამოთვლის ფაილებს (და დირექტორიებს) მათი ზომით - ამ ოფციის გარეშე დირექტორიები მხოლოდ d-ით არის მონიშნული.
lsdev ბრძანება ჩამოთვლის დისკის მოწყობილობებს მანქანაზე, მათ ძირითად დანაყოფებსა და ქვეკლავიშებს (ეს უკანასკნელი განკუთვნილია მხოლოდ BSD Label-ის წესების მიხედვით ეტიკეტირებული ტიხრებისთვის). -v ვარიანტი უზრუნველყოფს სიტყვიერ გამომავალს.
lsmod ბრძანება აჩვენებს ჩამტვირთველის მიერ დატვირთულ მოდულებს მენიუს (ან ბრძანების სტრიქონის) გამოჩენამდე. როგორც წინა შემთხვევაში, არსებობს სიტყვიერების ვარიანტი - -v.
შოუ ბრძანება ასრულებს მსგავს ფუნქციას, მაგრამ ჩამტვირთველის ცვლადებისთვის. არგუმენტის გარეშე მოცემული, ის ბეჭდავს მნიშვნელობებს ყველა განსაზღვრული ცვლადისთვის. თუ არგუმენტად მიუთითებთ ცვლადის სახელს, ნაჩვენები იქნება მხოლოდ მისი მნიშვნელობა. ნებადართულია მრავალი არგუმენტი, გამოყოფილი მძიმით.
ისე, მეტი აკეთებს იგივეს, რაც მისი Unix კომუნალური სახელწოდება. ის საშუალებას გაძლევთ ნახოთ ტექსტური ფაილის შინაარსი - ანუ, ჩამტვირთავი გარსში ყოფნისას, ჩვენ შეგვიძლია გავეცნოთ კონფიგურაციას, რომელიც მნიშვნელოვანია ჩატვირთვისთვის (და ნებისმიერი სხვა).
კონფიგურაციის ბრძანებები საშუალებას გაძლევთ განსაზღვროთ ან წაშალოთ ჩამტვირთველის ცვლადები, ჩატვირთოთ ან წაშალოთ ბირთვის მოდულები. როგორც უკვე აღვნიშნეთ, თავად ბირთვი მოდულებისა და ცვლადების გარკვეული წინასწარ განსაზღვრული ნაკრებით იტვირთება ჩამტვირთავი მენიუს და მისი ბრძანებების ინტერპრეტაციის წინ. ასე რომ, შესაბამისი ბრძანებების დახმარებით, ეს წინასწარ განსაზღვრული ნაკრები შეიძლება ოდნავ მორგებული იყოს (ან მთლიანად შეიცვალოს). ეს შეიძლება საჭირო გახდეს, თუ ბირთვის ნაგულისხმევი კონფიგურაცია არ არის ჩატვირთული რაიმე მიზეზით (ჩვეულებრივი შემთხვევაა კონფლიქტი ნოუთბუქის ენერგიის დაზოგვის სისტემებსა და ACPI სისტემის მოდულებს შორის), გამართვის მიზნით, ან უბრალოდ ცნობისმოყვარეობის დასაკმაყოფილებლად.
მოდით, ჯერ გადავხედოთ მოდულების მართვის ბრძანებებს. ეს არის დატვირთვისა და განტვირთვის ბრძანებების წყვილი მოდულების ჩატვირთვისა და ამოღების მიზნით. პირველი გამოიყენება არგუმენტთან module_name, რომელიც, საჭიროების შემთხვევაში, შეიძლება დაფიქსირდეს (ls-ის გამოყენებით) / modules დირექტორიაში - არგუმენტში სახელი მოცემულია * .ko სუფიქსის გარეშე. განტვირთვის ბრძანება იგივე არგუმენტით ამოიღებს მითითებულ მოდულს, არგუმენტების გარეშე - ის მთლიანად წაშლის ყველა მოდულს, რაც საშუალებას მოგცემთ დაიწყოთ ნულიდან კონფიგურაციაში.
ჩატვირთვის და განტვირთვის ბრძანებები ასევე ვრცელდება ბირთვზე მთლიანობაში. ასე რომ, ბრძანების საშუალებით
OK ბირთვის განტვირთვა
შეგიძლიათ გადმოტვირთოთ ნაგულისხმევი ბირთვი მეხსიერებიდან (მაგალითად, თუ აღმოჩნდა, რომ ის უმოქმედოა) და ბრძანების გამოყენებით
OK ჩატვირთვა kernel.old
ჩატვირთეთ ძველი, სამუშაო ბირთვი.
მსგავსი მიზნების წყვილი - დაყენებული და დაუყენებელი - ასევე არსებობს ჩამტვირთველის გარემოს ცვლადებისთვის. ეს ცვლადები გამოიყენება მიმდინარე დისკის მოწყობილობის შესაცვლელად, ძირეული ფაილური სისტემის მდებარეობის დასაზუსტებლად, ბირთვის მოდულების ბილიკების განსაზღვრისთვის, გარდა ნაგულისხმევი / მოდულებისა და ა.შ. ეს კეთდება set ბრძანებით C-shell სინტაქსის შესაბამისად, მაგალითად:
OK მითითებული currdev = "disk1s1a"
განსაზღვრავს მიმდინარე დისკის მოწყობილობას "დისკის # _slice # _section" თვალსაზრისით.
ერთი ცვლადისთვის დაშვებულია რამდენიმე მნიშვნელობა - ისინი გამოყოფილია მძიმით. Მაგალითად,
OK set module_path = "/; / modules; mymodule_path"
განსაზღვრავს ბირთვის მოდულების მდებარეობას - root, ნაგულისხმევი მოდულების დირექტორია და / mymodule_path დირექტორია: აშკარაა, რომ თუ ამ ცვლადში უბრალოდ განსაზღვრავთ გზას თქვენი საკუთარი მოდულებისკენ, ინფორმაცია ნაგულისხმევი მოდულების ადგილმდებარეობის შესახებ დაიკარგება. . თქვენს ყურადღებას ვაქცევ მნიშვნელობის არსებობას / ცვლადის განმარტებაში - ეს გზა საჭიროა ბირთვის ჩატვირთვისთვის load ბრძანების გამოყენებით (DragonFlyBSD-ში ბირთვი ნაგულისხმევად არის დაინსტალირებული root დირექტორიაში).
ზოგიერთი ცვლადი უბრალოდ ჩართავს ან გამორთავს ზოგიერთ მოქმედებას და, შესაბამისად, მათი ლოგიკური მნიშვნელობები - YES ან NO. ბუნებრივია, მათ სჭირდებათ მარცვლოვანი ცვლადები, რათა განისაზღვროს რა არის მათ მიერ დაშვებული. მაგალითად, ცვლადი
OK დააყენეთ userconfig_script_load = "დიახ"
მხოლოდ პერსონალური კონფიგურაციის სკრიპტების და ცვლადის შესრულების საშუალებას იძლევა
OK დააყენეთ userconfig_script_name = "/ boot / my.conf"
განსაზღვრავს რომელი სცენარი უნდა იქნას გამოყენებული ამ შემთხვევაში.
ცვლადების გამოყენებით, თქვენ ასევე შეგიძლიათ განსაზღვროთ ჩატვირთვის რეჟიმები. მაგალითად, ცვლადის დაყენების შემდეგ
OK დააყენეთ boot_single
ცვლადის განმარტება შეიძლება გაუქმდეს ბრძანებით
ცვლადის_სახელის გაუქმება
ზოგიერთ შემთხვევაში, მისი ექვივალენტი იქნება ცვლადის განსაზღვრა NO ლოგიკური მნიშვნელობით ან სიტყვის disable სახელში.
ჩამტვირთველის ჩაშენებული გარემოს ცვლადების სრული სია შეგიძლიათ იხილოთ შესაბამის man გვერდზე:
$ კაცი 8 მტვირთავი
და ბოლოს, ჩამოტვირთვის კონტროლის ბრძანებები. მათგან ყველაზე მნიშვნელოვანი არის ჩატვირთვა, რომელიც, ოფციების და არგუმენტების გარეშე, იწვევს ბირთვის დაუყოვნებლივ ჩატვირთვას ნაგულისხმევი ან მიმდინარე (ანუ გადატვირთული ცვლადების და მოდულების) კონფიგურაციით. / p>
ჩატვირთვის ბრძანების პარამეტრები განსაზღვრავს ჩატვირთვის რეჟიმს. მაგალითად, ბრძანება
OK boot -s
გამოიწვევს ჩატვირთვას ერთი მომხმარებლის რეჟიმში. ეს უდრის იგივე ბრძანების გაშვებას ოფციების გარეშე, მანამდე დაყენებული boot_single ცვლადი.
ჩატვირთვის ბრძანების არგუმენტებში შეიძლება მიუთითოთ ბირთვის სურათის სახელი, შესრულებადი ჩატვირთვის სკრიპტი და ა.შ. იგივე საკრალური მაგალითი: ბრძანება
OK boot kernel.old
ჩაიტვირთება ძველი ბირთვი, ისევე როგორც ჩატვირთვის ბრძანება ოფციების გარეშე წყვილის შესრულების შემდეგ
OK unload kernel OK load kernel.old
თუმცა, ამ წყვილის პირველ გუნდს მაინც არ დააზარალებს - რათა თავიდან აიცილონ... მითუმეტეს თუ ახალი ბირთვი საკმაოდ უხერხულად შეიკრიბა.
BSD loader-ის ინტერაქტიული რეჟიმის ყველა მახასიათებელი არ არის აღწერილი აქ - მხოლოდ ის, რაც მე გამოვიყენე. უფრო დეტალური ინფორმაციის ნახვა შეგიძლიათ არა მხოლოდ man (8) loader-ში, არამედ უშუალოდ დახმარების ფაილის წაკითხვით:
$ ნაკლები /boot/loader.help
და ეს საერთოდ არ არის საჭირო გადმოტვირთვის მართვის პროცესში - უმჯობესია ამის გაკეთება წინასწარ.
ჩამტვირთველის კონფიგურაცია
მომხმარებელს, რომელმაც მოახერხა Unix Way-ის სულისკვეთება (ან მაინც იგრძნო ეს) უფლება აქვს იკითხოს: თუ ჩატვირთვის პროცესში შესაძლებელია ინტერაქტიულად ჩარევა, შესაძლებელია თუ არა ხელით განსაზღვრული პარამეტრების ერთხელ და სამუდამოდ დაფიქსირება. ? და მასზე პასუხი იქნება: კარგი, რა თქმა უნდა, შეგიძლია.
ინტუიციურად ცხადია, რომ რადგან მომხმარებლის ჩარევა შესაძლებელია ჩატვირთვის პირველ (boot0) და ბოლო (ჩამტვირთავი) ეტაპებზე, სწორედ ისინი ემსახურებიან პერსონალიზაციას. და ასე გამოდის.
მართალია, ჩამოტვირთვის პირველ ეტაპზე, არც ისე ბევრია, რისი კონფიგურაცია შეგიძლიათ, კერძოდ:
- შეცვალეთ მონაკვეთის არჩევის ლოდინის დრო (ნაგულისხმევად ეს უდრის უცნაურ ციფრს 18,2 წამს - ასე წერია დოკუმენტაციაში);
- დააფიქსირეთ ერთ-ერთი დანაყოფი, როგორც ჩატვირთვადი ნაგულისხმევად - ამის გარეშე, როგორც უკვე აღვნიშნეთ, ნაგულისხმევად არის დანაყოფი შერჩეული აპარატის წინა გაშვებისას;
- კიდევ რამდენიმე წვრილმანი, რომელსაც პრაქტიკული მნიშვნელობა არ აქვს.
boot0cfg ბრძანება ემსახურება ამ მიზნებს. უნდა გვახსოვდეს მხოლოდ ის, რომ მისი გამოყენება დაკავშირებულია Master Boot Record-ის (MBR) ცვლილებასთან, რომლის განადგურება შეუძლებელს ხდის აპარატის დისკიდან გაშვებას. ამ ბრძანებით MBR-ის გაფუჭების ალბათობა უკიდურესად მცირეა და მას არ აქვს საშინელი შედეგები. თუმცა (ღმერთი მფარველობს მათზე, ვინც ზრუნავს) - ჯობია ხელთ გქონდეთ DFBSD საინსტალაციო დისკი. რა თქმა უნდა, არა სისტემის ხელახლა ინსტალაციისთვის, არამედ ჩატვირთვის ჩანაწერის აღსადგენად - ეს არის დიდი სამაშველო ფლოპი. და როგორ - ეს იქნება ციკლის შემდეგი სტატიის თემა.
ასე რომ, თქვენ შეგიძლიათ შეცვალოთ დრო -t # ვარიანტის გამოყენებით, სადაც # არის მნიშვნელობა წამებში (ნულოვანი მნიშვნელობა დაუშვებელია). -s # ოფციის გამოყენებით, ერთი კონკრეტული დისკის დანაყოფი ხდება ნაგულისხმევად ჩატვირთვადი სამუდამოდ (და არა ის, საიდანაც ის დაიწყო, როდესაც მანქანა ბოლოს ჩართული იყო). ცხადია, აქ მისაღებია მნიშვნელობები 1-4 (შესაძლო პირველადი დანაყოფების რაოდენობის მიხედვით) პლუს 5 - კონტროლის გადაცემა მეორე დისკის MBR-ზე. ხოლო -v ვარიანტი უფრო დეტალურ ინფორმაციას მოგვცემს შესრულებული ოპერაციის შედეგების შესახებ. და, რა თქმა უნდა, საჭიროა არგუმენტი - დისკის მოწყობილობის სახელი, რომლის MBRსაც ვცვლით. ანუ ბრძანება
$ boot0cfg -t 30 -s 2 -v -f /boot/boot0.old ad0
ცვლის პირველი IDE დისკის MBR (ad0 არგუმენტი) ისე, რომ მისი მე-2 ნაჭერი გახდება ნაგულისხმევი ჩატვირთვა, დანაყოფის არჩევის დრო გაიზრდება 30 წამამდე და მოახსენებს მისი მუშაობის შედეგებს მსგავსის სახით. შემდეგი:
# დროშის დაწყება chs ტიპის დასასრული chs ოფსეტური ზომა 1 0x00 0: 1: 1 0x83 850: 254: 63 63 13671252 2 0x80 851: 0: 1 0xa5 261: 254: 63301 დისკი = 254: 613 300 დისკი = 254: 613 301 2 0x80 851: 1 0xa5 261: 254: 613 301 დისკი = 254: 613 30 3 1 0x80 = 254: 63 30 3 0 2 0x80 851 = 254: 613 30 1 . 30 ვარიანტი = პაკეტი, განახლება, nosetdrv default_selection = F2 (ნაწილი 2)
დიახ, -f ვარიანტი შექმნის ჩატვირთვის მიმდინარე ჩანაწერის ასლს / boot დირექტორიაში; მართალია, ფაილი / boot / boot0 არის ახლად დაყენებული სისტემის MBR-ის ასლი, მაგრამ - დაზღვევისთვის კიდევ ერთი ორმაგი არ დააზარალებს.
მოდით, ყურადღება მივაქციოთ noupdate ოფციას ბრძანების საბოლოო გამომავალში: ეს არის ის, რომელიც აფიქსირებს ერთ-ერთ ნაჭერს ნაგულისხმევად დატვირთულად. თუ რაიმე მიზეზით არ მოგწონთ ეს პოზიცია, მისი შეცვლა ადვილია ამ ფორმით ბრძანების გამეორებით:
$ $ boot0cfg -o განახლება ad0
ისე, სხვა ვარიანტების მნიშვნელობა (და ბრძანების გამოყენების სხვა გზები) შეიძლება გარკვევა დეიდა მანიით: man (8) boot0cfg.
ასე რომ, ჩვენ უნდა დავაყენოთ თავად ჩამტვირთავი. ერთხელ აღვნიშნე, რომ მენიუს გამოჩენამდე და ინტერაქტიულ რეჟიმში გადასვლის შესაძლებლობამდე, ბირთვი უკვე ახერხებს ჩატვირთვას პარამეტრების გარკვეული ნაკრებით და დავპირდი, რომ გეტყვით სად და ვის მიერ არის განთავსებული ეს პარამეტრები. დროა შეასრულოთ თქვენი დაპირება.
ასე რომ, ბირთვის ჩატვირთვის პარამეტრები დაყენებულია bootloader ინიციალიზაციის სკრიპტით - /boot/loader.rc. სინამდვილეში, ეს არის ერთგვარი სერიული ფაილი, საიდანაც რამდენიმე ცალკეული სკრიპტი იწოდება, მაგრამ ჩვენთვის ახლა ეს არ არის აუცილებელი. და რაც მნიშვნელოვანია, არის ის, რომ ჩამტვირთველის ნაგულისხმევი გარემოს ცვლადები და მათი მნიშვნელობები დაყენებულია დაწყვილებულ კონფიგურაციის სკრიპტში - /boot/defaults/loader.conf ფაილში. იგი აღწერს მოდულების ძიების ბილიკებს, ბირთვის ნაგულისხმევ სახელს, მიმდინარე დისკის მოწყობილობას და ძირეულ ფაილურ სისტემას, და დაგვიანებას ჩატვირთვამდე - ყველაფერი, რაც შეიძლება ინტერაქტიულად იყოს მითითებული, როგორც გარემოს ცვლადები. ის ასევე შეიცავს ყველა სახის ბირთვის მოდულის ჩამონათვალს (ზოგადად, ყველა შესაძლო) და მიუთითებს, უნდა ჩაიტვირთოს ისინი ავტომატურად გაშვებისას თუ არა.
თავისთავად, /boot/defaults/loader.conf არ არის განკუთვნილი რედაქტირებისთვის, მაგრამ მხოლოდ აჩვენებს ჩატვირთვის ყველა შესაძლო პარამეტრს და აფიქსირებს მათ ნაგულისხმევ მნიშვნელობებს. და ამიტომ, ჩამტვირთველის კონფიგურაციის რეალური მიზანი ის კი არ არის, არამედ ფაილი /boot/loader.conf.
თუმცა, სისტემის დაყენებისთანავე, სისტემაში ასეთ ფაილს ვერ ვიხილავთ. თქვენ თვითონ უნდა შექმნათ იგი, გადაიტანოთ საჭირო ვარიანტები /boot/defaults/loader.conf ფაილიდან და შესაბამისად შეცვალოთ მათი მნიშვნელობები.
ნებისმიერი სისტემის დაყენებისას, ჩვეულებრივ, უფრო ადვილია იმის ჩვენება, თუ როგორ კეთდება ეს, ვიდრე ამის შესახებ. და ამიტომ მივცემ ჩემს /boot/loader.conf-ს მაგალითს რამდენიმე კომენტარით. მე ვარ უბრალო ადამიანი, არ ვარ მიდრეკილი ექსცესებისკენ და ამიტომ ეს ფაილი ჩემთვის ძალიან მცირეა.
Autoboot_delay = "5" # ლოდინის დრო ავტომატურ ჩატვირთვამდე beastie_disable = "YES" # ჩამტვირთველის მენიუს ჩვენების გაუქმება usb_load = "YES" # USB ავტობუსის მხარდაჭერის მოდულის ჩატვირთვა ugen_load = "YES" # ჩატვირთვა USB მოწყობილობის მხარდაჭერა ზოგადად ums_load = "YES" " # ჩატვირთეთ USB მაუსის მხარდაჭერა # ეს ხაზები საჭიროა, თუ შესაბამისი ფუნქციები # არ არის მყარი კოდირებული snd_pcm_load = "YES" # ჩატვირთეთ ხმის მხარდაჭერის მოდული snd_ich_load = "YES" # ჩატვირთეთ ხმის მოწყობილობის მოდული # მაგალითში - ჩიპსეტის აუდიო Intel-ისგან ICH #
გარდა ამისა, აქ შეგიძლიათ ჩართოთ ზოგადად ეკრანმზოგის მოდულის ჩატვირთვა და, ამის შემდეგ, კონკრეტული მოდული (შესაბამისი ფაილები განთავსებულია / modules დირექტორიაში და აქვს ფორმა * _saver.ko):
Vesa_load = "YES" screensave_load = "YES" screensave_name = "fire_saver"
თქვენ ასევე შეგიძლიათ ატვირთოთ თქვენი საკუთარი splash სურათი (რომლის შექმნა * .bmp ან * .pcx ფორმატში და მისი განთავსება / boot დირექტორიაში წინასწარ უნდა იზრუნოთ):
Splash_bmp_load = "YES" bitmap_load = "YES" 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 პროგრამის რეგულარულ ამოცანებს.
ამ ამოცანებიდან პირველი, როგორც გაშვების, ასევე მნიშვნელობის თვალსაზრისით, არის ხელმისაწვდომი ფაილური სისტემების მთლიანობის შემოწმება. ამისათვის თითოეული მათგანი მოწმდება „სუფთა ბაიტის“ ბიტის არსებობაზე, რომელიც ავტომატურად დაყენებულია წინა სესიის სწორად შეწყვეტისას. თუ ასეთი ბიტი გვხვდება ყველა ფაილურ სისტემაზე - ყველაფერი კარგადაა, ყველაფერი წინ მიდის. თუ არა, შესაძლებელია ვარიანტები, რომლებიც მომდევნო სტატიაში იქნება განხილული.
უნდა აღინიშნოს, რომ "სუფთა unmount bit" თავისთავად არ იძლევა ფაილური სისტემის და განსაკუთრებით მისი მონაცემების უსაფრთხოების გარანტიას. ეს მხოლოდ აჩვენებს, რომ ფაილური სისტემა სწორად იყო დემონტაჟი წინა სესიაზე. ამ შემთხვევაში, init აკეთებს გონივრულ ვარაუდს, რომ მეტამონაცემები და მონაცემები წესრიგშია და გადადის შემდეგ დავალებაზე.
და init პროცესის შემდეგი ამოცანაა გამოიძახოთ და შეასრულოთ init სკრიპტები, ან გაშვების სკრიპტები, რომლებიც შეგროვებულია / etc დირექტორიაში და (ან) მის ქვედირექტორიებში. ეს არის ჩვეულებრივი გარსის სკრიპტები, რომლებიც შექმნილია სტანდარტული POSIX გარსით შესასრულებლად და მოიცავს ბრძანებების თანმიმდევრობებს ფაილური სისტემების დასამონტაჟებლად, სვოპ არეალის გასააქტიურებლად, სისტემის საათის დაყენებისა და გარკვეული სერვისებისა და დემონების დასაწყებად.
ბრძანებები, რომლებიც ქმნიან გაშვების სკრიპტებს, იღებენ თავიანთ ოფციებს, მათ მნიშვნელობებს და არგუმენტებს სპეციალური კონფიგურაციის ფაილებიდან, რომლებსაც ასევე აქვთ მათი მდებარეობა / ა.შ. და მისი ქვედირექტორიები. კონფიგურაციის ფაილები (ან უბრალოდ კონფიგურაციები) არის პარამეტრების და ბრძანების არგუმენტების მარტივი მონაცემთა ბაზა, ან ცვლადის სახელების სიები (შეესაბამება სკრიპტებში გამოყენებული ბრძანებების ვარიანტებს) მათთვის მინიჭებული მნიშვნელობებით. სკრიპტების კონფიგურაციები ადვილად გამოირჩევიან / etc დირექტორიაში დათვალიერებისას პირველი შესრულების ბიტების არარსებობით.
დაბოლოს, დაწყების პროცესის მესამე შეუცვლელი ამოცანა - ე.წ. ტერმინალის მიღება (გეტის პროცესის დაწყება), მისი თვისებების დაყენება და ავტორიზაციისთვის მომზადება - ჩანაცვლებულია შესვლის პროცესით. ამ პროცედურის შესრულება ასევე განისაზღვრება შესაბამისი კონფიგურაციის ფაილის პარამეტრებით.
გაშვების სკრიპტების და მათი კონფიგურაციის ფაილების თანმიმდევრული გამიჯვნა არის სისტემის მასშტაბით კონფიგურაციის ერთ-ერთი ქვაკუთხედი. სინამდვილეში, დაყენების ნორმალური მსვლელობისას მომხმარებელს პრაქტიკულად არ სჭირდება სკრიპტების შინაარსის გაცნობა (თუმცა ეს არ არის საზიანო), ან, მით უმეტეს, რაიმეს შეცვლა მათში (ეს უკანასკნელი დასაშვებია მხოლოდ თუ სწორედ ამ მომხმარებელმა იცის ზუსტად რომელია, წინააღმდეგ შემთხვევაში სისტემა ადვილად შეიძლება მიიყვანოს არაოპერატიულ მდგომარეობაში). მაგრამ არა მხოლოდ შესაძლებელია, არამედ აუცილებელია ცვლილებების შეტანა კონფიგურაციის ფაილების პარამეტრების მნიშვნელობებში - რა თქმა უნდა, ასეთი ნებართვა არ ათავისუფლებს მომხმარებელს მათი მოქმედებების მნიშვნელობის გაგებისგან.
ამასთან, ამის გაგებას აფერხებს ის ფაქტი, რომ როგორც საწყის სკრიპტები, ასევე მათი კონფიგურაციის ფაილები განსხვავებულად არის დანერგილი სხვადასხვა ოპერაციულ სისტემაში და მათ დისტრიბუციაში. თუმცა, ეს ჯიში შეიძლება შემცირდეს ორ სტილამდე - BSD, რომლის თემაზე ყველა ვარიაცია ძალიან ჰგავს ერთმანეთს და System V, რომლის თითოეული წარმომადგენელი თავისებურად ორიგინალურია. ინიციაციის პირველი სტილი გამოიყენება ამავე სახელწოდების ოჯახის ოპერაციულ სისტემებში. System V სტილი ჭარბობს Linux-ის ყველაზე გავრცელებულ დისტრიბუციაში. თუმცა ბოლო დროს ბევრი მათგანი (CRUX, Archlinux, Gentoo) სულ უფრო ხშირად იყენებს BSD-ის მსგავს ინიციაციის სქემებს.
DragonFly-ის ინიცირება
DragonFly-ში BSD სტილის დატვირთვა მიღებულია ისე, როგორც ეს უნდა იყოს BSD ოჯახის წარმომადგენლისთვის. მისი მთავარი განსხვავება System V სტილისგან არის runlevels-ის კონცეფციის არარსებობა (რაც ხშირად არაზუსტად ითარგმნება როგორც დატვირთვის დონეებიან თუნდაც ტრიგერის დონეები). ამის ნაცვლად, არსებობს ჩატვირთვის რეჟიმების კონცეფცია, რომელთაგან მხოლოდ ორია - ერთჯერადი და მრავალ მომხმარებლის.
ერთი მომხმარებლის რეჟიმში, ჩატვირთვა ხდება ა) როდესაც ირჩევთ შესაბამის ელემენტს ( ჩატვირთვა ერთი მომხმარებლის რეჟიმში) bootloader მენიუში, ბ) bootloader ბრძანების ხაზში boot -s ბრძანების მითითებისას (მისი მენიუს ელემენტის არჩევის შემდეგ გაქცევა ჩამტვირთველის მოთხოვნაზე) და გ) თუ ფაილური სისტემის მთლიანობის სერიოზული (ავტომატურად გამოუსწორებელი) დარღვევები გამოვლინდა მისი შემოწმებისას ინიციალიზაციის პირველ ეტაპზე).
ერთი მომხმარებლის რეჟიმში ჩატვირთვისას, მდგომარეობა ფაქტობრივად შენარჩუნებულია ჩამტვირთველის შესრულების შემდეგ. ანუ, არ არის ფაილური სისტემების დამონტაჟება (გარდა root-ისა, საიდანაც ადრე იყო ჩატვირთული ბირთვი - და ისიც კი დამონტაჟდა მხოლოდ წაკითხვის რეჟიმში), არ არის ინიციაციის სკრიპტები, არ არის ვირტუალური ტერმინალების გააქტიურება, არ არის მოწვევა. მომხმარებლების ავტორიზაციისთვის. მხოლოდ პირველი, სისტემა, კონსოლი გააქტიურებულია მასზე ავტომატური, ნაგულისხმევად, პაროლის გარეშე, სუპერმომხმარებლის რეგისტრაციით.
ცხადია, ნორმალური მუშაობა ერთი მომხმარებლის რეჟიმში შეუძლებელია - ის განკუთვნილია გადაუდებელი აღდგენის ოპერაციებისთვის წარუმატებლობისა და სისტემის ზოგიერთი მანიპულაციის შემდეგ. ყოველდღიური მოქმედებებისთვის განკუთვნილია ნორმალური მულტიმოთამაშის რეჟიმი.
მრავალ მომხმარებლის რეჟიმში ჩატვირთვისას (და ეს ხდება ნაგულისხმევად, როდესაც მანქანა ჩართულია ან გადაიტვირთება), დაწყების ყველა ეტაპი სრულად სრულდება: შემოწმების შემდეგ, დამონტაჟებულია ამისთვის განკუთვნილი ფაილური სისტემები (და root. ფაილური სისტემის შეკეთება ხდება წაკითხვის/ჩაწერის რეჟიმში), გარკვეული საწყისი სკრიპტები (ვნახავთ სად და ვის მიერ - მალე ვნახავთ) და ყველა წინასწარ განსაზღვრული ვირტუალური ტერმინალი (რომელზეც ასევე მოგვიანებით იქნება განხილული) გააქტიურებულია მოსაწვევებით. ავტორიზაცია. ავტორიზაცია შესაძლებელია როგორც ადმინისტრატორისთვის, ასევე ნებისმიერი მომხმარებლისთვის, მაგრამ თქვენ მოგიწევთ დაივიწყოთ პაროლის გარეშე შესვლა. მოკლედ ნორმალური ცივილიზებული სამუშაოები მიდის...
არ არსებობს გადაულახავი უფსკრული ერთ მომხმარებლის და მრავალ მომხმარებლის რეჟიმებს შორის: ერთი რეჟიმიდან მეორეზე გადასვლა შესაძლებელია არა მხოლოდ აპარატის გადატვირთვისას, არამედ ერთი სესიის დროსაც. იმისათვის, რომ დაუყოვნებლივ გადახვიდეთ ერთ მომხმარებლის რეჟიმში, გამოიყენეთ ბრძანება
$ გამორთვა ახლა
მრავალმოთამაშიან რეჟიმში დაბრუნება ხდება ბრძანებით
ეს მეთოდი ფართოდ გამოიყენება სისტემის ხელახალი ინიციალიზაციისთვის, მისი სრული გადატვირთვის გარეშე, ნებისმიერი კონფიგურაციის პარამეტრის შეცვლის შემდეგ - ის ბევრად უფრო სწრაფად მიმდინარეობს, ვიდრე სრული გადატვირთვა. თქვენ უბრალოდ უნდა გახსოვდეთ, რომ ყველა სერვისი და დემონი არ არის საჭირო სწორად იმუშაოს. მაგალითად, კონსოლის მაუსის დემონი უარს ამბობს მომსახურებაზე.
ჩატვირთვა მრავალ მომხმარებლის რეჟიმში - და ეს არის BSD სტილის გამორჩეული მახასიათებელი - პოტენციურად განაპირობებს აბსოლუტურად ყველა სისტემის სერვისისა და დემონის ხელმისაწვდომობას დასაწყებად: სკრიპტებს, რომლებიც მათ ინიციალიზაციას უკეთებენ (მდებარეობს /etc/rc.d დირექტორიაში) შეუძლიათ. თეორიულად გაიშვება ძირითადი გაშვების სკრიპტიდან - ფაილი / etc / rc. მაგრამ რომელი მათგანი იქნება რეალურად გაშვებული, განისაზღვრება მისი კონფიგურაციის ფაილის ვარიანტებით - /etc/rc.conf. რამდენიმე ძირითადი გაშვების სკრიპტის და მისი კონფიგურაციის ფაილის არსებობა DragonFly-ის მეორე განმასხვავებელი თვისებაა (და ზოგადად BSD დაწყების სტილი).
როდესაც DragonFly არის დაინსტალირებული, ნაგულისხმევი /etc/rc.conf იწერება დისკზე არსებული / etc დირექტორიაში, რომლის ხაზები ასე გამოიყურება.
Servicename_enable = "მნიშვნელობა"
ცვლადი = "მნიშვნელობა"
პირველი ტიპის სტრიქონების მნიშვნელობა = "დიახ" ან "არა". ადვილი მისახვედრია, რომ ისინი იძლევიან (ან უარყოფენ) დასახელებული სერვისის გაშვებას შესაბამისი (და, როგორც წესი, ამავე სახელწოდების) სკრიპტის საშუალებით /etc/rc.d დირექტორიადან. მეორე ტიპის სტრიქონების მნიშვნელობები არის პარამეტრები, რომლებიც გადაცემულია ინიციალიზაციის სკრიპტებში შემავალ ბრძანებებზე.
ნაგულისხმევად, DragonFly - და ეს ასევე არის BSD სისტემების ტრადიცია - /etc/rc.conf ფაილში დასაშვებია მხოლოდ მინიმალური რაოდენობის სისტემური სერვისების გაშვება, რაც აუცილებელია დასაწყებად. მათი უმეტესობა, როგორც წესი, აკრძალულია - ან ცალსახად, მნიშვნელობის "NO" მითითებით, ან ნაგულისხმევად (და საიდან მოდის ეს ნაგულისხმევი პარამეტრები - ახლა ვნახავთ). ასე რომ, მომხმარებლისთვის საჭირო დემონების ჩართვა (მაგალითად, იგივე კონსოლის მაუსი) თავად მომხმარებლის საქმეა.
საწყისი ნაგულისხმევები აღებულია /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 = "არა" # გაუშვით მაუსის დემონი. moused_type = "auto" # იხილეთ man page for rc.conf (5) ხელმისაწვდომი # პარამეტრებისთვის. moused_port = "/ dev / psm0" # დააყენეთ თქვენი მაუსის პორტი. moused_flags = "" # ნებისმიერი დამატებითი დროშები მაუსის დასაყენებლად. mousechar_start = "არა" # თუ 0xd0-0xd3 ნაგულისხმევი დიაპაზონი არის დაკავებული თქვენს # დაწყებაში, როგორიცაა mousechar_start = 3, იხილეთ vidcontrol (1)
საიდანაც, ფაქტობრივად, შემდგომი ქმედებები აშკარა ხდება. პირველ რიგში, მაუსის დემონს უნდა მიეცეს დაშვება - რისთვისაც ხაზი ემატება /etc/rc.conf-ს.
Moused_enable = "დიახ"
/ usr / sbin / moused ბრძანება (და თქვენ შეგიძლიათ ჩართოთ მაუსის მხარდაჭერა ბრძანების ხაზიდან, მაგრამ მხოლოდ ამ სესიაზე - ეს ცოტა მოგვიანებით იქნება განხილული) ზოგადად მოითხოვს ორ ვარიანტს - პროტოკოლის დაზუსტებას (ეს არის ის, რაც აღწერილია moused_type ხაზი) და კავშირის პორტი (სერიული, PS / 2, USB - ავტობუსის მაუსები, სავარაუდოდ, გამოუსადეგარია). პროტოკოლის აღწერისას ხაზი
Mooused_type = "ავტო"
შესაფერისია ყველა, რამდენადაც მე ვიცი, თანამედროვე მღრღნელებისთვის PS / 2 კონექტორებით, თუმცა შეიძლება ზუსტად დაზუსტდეს - ps / 2. მაგრამ სერიული (და მით უმეტეს ავტობუსის) თაგვებისთვის, პროტოკოლი მკაფიოდ უნდა იყოს მითითებული. რა - ვუყურებთ ადამიანში (5) rc.conf ან კაცი (8) თაგვის (მე, ცოდვილი საქმით, უკვე დავივიწყე ეს არსებები).
მკაფიო პორტის მითითება ასევე აუცილებელია მხოლოდ სერიული და საბურავი თაგვებისთვის ("იცნობ დეიდა მანიას? - მე ვიცნობ დეიდა მანიას. - გჯერა დეიდა მანია? - მე ვენდობი მანას დეიდა. - მაშ, სთხოვე მას ასეთი ცხოველები.. .")... თუმცა თუ დააზუსტებთ
Moused_port = "/ dev / psm0"
PS-ნახევარი მხეცისთვის ოდნავი ზიანი არ იქნება.
Mooused_flags = ""
შეგიძლიათ დააყენოთ სხვადასხვა ვარიანტები, რომლებიც მოცემულია / usr / sbin / მაუსის ბრძანებისთვის, როგორიცაა: შუა ღილაკის ემულაცია ორღილაკიანი მოდელებისთვის (მოძრავ თაგვებზე ბორბალი მუშაობს შუა ღილაკის მსგავსად), რეაქციის სიჩქარე, აჩქარება გადაადგილებისას. კურსორი და ა.შ. დეტალებისთვის - ისევ მანას, მანას, მანას ...
ისე, ხაზის შესახებ
Mousechar_start = "არა"
საუბარი უკვე იყო: თუ KOI8-R გამოიყენება როგორც გამომავალი კოდირება, და ბირთვი არ იყო აღდგენილი, ან ხელახლა აშენებულია ოფციის გარეშე
პარამეტრები SC_MOUSE_CHAR = 0x3
ნაგულისხმევი NO უნდა შეიცვალოს 3-ით. ნებისმიერ სხვა შემთხვევაში, ეს უბრალოდ არ არის საჭირო.
როგორც მომდევნო სტატიაში ნახავთ, ბირთვის აღდგენის ერთ-ერთი მიზანი იყო გრაფიკული კონსოლის მხარდაჭერა. თუმცა, საკმარისი არ არის ბირთვის კონფიგურაციაში შესაბამისი ვარიანტის ჩართვა - შესაბამისი ვიდეო რეჟიმი ჯერ კიდევ უნდა გააქტიურდეს. ამას უზრუნველყოფს /etc/rc.d/syscons სკრიპტი, რომელიც ახორციელებს, კერძოდ, vidcontrol ბრძანებას, რომელიც პასუხისმგებელია ყველაფერზე, რაც დაკავშირებულია ჩვენების პარამეტრებთან. და ეს ბრძანება თავის პარამეტრებს ისევ იღებს /etc/rc.conf ფაილიდან. კერძოდ, ვიდეო რეჟიმი განისაზღვრება ცვლადით
Allscreens_flags = ""
რისთვისაც თქვენ უნდა განსაზღვროთ შესაბამისი მნიშვნელობა MODE_ # რეჟიმის სახით. მაგალითად, თუ გსურთ გქონდეთ 800 × 600 გარჩევადობა და 32 ბიტიანი ფერის სიღრმე, ეს ხაზი მიიღებს ფორმას
Allscreens_flags = "MODE_277"
ახლა ინიცირების ბოლო ეტაპის შესახებ - ტერმინალის მოპოვების პროცესი. ის კონტროლდება / etc / ttys ფაილში ჩანაწერებით, რაც მოკლედ იყო ნახსენები სტატიაში სისტემის დაყენების შესახებ. ვირტუალური ტერმინალების კონფიგურაციისთვის სპეციალური ფაილის არსებობა არის მესამე მნიშვნელოვანი განსხვავება BSD სისტემებს შორის: Linux-ში, განურჩევლად კონკრეტულ დისტრიბუციაში მიღებული init სკრიპტების სტილისა, ვირტუალური ტერმინალების დაყენება აღწერილია init-ის ზოგად კონფიგურაციაში. პროცესი.
/ etc / ttys ფაილის შიგთავსი ასე გამოიყურება (მე გამოვტოვებ ხაზებს, რომლებიც აღწერს ტერმინალებს, რომლებიც მიღებულ იქნა აპარატზე dial-up წვდომით, როგორც შეუსაბამო):
კონსოლი უცნობია, გამორთულია # ttyv0 "/ usr / libexec / getty კომპიუტერი" cons25 უსაფრთხო # ვირტუალური ტერმინალები ttyv1 "/ usr / libexec / getty კომპიუტერი" cons25 უსაფრთხო ttyv2 "/ usr / libexec / getty კომპიუტერი" cons25 უსაფრთხო ttyv3 " / usr / libexec / getty კომპიუტერი "cons25 უსაფრთხო ttyv4-ზე" / usr / libexec / getty კომპიუტერი "cons25 უსაფრთხო ttyv5-ზე" / usr / libexec / getty კომპიუტერი "cons25 უსაფრთხო ttyv6-ზე" / usr / libexec / getty კომპიუტერი "cons25 უსაფრთხო ttyv5-ზე" ttyv7 "/ usr / libexec / getty კომპიუტერი" cons25 უსაფრთხო ttyv8 "/ usr / X11R6 / bin / xdm -nodaemon" xterm off უსაფრთხო
როგორც ხედავთ, ეს არის მარტივი მონაცემთა ბაზა, რომლის ველებს აქვს შემდეგი შინაარსი:
- ტერმინალური მოწყობილობის სახელი, რომელსაც აქვს მნიშვნელობების კონსოლი ეგრეთ წოდებული სისტემის კონსოლისთვის და ვირტუალური ტერმინალის სახელი (ttyv #, სადაც # არის რიგითი ნომერი) ყველა დანარჩენისთვის;
- ამ ტერმინალზე დაწყებული პროცესი მის გასააქტიურებლად; სისტემის კონსოლზე პროცესი არ დაწყებულა, მის როლს (პირველ რიგში, სისტემური შეტყობინებების განთავსების ადგილი) ასრულებს პირველი ვირტუალური ტერმინალი; სხვებზე, გარდა ამ უკანასკნელისა (რომელიც ცალკე განხილვა იქნება), ასეთი პროცესი სტანდარტული გეტია;
- ტერმინალის ტიპი - ნაგულისხმევად სტანდარტული ვიდეო რეჟიმისთვის 80 × 25;
- ტერმინალის სტატუსი, რომელიც განსაზღვრავს გააქტიურებულია (ჩართულია) თუ არა (გამორთული); ნაგულისხმევი „უარყოფითი“ მნიშვნელობა ჩანს ორ ჩანაწერში - პირველსა და ბოლოში;
- ტერმინალის უსაფრთხოების ხარისხი; ნაგულისხმევი მნიშვნელობა safe ვარაუდობს, რომ ეს ტერმინალი ფიზიკურად, ასე ვთქვათ, მიუწვდომელია თავდამსხმელისთვის და, შესაბამისად, სუპერმომხმარებელს შეუძლია უსაფრთხოდ დარეგისტრირდეს მასზე; თუ თქვენ შეცვლით მას არაუსაფრთხოზე, მაშინ ამ ტერმინალიდან root ავტორიზაცია შეუძლებელი იქნება; სისტემის კონსოლისთვის არაუსაფრთხოების მითითება გამოიწვევს სუპერმომხმარებლის პაროლის დაყენებას ერთი მომხმარებლის რეჟიმში ჩატვირთვისას.
რა შეიძლება შეიცვალოს აქ? პირველი, ტერმინალის ტიპი: კონსოლის რეჟიმის რუსიფიკაციის შემთხვევაში, ნაგულისხმევი მნიშვნელობა cons25 უნდა შეიცვალოს cons25r-ით; თუმცა, ჩვენ ეს გავაკეთეთ ინსტალაციის შემდეგ, არა? თუ იყენებთ სიმბოლოების სიმკვრივეს, გარდა სტანდარტული სიმბოლოების სიმკვრივისა, უნდა შეიცვალოს ტერმინალის ტიპიც. მაგალითად, თუ იყენებთ 80x30 რეჟიმს, ჩაანაცვლეთ აქ cons30r. ტერმინალის მოქმედი ტიპის მნიშვნელობების სრული სია შეგიძლიათ იხილოთ / etc / termcap ფაილში.
გარდა ამისა, უსაფრთხოების თვალსაზრისით, უსაფუძვლო არ არის სუპერმომხმარებლის ავტორიზაციის დაშვება მხოლოდ რომელიმე ვირტუალურ კონსოლზე, მაგალითად, პირველზე: ის ჯერ კიდევ არ არის შესაფერისი პრაქტიკული მუშაობისთვის, რადგან მასზე გროვდება სისტემის შეტყობინებები. . მათი უმეტესობის მოშორება, რა თქმა უნდა, შესაძლებელია /etc/syslog.conf ფაილის რედაქტირებით, ხაზით აღწერილი მათი გამომავალი გადამისამართებით.
* .err; kern.debug; auth.notice; mail.crit / dev / კონსოლი
სისტემის კონსოლიდან რომელიმე ფაილამდე (ან თუნდაც / dev / null მოწყობილობამდე). თუმცა, რამდენიმე რამ მაინც გამოჩნდება კონსოლზე - მაგალითად, შეტყობინებები ცხელი დანამატის მოწყობილობების (როგორიცაა USB ჩხირები ან კომპიუტერის ბარათები) მიმაგრებისა და გამორთვის შესახებ.
პრინციპში, ადმინისტრატორის რეგისტრაცია შეიძლება საერთოდ აიკრძალოს: Root-ოპერატორის დროებითი უფლებების მოპოვება ბრძანებით.
ეს არავითარ შემთხვევაში არ არის შემაფერხებელი.რა თქმა უნდა, სისტემის გაშვებისას გააქტიურებული ვირტუალური ტერმინალების რაოდენობა შეიძლება შეიცვალოს ამა თუ იმ მიმართულებით. გასაგებია, რომ მათი რიცხვის შესამცირებლად საკმარისია უბრალოდ წაშალოთ ან კომენტარი გააკეთოთ "დამატებითი" ხაზები და გაზარდოთ - შეიყვანოთ დაკარგული ხაზები არსებულის გამოსახულებაში და მსგავსებაში (გახსოვდეთ ფაილების გადარქმევა. შესაბამისი მოწყობილობებიდან). უბრალოდ გაითვალისწინეთ, რომ ნაგულისხმევი GENERIC ბირთვი მხარს უჭერს 16 ვირტუალურ ტერმინალს, რომელთაგან ერთი მაინც უნდა იყოს დაცული X window სისტემის დასაწყებად - ხელით ან ავტომატურად. და კიდევ ერთი რამ - როდესაც ვირტუალური ტერმინალების რაოდენობა იზრდება, თქვენ უნდა იზრუნოთ შესაბამისი მოწყობილობების ფაილების არსებობაზე (მაგალითად, ttyv #) - ნაგულისხმევად არის "მხოლოდ" 12 მათგანი / dev დირექტორიაში.
სხვათა შორის, დაახლოებით X. Linux-ის მომხმარებლებს აქვთ შესაძლებლობა უზრუნველყონ გრაფიკული ავტორიზაცია (და ავტომატური X ჩატვირთვა) მარტივი მეთოდით - ნაგულისხმევი გაშვების დონის შეცვლით. და რაც შეეხება BSD სისტემების მომხმარებლებს, რომლებსაც არ აქვთ runlevel კონცეფცია - ისინი, ვინც ძირითადად X-ში მუშაობენ და ვინც დაიღალა startx ბრძანების აკრეფით? დიახ, ყველაფერი ისეთივე მარტივია: საკმარისია "x" ვირტუალური ტერმინალის გააქტიურება, ბოლო მოცემულ ხაზში გამორთვის ჩანაცვლება. ეს ავტომატურად იტვირთება შესვლის გრაფიკული მენეჯერი - xdm. რაც, რა თქმა უნდა, შეიძლება შეიცვალოს უფრო მოწინავე ანალოგით. მაგალითად, ხაზი
Ttyv8 "/ usr / local / bin / kdm -nodaemon" xterm off უსაფრთხო
სისტემის ინიციალიზაციის მინუსი არის მისი შეჩერება ან გადატვირთვა, ამ პროცესებს შორის პრაქტიკულად არანაირი განსხვავება არ არის. და მასზე პასუხისმგებელია გამორთვის ბრძანება, რომელიც შეიძლება გაიცეს სუპერმომხმარებლის ან ოპერატორის ჯგუფის წევრის სახელით. -h ოფციით, ეს იწვევს აპარატის გაჩერებას, -r ოფციით ის გადაიტვირთება. და ეს ბრძანება ასევე მოითხოვს არგუმენტს - დრო, როდესაც უნდა მოხდეს გაჩერება ან გადატვირთვა. თუმცა, არსებობს მყისიერად გაჩერების ან გადატვირთვის გზა:
$ გამორთვა -h ახლა
$ shutdown -r ახლა
შესაბამისად.
გარდა ამისა, ასევე არსებობს შეჩერების და გადატვირთვის ბრძანებები იმავე მიზნით. თუმცა, ისინი არ ასრულებენ დამოუკიდებელ როლს, უბრალოდ გამორთვის ბრძანების გამოძახებით, შესაბამისად შეჩერების და გადატვირთვის ოფციით.
სისტემა ჩერდება მისი ინიციალიზაციის საპირისპირო თანმიმდევრობით. პირველ რიგში, მცდელობა ხდება მოხდენილად შეწყვიტოს მომხმარებლის ყველა პროცესი TERM სიგნალის გაგზავნით. გარკვეული პერიოდის გასვლის შემდეგ, KILL სიგნალი ეგზავნება ყველა ჯერ კიდევ "ცოცხალ" პროცესს - მათი მოკვლის უზრუნველსაყოფად. შემდეგ ყველა გაშვების სერვისი და დემონები შეჩერებულია. საბოლოოდ, დისკის ქეშის შიგთავსი იწერება დისკზე (სინქრონიზაციის ბრძანების მეშვეობით) და ფაილური სისტემების დემონტაჟი ხდება. ამის შემდეგ, როგორც წესი, ჩნდება შეტყობინება, რომელიც მიუთითებს იმაზე, რომ მანქანას შეუძლია უსაფრთხოდ გამორთოს ენერგია, ან ის ავტომატურად გამორთულია. გადატვირთვისას ყველაფერი ზუსტად იგივე ხდება, მაგრამ სისტემის გაჩერების შემდეგ მანქანა ავტომატურად გადაიტვირთება.
როგორც უკვე აღვნიშნეთ, სკრიპტები, რომლებიც პასუხისმგებელნი არიან გაშვების სერვისების დაწყებაზე, განლაგებულია დირექტორიაში /etc/rc.d. პროგრამების უმეტესობა, რომელსაც ისინი აწარმოებენ, არის ეგრეთ წოდებული დემონები (daemon - Disk And Execution MONitor), მსგავსი TSR პროგრამები, რომლებიც გაშვებულია ფონზე, ელოდება მოთხოვნის შესრულებას მათი ფუნქციის შესასრულებლად (ბეჭდვა, ფოსტის გაგზავნა, წვდომა ftp ან http სერვერზე და და ა.შ). ამის შესაბამისად, სკრიპტები, რომლებიც მათ გამოუშვებს, დალაგებულია დაწყება - გაჩერების პრინციპით. და თუ პირველი ფუნქცია შესრულებულია სისტემის გაშვებისას, მაშინ როდესაც ის ჩერდება, როგორც თქვენ ალბათ მიხვდებით, მეორე.
გამორთვის პროცესის პროგრესი კონტროლდება /etc/rc.shutdown სკრიპტით. მისი მიზანია შეასრულოს გაჩერების ფუნქცია ყველა სერვისის სკრიპტებში, რომლებიც გაშვებულია / etc / rc სკრიპტიდან /etc/rc.conf-ში და /etc/defaults/rc.conf-ში მოცემული აღწერილობის შესაბამისად.
