Linux за българи: Форуми

Здравейте,
Имам следният проблем:
Един младеж ме помоли да му помогна за курсов проект (учи в Германия). Касае се за някакви статистически анализи на кода на Х . Където знам му дадох инфото, но има едно нещо за което немога да намеря нищо. Това е статистика за честота на използването на библиотеките (или функции от тях) на Х по време на една сесия. Такова нещо съм виждал за Вин програми, направени от фирми, както и имам анализиращ софтуер, но е за Вин апликации.
Нещата трябва да изглеждат в най-лошия случай така:
libX11.so - 5%
libXdmcp.so - 1%
...
...
В най-добрия:
libX11.so - 5%
   func1 - 11%
   func2 - 25%
libXdmcp.so - 1%
   func3 - 28%
   func4 - 1%
...
...
Също така е желателно да се цитира източника на този анализ. Аз се опитах с strace и подобни функции но ще ми отнеме безкрайно време да обработя всичкият изход и да направя подобен анализ.

А защо не погледнеш profiling инфраструктурата. Примерно oprofile, kprobes, valgrind

Реално ще ти трябва дебъг версията на всички библиотеки, опрофиле в кернела и някакъв юзерспейс тул за четенето на статистиката

"ltrace -f -c" ще изкара колко пъти коя library функция е викана и колко време е отишло за нея, при това опитвайки се да прави същото и за форкнатите дъщерни процеси. Обаче не знам да може да вади информация коя функция от коя динамично-линкната библиотека е. За последното предполагам ще се наложи да се правят някакви заобиколни номера от сорта на find /usr/lib |xargs strings|grep "function_name" (примерно), колкото и малоумно да звучи.

Изобщо не звучи малоумно но е доста работа - точно така би трябвало да изглежда. Надявах се да намеря някой официялен източник с готов подобен анализ. Иначе незнам за какъв период от време се счита за представителна извадка, кои програми трябва да се стартират за да направят някакво натоварване, кои са Х библиотеките за да ги филтрирам само тях. Изобщо доста неща са твърде академични и доста в страни от моите познания. Брей какви неща ги карат хората да правят а ние си чешем езиците :-) .
Ако има и други подобни педложения съм отворен много благодаря gat3way за предложението.

Все още си мисля че oprofile е по-добрата алтернатива (е ще иска малко повече ръчно парсене) но не е непостижимо

Колкото за другите въпроси:
 * Период: да речем 1 седмица е добър подход, осигурява най-пълно покритие. Игрички, документи, филмчета, разработка и т.н. (замислете се защо точно)
 * Натоварване: Бих казал напълно нормална употреба. Браузене, игри, филми. Накратко да игнорира че има нещо което логва процеси и т.н. и просто да се ползва нормално машината
 * Повторяемост: Препоръчително е да се изтъркаля няколко пъти цялото упражнение и за предпочитане с няколко различни човека (за да се изключи едностранчивостта на резултатите)
 * Кои са библиотеките: в дебиан мисля че имаше опция deptree или нещо подобно което правече обратно дърво на зависимостите бих казал че то най-ясно ще покаже какво точно се ползва (но не гарантирам)

Твърде ми е сложно да правя профил. Резултатите трябва да са готови за след седмица и да ги изпратя. Достатъчно е и използваемоста на библиотеките. Хората си разделят задачите малко странно, но въз основа на този проект ще се работи по оптимизирането на скоростта на Х-а. За съжаление ще е вътрешен проект за института им, а много бих искал да видя какви са ги натворили. За сега видях модифициран konqueror работи като изтребител.

Твърде ми е сложно да правя профил. Резултатите трябва да са готови за след седмица и да ги изпратя. Достатъчно е и използваемоста на библиотеките. Хората си разделят задачите малко странно, но въз основа на този проект ще се работи по оптимизирането на скоростта на Х-а. За съжаление ще е вътрешен проект за института им, а много бих искал да видя какви са ги натворили. За сега видях модифициран konqueror работи като изтребител.

:| :|
абе тия що не учат паскал?!?!?!?!?!?!?!?
:( :( :( :(

:| :|
абе тия що не учат паскал?!?!?!?!?!?!?!?
:( :( :( :(

Защото не са в ТУ-София ;)

Какво против Паскал и какво против ТУ? :)

Аааа нищо. Най-обичам да си правя курсовите по Операционни система или Изследване на операциите на Паскал :)

По темата: Нещо ми се върти в главата, вечерта ще се пробвам :)

Това е реалността. Иначе нищо против.  :)

Какво против Паскал и какво против ТУ? :)

ами как защо да си учат там за масиви, процедури и функции...
кво са се захванли с Хикса...
...
иде ми да троша като чета хората на кво ги учат, а ние - паскал...
и до сега май си го продължават това в ТУ нали?

Приложна математика са на Паскал и за ООП Делфи, за КСТ немога да кажа със сигурност, но мисля че и те са на Паскал. :(

Не е вярно. Аз завърших приложна математика преди години и тогава ООП езика беше C++. Преподаваше го един психопат, с който не успях да изляза на глава. Заяжда се за глупости, заяжда се за глупости, заяжда се за глупости, видя че няма да стане и накрая ми писа 5 защото не съм дефинирал оператор за присвояване на моя клас в курсовата работа. Като му обясних че в случая няма нужда и че не е било и като изискване, човекът заключи че това било "каноничния" вид на един клас (каквото и да рече това), рече отсече и ми писа оценката. Те такива работи.

Във втори курс се учи делфи, а С++ е в трети и е избираем :) Добре, че в моята курсова съм си направил опертор за присвояване  :D сега да видим с колко ще ми я оценят :)

Всъщност май и ние имахме Делфи...имам някакви спомени че правих една курсова работа дето чертаеше прости фрактали.

А със C++ внимавай - ако е същия се приготви психически хехе :)

А сега развръзката на серияла (всички са се врътнали по веднъж, цялото семейство плаче от умиление, и главния герой се жени за главната героиня докато лошия отива в затвора).
Не вярвах че такъв дебат ще предизвика една такава тема. Понеже няма да може да се публикуват тези работи до 3 години то мога да направя резюме и да подпаля още фитили.
Разработката е пусната към техническия университет в Мюнхен по индустриално инженерство. Въпроса е да се оптимизира линукс за вградени системи и автоматика.
Наблюдаваните проблеми от възложителя на изследването е слабата производителност на графичните апликации под линукс (моля не спорете наистина е така сравнете работа само на офис пакета и ще разберете за какво иде реч).
Целта е да се подпомогне подобряването на производителността посредством замяна на най-често извиквани малки функции със същите но написани по близо до асемблер с по голяма скорост на изпълнение. Избягва се също използването на сметки с плаваща запетая в тези нови функции.
Как протича до сега проекта:
Пуснали са Х сървер на няколко компютъра с различна архитектура, изследва се за най често използвани библиотеки (gat3way благодаря за идейния принос). На тези системи се 'маймунят' студентите ангажирани в проекта и стартират някакви си техни приложения.
На етап 1 се определя честотата на използвани библиотеки. Най-често използваните библиотеки ще бъдат профилирани по време на етап 2 (zeridon благодаря и за твоя принос) за да се определи от кои функции да се започне първо. На етап 3 ще се направи програма DOE (design of experiment) и ще се раздадат фрагменти от код за оптимизация по така направения анализ и честота на използване.
Целта ще бъде да се пренапишат (по-скоро редактират) тези функции така че да отнемат по-малко време за изпълнение.
Нататъка следва етап 4 вграждането им и етап 5 дебъгване етап 6 изследване на новата производителност.
На практика пари са отпуснати за етап 0 - проучване на проблема и етап 1 и 2. Имената на фирмите са конфиденциална информация и се знае от малко хора ??? но парите са ясни до момента 30000 европейски лева. Такива проучвания колкото и странно да е са най ефтини в университетите (за разлика от нас там е най-скъпо).
Въз основа на резултатите ще се приемат действия за внедряване на тези модификации и за нас в самия проект на "важните" приложения (кои са така и не е ясно).
Но като обобщение за нашите среди:
Тези методи са световно признати така че за разработчиците на софтуер не е зле да се изследва за какво време се изпълнява дадено писание в няколко различни реализации на една и съща функционалност.
Ако някой се интересува как се извършват тези тестове може да се отвори друга тема или нещо подобно. На практика се оказва че е доста просто но се иска малко повече търпение.
По трудно и времемко е да се оправи нещо вече написано отколкото да се внимава и изпипва при писане (Viva LasWin).
Време е да си дадем равносметка че малките победи с нашие ОС (Линукс, фрии БиЕсДи,.....) и пакетите за тях, не печелят войната, нещата са далече от идеалните (малко е силино но...).
Нещата които спъват инвестициите са:
Малката информираност на обществото като потребители, но на първо място са завършващите инженери (ИТ, електроника, програмиране ....) все пак те внедряват софтуера.
Лошата производителност при използване на съвременни графични приложения (света не е конзола). Липса на добри офис решения (говоря за бързина и език за писане за ламери 'счетоводители' като VB).
Липса на интересни за младежтта игри (това е първия досег с компютър обикновенно) дори да са ултра яка графика с много стрелба (натискане на газ) и никъква мисъл (малко са шах любителите).
Липса на интегрирани инструменти за интуитивна (ламерска) настройка които да могат да се адаптират за дадена конфигурация (добър опит е  Убунту там доста неща са оправени по подразбиране).
Липса не превод на български на документация. Не съм съгласен че америчкия е абсолютно задължителен. Докато чете един добър програмист, който е загубил 7-8 години като програмист, и още толкова като математик, на него обикновенно английския не му е перфектен и 20% от сивото му вещество е заето с превода. Защо трябва да ги губи тези 20% като обикновен преводач (е не съвсем обикновен) ако това може да му бъде спестено. 
Какво можем да направим:
Първо - да говорим открито за недостатъците - само ако се признаят недостатъците, проверят, потвърдят, и т.н.т. може да се отстранят. Ако смятаме че всичко е перфектно и колко сме добри - е нищо няма да стане само ще си лаем докато кервана върви.
Да се стегнеме и да започнем не само да използваме а и да участваме в проекти които са ни интересни.
Който неможе да пише софт то може да помогне с преводи, демонстрации консултации и т.н.т.
Какво ни е най-голямото постижение като Българи:
Това е добрият превод на български на приложенията. Признато е от чужденци, които знаят български, че българският превод е по добър отколкото немския, френски и испански.
Кой е най големият ни провал:
"О неразумний юроде ти що се срамиш да четеш и пишеш на Болгарски ...." - Въпреки добрият превод, много от нас си предпочитат да им е на английски - така им било "по-лесно" - несериозно обяснение. Аз не съм виждал французин с винбоза на английски всичко е на френски. За немците е същото. Е ние сме най англичанчета, по англичани от ирландците че и те го ползват на техния диалект . Направо Абсурдистан Булгаристан - провинция на Амеркан.

П.С. Повечето неща съм ги предал възможно най-близко с разговора с г-да Професорите от Мюнхенският институт по ИИ. Пропуснал съм някои части, имена и т.н.т. които не са за разгласяване. Пропуснал съм и моята реакция и див скандал който им дигнах (без да имам право) заради отправени критики към моят познат. Пропуснал съм и търпението и вниманието с което ме убедиха (аз пък се и съгласих) че не съм прав и греша. Съвсем малка част е мое лично мнение, но аз съм съгласен на 99% с тях, и съм убеден че са прави. С две думи "открий си проблемите за да ги отстраниш".