Моето си място

В паузата между две велики ИТ постижения и в очакване да падне тавана на лятното кино, реших малко да се позабавлявам с KDE 3.4. Преди време го бях зарязал (до версия 3.2) защото беше непоносимо бъгаво и тромаво. Сега с Fedora Core 4, версията му е доста стабилна и пъргава. На практика, не мога да забележа някаква съществена разлика в бързодействието между KDE 3.4.2 и GNOME 2.12. Де да знам, може и да съм кьорав….
Това, което за пореден път леко ме изнерви, е тъпият аплет за клавиатурните подредби. Не знам защо, но това нещо си е бъгаво и гадно още от самото му създаване. Не мога да схвана, в какво се състои проблема(вероятно го пише някъде, но меам нерви за решаването му), но отново това “чудо” нито ми показва знаменцата, нито иска да се превключва с клавишите, които му настройвам. Вярно, че има леко подобрение в работата му. Тя се състои в това, че ако “ръчно”, т.е. с мишката активираш алтернативната подредба, после смяната се извършва правилно. Е, разбира се, отново няма знамена и смяна на символите в жлеба, ама както се казва “това са дребни кахъри”. Kkbswitch 1.4.2 пък изобщо не тръгна. Може би, по-късно ще сложа новата му версия, може и да стане. То поне, е в пъти по-добро от въпросната издънка с аналогична функционалност.
След тази дружелюбна критика, да напиша и нещо хубаво. То се отнася до подобренията на KDE средата. Сайта за тези добавки и приложения е доста добре структуриран и лесен за използване. За мен това е образец за място от което може да се “обслужиш”, ако искаш да настроиш графичната среда. Едно от нещата (досега!), които си инсталирах и мисля да използвам е YaKuake. Не ме питайте как се произнася, това е нещо в стил “yet another…”. Програмката, представлява терминал, който се разпъва доста елегантно (това се настройва) при натискане на клавиш F12. Конфигурират се също ширината и височината на прозореца, както и схемата на терминала. Всъщност, това на практика си е konsole с всичките й екстри. Симулиране на multitab интерфейс се прави с команда screen (за повече инфо man screen). Работи перфектно! За самата инсталация – нищо интересно. Разпакетиране, после ./configure, make, make install. Добавката се появава в меню Utilities, стартира се и после се използва с клавиш F12. Който иска да си го сменя – има си меню за целта. Не е проблем.
Друго доста свежо подобрение е Kommando. Това е навигатор в стил Neverwinter Nights (така пише на линка, но аз съм виждал подобно меню в доста други игри, че даже и за мишка Logitech) на който може да се закачат различни приложения. Аналогично на YaKuake и това приложение се компилира и закача на същото място в менюто. Стартира се с клавишна комбинация Ctrl+Alt+h. Има един лек нюанс и той е, че трябва ръчно да си копирате .kommandorc файла в личната ви директория. На практика, това е ресурсният файл в xml формат, който определя кое приложение да се стартира. Редактирането му не е никак сложно, ако имате проблеми, все пак прочетете README файла. Там има кратко описание за формата и промяната му.
SuperKaramba е нещо повече от обикновена добавка. Това е цяло API, с помощта на което може да добавяте всякакви глезотии и красоти (може и грозоти, зависи от вкуса ви) в KDE средата. Знам, че звучи малко странно, но възможностите й (на добавката) са почти безкрайни. Е, не съвсем “безкрайни”, а по-скоро най-точно написано, това са ограниченията на езика Python, защото с негова помощ се създава интерактивността на приложенията. В терминологията на SuperKaramba, добавките се наричат теми. Инсталацията на карамбата е пак тривиално (./configure, make, make install). Стартиране – пак оттам. Използване?! Може да свалите .theme пакетите, които си харесате от групата Karamba или да си напишите собствен. Лично аз ще се пробвам – не изглежда трудно 😉
Изобщо, в секцията “подобрения” и “добавки” на KDE-Apps има доста свежи и оригинални неща. Всеки може да намери нещо “шаренко” по свой вкус и манталитет за освежаване на KDE средата. Засега – толкова…

Няколко минути се чудих, как и защо да напиша този пост. Дали да почна с това, че софтуерът с отворен код е нещ΀¾то, което може да преобрази един начинаещ(ламер) в (почти)истински специалист? Или да поразсъждавам на темата, защо да се мъча да разбера нещо, коеπ‚о така или иначе си работи и използвам ежедневно? Или пък да си задам фундаменталният въпрос “Абе, аз толкова ли съм тъп…. ?!” Всъщност, мога да продължа с увода и въпросите, които прехвърчаха из главата ми, докато наистина започнах да пиша следната история:

Основният ми сървър за наблюдение на мрежата е един двупроцесорен IBM x342, малко дъртичик, но с големи и бързи дискове. Общо взето – безотказен. На него съм натоварил JFFNMS (което тика 188 хоста и 2493 интерфейса), Smokeping, RANCID, блог-а на отдела, TACACS+ сървър и какво ли още не. Просто, не за това е историята :).
Средното натоварване на тази машина беше около 12 до 15 единици. В крайна сметка ги “свалих” до почти поносимите 8 до 10 единици. Ама и за това не е въпросната история :).
Истинското ровене и четене беше заради въпроса “какво всъщност се мери с load average”. Простият отговор е “Някакво натоварване на процесора през 1, 5 и 15 минути”. Лично аз бях доста изненадан да разбера, че зад тези три цифри стои доста акъл и от тях може да разберем доста за това как работи машината.
Обясненията за тях варират от обезкуражаващото “The load average tries to measure the number of active processes at any time. As a measure of CPU utilization, the load average is simplistic, poorly defined, but far from useless”, до съвсем подробното “The load average is the sum of the run queue length and the number of jobs currently running on the CPUs”. Ако погледнем в кода на ядрото, ще видим доста интересни работи, а именно:
– функцията за изчисление се извиква на всеки 5секунди;
– изчисленията се правят с числя с фиксиран знак, а не с плаваща запетая за да се постигне по-голямо бързодействие и да не се товари допълнително процесора (сметките са в адресното пространство на ядрото);
– сметките са “приблизителни”, но с достатъчна точност;
– информацията може да се използва за да се разбере, каква работа е свършила машината за последните 1, 5 и 15 минути;
– нещата не са никак прости 🙂

Наред с това, при подобен подход стоят и следните проблеми:
– показаното натоварване по-скоро е свързано не пряко с производителността на процесора, а по-скоро с дължината на опашката от операции, които чакат изчисления;
– стойностите се вземат по експоненциална, а не линейна зависимост, което затруднява анализа;
– трудно може да се планира капацитет и прогнозирано натоварване по такива стойности с цел разширение и подобрение на производителността;

За мое голямо удоволствие, като се зарових в проблематиката, в крайна сметка открих и доста полезни материали, свързани предимно с анализ и оптимизация на натоварването на Unix машините. Ако сте ограничени в рамките на определен хардуер, единствената възможност е да направите всичко “като по учебник”. Всъщност, въпросните статии са едно доста добро начало.
Мисля да започвам – просто нямам избор!

С уважение и респект към Neil Gunther и екипа на TeamQuest.