ср /usr/src/linux/arch/1386/boot/zImage /boot/vmlinuz
Ви можете змінити завантаження Linux таким чином, що одержите можливість завантаження системи як з новим, так і зі старим ядром. Для цього ви повинні відредагувати файл /etc/lilo.conf, додавши в нього новий запис. Приклад такої зміни файлу приведений у листинге, у якому додається запис про старе ядро під позначкою old для завантаження старого ядра.
Листинг 1. Приклад файлу /etc/lilo.conf
boot=/dev/had
maps/boot/map
install=/boot/boot,b
prompt
timeout=50
image=/boot/vmlinuz
label=linux
іnіtrd=/boot/іnіtrd
root=/dev/hdal
read-only
image=/boot/vmlinuz.old
label=old
root-/dev/hdal
read-only
Після змін у конфігураційному файлі скористайтеся для відновлення L1LO командою
/sbin/lilo -v
Тепер після перезавантаження у вас буде 50 секунд для можливості вибрати завантаження Linux зі старим ядром.
Тепер же ви можете завантажувати модулі підтримки того чи іншого апаратного чи забезпечення драйвера пристроїв тільки при необхідності. Для того щоб побачити список використовуваних у даний момент модулів, скористайтеся командою lsmod.
Модульні ядра підтримуються тільки версіями Red Hat Linux/Intel і Red Hat Linux/SPARC. Користувачі Red Hat/Alpha змушені будувати монолітні ядра.
Для побудови модулів знаходячись у каталозі /usr/src/linux, скористайтеся командами
Make modules
make modules-install
Робота з модулями ядра
Тепер, після компіляції й інсталяції модулів, ви готові розширити можливості свого ядра за допомогою модулів, що завантажуються. У табл.14.2. перераховані основні доступні команди роботи з модулями ядра.
| Таблиця 14.2. Команди роботи з модулями | |
| Команда | Опис |
| lsmod | Виводить список завантажених у даний момент модулів |
| insmod | Уставляє визначений модуль у ядро |
| rmmod | Видаляє визначений модуль з ядра |
| depmod | Створює файл залежностей для команду modprobe |
| modprobe | Завантажує модулі зі списку, сгенерированного командою depmod |
Якщо ви працюєте з Х Windows, до ваших послуг простий і інтуїтивно зрозумілий інтерфейс роботи з модулями, наданий демоном kerneld з Control Panel (мал.14.5.)
Клацніть на кнопці Kernel Configurator. З'явитися однойменне діалогове вікно (мал. 14.6.)
За допомогою кнопки Add можна додати модуль до ядра, а за допомогою кнопки Remove – видалити. Вікно, що з'являється при щиглику на кнопці Add.
Зміни зроблені за допомогою Kernel Daemon Configurator, зберігаються у файлі /etc/conf.modules, до якого kerneld звертається при запуску.
Для перезапуску kerneld можна скористатися кнопкою Restart Kerneld у вікні Kernel Configurator чи зробити це командного рядка за допомогою команд
/etc/rc.d/init.d/kerneld stop
/etc/rc.d/init.d/kerneld start
Перезапуск не приводить до завантаження використовуваних у даний момент модулів, однак kerneld буде застосовувати збережену конфігурацію при запуску модулів у майбутньому.
У 1968 році компанія IBM запропонувала своїм клієнтам систему керування інформацією (IMS). Це була одна з перших спроб досягти хоча б деяких цілей підходу на основі баз даних до керування файлами й один з перших прикладів СУБД. У IMS база даних була концептуально представлена у виді ієрархії. Запису були організовані в набори, що зв'язувалися один з одним зв'язками володіння (ownership).
Ієрархічні бази даних підходять для тих інформаційних систем, що природним образом ґрунтуються на ієрархічній моделі. Істотним високопродуктивних великих систем, побудованих на основі IMS. Однак більшість систем неможливо реалізувати у виді IMS так, щоб уникнути великої кількості повторень даних.
У мережній моделі маються дві основні конструкції: запису і зв'язки. Зв'язок являє собою набір фізичних покажчиків, що задають відношення володіння між наборами записів. Так, можна сказати, що клієнт «володіє» набором замовлень, а деяке замовлення «володіє» набором елементів запасів (як і в ієрархічній моделі). Але в мережній моделі немає обмеження, що вимагає, щоб володіння задавалося тільки в одному напрямку, і набір записів може брати участь у довільному числі зв'язків володіння.
Використовуючи мережний підхід, можна шляхом ретельного аналізу даних усунути надмірність, і файли системи дійсно стануть інтегрованими. Але ця інтеграція досягається за рахунок складності. Мережні бази даних характеризуються великою кількістю наборів записів, кожний з який містить небагато інформації і багато покажчиків на інші безлічі записів. Навіть написання найпростіших запитів може зажадати складної навігації від одного набору записів до іншого.
У реляционной моделі дані на концептуальному рівні представляються у виді таблиць, що складаються з рядків і стовпців. Строго говорячи, таблиці називаються відносинами, рядка – кортежами, а стовпці – атрибутами. Кортежі практично еквівалентні тому, що звичайно розуміється під записом файлу, а атрибути відбивають зміст значень кожного кортежу.
У реляционной базі даних зв'язування даних різних таблиць один з одним здійснюється не за допомогою явних покажчиків (як у мережній базі даних), а за допомогою значень атрибутів.
У реляционной базі даних можна задавати зв'язку між будь-якими двома атрибутами, що мають порівнянні значення даних. Атрибут одного відношення, що складає винятково з числових значень, можна зв'язати з будь-яким атрибутом будь-якого іншого відношення, що складає також винятково з чисел. Таким чином, завдання логічних зв'язків між відносинами не становить труднощі.
Описані вище так називані класичні підходи до реалізації СУБД найчастіше зазнають критики за те, що усі вони ґрунтуються на ідеї пасивної безлічі даних. У них немає засобів, що дозволяють моделювати реальне поводження даних. Крім того, семантичні можливості також дуже обмежені, тому важко представляти дійсний зміст даних.
Объективно-ориентированная технологія намагається перебороти ці обмеження. Схема объективно-ориентированной бази даних складається з колекції класів. Клас є колекцією об'єктів, причому структура і поводження об'єктів одного класу однакові. Видима структура об'єкта визначається властивостями його класу. Так у нашій гіпотетичній базі даних клієнт буде мати такі властивості, як номер, ім'я, адреса, статус і ін. Поводження об'єкта задається за допомогою методів його класу. Метод – це, по суті, деяка операція, яку можна застосувати до об'єкта. Він представляє те, що, по-нашому думки, повинний робити об'єкт. Наприклад, клієнт може створювати замовлення, оплачувати рахунок і т.д., отже, необхідні методи для кожного з цих видів діяльності.