W pełni się zgadzam.

Co do błędów – są poprawiane te, które znajdę. Poza błędem w parserze ElementTree oraz złym importem ET w nie wspieranym Pythonie 2.4, nikt nie zgłosił mi jeszcze błędu. (Kod nie był jeszcze bardzo dokładnie sprawdzany, może dzisiaj zacznę się z tym bawić.)

Co do zwiększania wydajności – wyrzucam niepotrzebne importy i staram się importować tylko potrzebne rzeczy – to powinno zredukować trochę zużycie pamięci. Zużycie pamięci przez struktury danych OK jest minimalne. W trzech trybach działania (1, 3 i 4) ścieżka wykonania kodu po uruchomieniu całej maszynerii jest ograniczona do trzech prostych funkcji (dla użytkowników, grup czy programów – zależy od konfiguracji)
add_tasks_to_cgroup
get_pids
write_to_file
Przy standardowych ustawieniach długości cyklu są one wywoływane co 20 sekund. Tryby 0 i 2 są trochę bardziej skomplikowane, ale zamierzam to uprościć.

Jeśli ktoś nazywa OK zamulaczem, to uważam, że nie przeprowadził rzetelnej analizy problemu.

"Zamula – czyli zużywa dużo pamięci – python i jego maszyna wirtualna."

Z tego co zaobserwowałem, to zużycie pamięci przez Pythona w trakcie działania OK wynosi trochę ponad 8MB na F9 Beta
(VmPeak: 8420 kB
VmSize: 8344 kB)
zgadzam się, że jest to dużo – szczególnie dla ludzi przyzwyczajonych do skrajnego oszczędzania. Jednak te 8MB na komputerze wyposażonym w 1 GB pamięci to niecały 1% zasobów. Wystarczy policzyć jaki zysk można osiągnąć przez używanie OK aby zdecydować, czy warto poświęcić 8 MB pamięci na Pythona.

"Dlatego użycie go do napisania demona, i to demona służącego do przyspieszenia działania systemu, jest co najmniej dziwne."

Aktualna wersja OK służy nie tyle do samej optymalizacji działania systemu oraz zarządzania grupami kontrolnymi. Dla mnie jest to też narzędzie do przeprowadzania badań nad optymalizacją pracy systemu – dzięki temu, że jest napisane w Pythonie mogę bardzo szybko dopisać nową funkcjonalność i sprawdzić co ona daje.

Przez ostatnich parę dni sprawdzałem jak można przyspieszyć start Fedory 9 (bardzo trudny przypadek… ;)) – np. napisałem moduł zbierający dane o programach uruchamianych w trakcie startu systemu (napisanie tego w C byłoby męczarnią), następnie programy razem z bibliotekami były prefetchowane – okazało się, że prefetch podczas startu systemu praktycznie nic nie daje a często może zaszkodzić. Przeprowadzenie tych eksperymentów z użyciem Pythona było prostsze i szybsze niż gdybym używał C – w ten sposób poświęciłem 1 dzień na zbadanie wpływu prefetchu na czas startu systemu. Gdybym używał do tego C musiałbym poświęcić dużo więcej czasu – a ja nie lubię go marnować.

"Nie lepiej było z gotowego bootcharta skorzystać?"

Zrobiłem to trochę inaczej – parsowanie skryptów startowych w poszukiwaniu binarek nadających się do prefetchu.

Oczywiście mógłbym spróbować przefiltrować dane gromadzone przez bootchart (po wyrzuceniu wszystkich około kernelowych procesów), jednak z tego co widzę to mogłoby to być trochę więcej roboty z przynajmniej dwóch powodów: a) bootchart ucina nazwy procesów np. hald-addon-stor – trzeba by było spróbować jakoś to obejść b) mam poważne wątpliwości czy gromadzi wszystkie informacje o procesach używanych podczas startu – rc.sysinit wraz z moim rcS-mount-kernel-pseudo-filesystems przynajmniej kilkakrotnie montują różne systemy plików, bootchart zarejestrował tylko pojedyncze użycie mount. Dziwne, prawda?

"ale to zupełnie inna jakość niż odpowiedź developera FALF Player na analogiczne pytanie, jaką ongiś otrzymałem (”Jeśli sam nie umiesz programować, STFU”)."

Ręce opadają…