Avalon Project Page

Так склалося, що я час од часу маю необхідність спостерігати результати раптового вимкнення живлення у великої кількості серверів під різними операційними системами. З таких спостережень можна робити якісь висновки. Зокрема, ще рік-два тому, коли я востаннє бачив картину великої аварії в датацентрі, основна маса машин, що не піднялися після неї, працювали під Linux різних версій і іпостасей. Останній раз, кілька днів тому, це були, в основному, FreeBSD, багато з них - з RAID-контроллерами імені NVidia, набортними, в зеркалі. Проте жодної машини під linux. Всі linux піднялися і працювали відразу після подання напруги.

Отже, останнім часом Linux зробив помітний крок у надійності і стійкості до збоїв живлення фалових систем.

Крім того, досить негарно себе повели рейди імені NVidia. Чи то вони так не полюбляють FreeBSD, чи то FreeBSD їх не любить, та факт залишається фактом.

Зрештою, я завжди говорив клієнтам, що RAID не виключає бекапи, що він навіть може стати причиною проблеми, особливо дешевий набортний рейд. Під час останньої аварії я лише переконався, що використання "напівсофтварних" контролерів лише шкодить. На моє щастя, з усіх машин, що були вражені цією проблемою, мене стосувалася лише одна, і та була надійно забєкаплена. Після деяких присідань з фаловою системою, ми вирішили просто знести все те діло до бісового дідька і відновити з резервної копії.

Крім того, нарешті внесли в rc.conf рядок для автоматичного fsck після збою. Все одно ніхто і ніколи не розбирається, що там пише той fsck, все одно всі потім запускають fsck -y. То навіщо складати собі проблему?

Знайдено першу ремотну дірку в кавоварці з виходом в Internet. Я просто заливаюсь сльозами і бьюся головою по клаві :) День, про який так довго говорили з усмішкою тисячі адмінів, настав.

Лінка на оригінайльний текст статті:http://it.slashdot.org/article.pl?sid=08/06/17/1941200

Дірки є в будь-якому програмному забезпеченні. Іноді їх багато, іноді дуже багато, іноді вся софтинка дірява, як сито. Зокрема, цим славляться багаточисельні приблуди на PHP. PhpMyAdmin, PHPBB, etc. Та і сам PHP не є взірцем безпечного софта. Ясна справа, що велика кількість проблем виникає в сторонніх бібліотеках, прилінкованих до інтерпретатора у вигляді модулів, та мене вже вкотре непокоїть одне й те ж питання: якщо PHP такий популярний, що на ньому написано переважну більшість сайтів в Мережі, якщо його встановлено на всіх серверах массового хостінгу, то якого ж дідька security updates для нього в портах FreeBSD виходять з затримками в декілька днів, а то і тижнів? І це до поточної стабільної версії, вже не кажучи про закам'яніле гуано мамонта імені php4.

Пробзділось щось у Датському князівстві. Щороку софт все гірший і гірший, мізки розробників і майнтейнерів все більше розм'якають. Піду в windows-адміни :)

Нарешті я зважився змінити домашню систему на ноуті з Debian testing на Ubuntu Desktop 8.04. Справді,ця система пряцює просто з коробки,навіть не треба налаштовувати. Можливо, і скоріше за все, це тому, що ноут у мене наскрізь Intel, тому підтримується добре. Дещо засмучує невстановлюваний чесним чином xxkb, я до нього дуже звик. Проте є добіса гарних автоматичних приблуд, що саміроблять купу роботи. Ну, і, звичайно, є майже все. що є в Debian, що для мене просто казка якась.

Проте, народ на форумах жаліється на поламані пакунки при оновленні системи. Можливо, щось і змінили в конфігураційних файлах, різні горе-программери імені вільного софта полюбляють час від часу викинути подібний фінт на голову користувача, чим цього самого користувача немало від себе відганяють.

Вцылому, системою я задоволений на всы 100%. Хоча, ні, мабуть-таки на 90. Адже xxkb. Плюс, я перестарався виносити пакети і система при прокиданні після hibernate через довільний проміжок часу може нафіг зависнути. Точніше,воня не відповідає на клавіатуру та мишу, проте шевелить дисками. А от відразу після встановлення працювала нормально. Схоже, я щось таки поламав :)

Задався метою зменшити споживання електроенергії своїм ноутом HP 530 (Core Duo, 1.66 GHz). Спробував декілька різних драйверів для зміни частоти процесора, зокрема, acpi-cpufreq і p4-clockmod. Останній дає змогу змінювати частоту у інтервалі від 1 ГГц до 125 мегагерц, перший - від 1 ГГц до 1.66 ГГц, тобто, до максимальної частоти мого роцесора. Навіть не потрібні різні демони на кшалт cpudyn чи cpufreqd, достатньо acpi і драйвера.

Однак. якщо все ж хочеться зовсім не помічати зміни частоти процесора при роботі від стаціонарного джерела живлення, найкраще використовувати cpufreqd, він дозволяє керувати параметрами енергозбереження на основі гнучких правил.

Крім того, ядро 2.6.24 імені Debian Lenny, з ввімкненим по дефолту NOHZ, декілька хаків відносно опитування DVD-драйва, і маємо заявлені виробником 2.5 години роботи від батареї. Причому, схоже, якийсь нещасний mplayer, що грає музику, машину ніяк не навантажує по живленню... Якщо, звичайно, підправити дефолтні правила cpufreqd імені Debian, а то при роботі mplayer він вмикає CPU на повну.

Втім, зваживши всі "за" і "проти", залишаюсь з acpi-cpufreq і політикою ondemand. Це не помітно оку і, в той же час, економить заряд батареї.