Portál AbcLinuxu, 4. května 2025 15:36
Často se tu objevují něčí stesky, že by chtěl dělat nějaký projekt z oblasti svobodného softwaru (ať už do školy nebo třeba jen pro zábavu či jako pomoc komunitě), ale neví, co by to přesně mělo být. Pár námětů bych tu měl.
Jsou to dva opačné póly - na jedné straně chybí spousta věcí, na straně druhé je mnoho lidí, kteří by chtěli něco dělat. Když se nenajde společný bod, zbytečně se plýtvá energií. Vzniká mnoho projektů, které řeší stále tytéž věci, přitom některé oblasti nejsou vůbec pokryté.
Proto jsem se rozhodl zveřejnit tady pár námětů. Jde vesměs o věci, které považuji za velmi důležité. To samozřejmě neznamená, že by důležité nebyly i jiné věci, ale jednoduše jsem vybral pár těch nejpalčivějších (ve smyslu toho, že nejvíc chybí). Proto kdo chce něco (o prázdninách i jindy) tvořit, nechť se podívá do následujícího seznamu a třeba mu něco z toho přijde jako vhodné téma. Myslím, že to bude lepší, než tvořit milióntý první CMS pro web.
Už jsem o tom kdysi hovořil. Aplikační programátoři na GNU/Linuxu mají oproti těm "windowsovým" jeden velký handicap - bídnou referenční dokumentaci. Pokud se chci podívat třeba na použití funkce pthread_setschedparam(), nic mi nestojí v cestě. Nemám ovšem žádnou šanci snadno zjistit, že mám pro daný účel (tedy pro nastavení plánovače a priority vlákna) použít právě tuto funkci. Existuje sice jakési torzo, ale je 6 let staré, neobsahuje všechno (ani z tehdejší doby) a je to spíš naučná příručka než referenční dokumentace.
To, co chybí, je strukturovaná dokumentace standardní knihovny (glibc) a knihoven souvisejících (libpthread, librt, libm atd.). Idea je taková, že se použijí existující manuálové nebo info stránky (kategorie 2, 3, příp. 5) a uspořádají se do hierarchie. Mohlo by to vypadat třeba takto:
-Process management |- ... -Threads and synchronization |- Threading basics |- Thread attributes |- Synchronization objects | |- Mutexes | |- Read-write locks | |- Condition variables | |- ...
Snad je to dost srozumitelné. Jde o to, navrhnout strukturu stromu, pak jednotlivým uzlům přidělit identifikátory a těmito identifikátory "označkovat" jednotlivé manuálové stránky (jedna může mít více identifikátorů). Posledním krokem je samozřejmě vygenerování dokumentace jako takové v různých formátech - určitě v HTML, možná v TEXu atd.
Kdyby někdo hledal inspiraci, najde ji třeba v MSDN v dokumentaci k Visual C/C++ (tím v žádném případě neříkám, že by to mělo být stejné!). Výsledkem by měla být dokumentace, kde každý najde potřebné funkce a datové struktury podle toho, co chce naprogramovat.
UPDATE: Takový projekt už vznikl. Kdo se chce zapojit, má možnost.
Velkým problémem současného softwaru je pomalý disk. Zatímco všecho se zrychlilo a zvětšilo, rychlosti disků nemají tendenci příliš růst a vzniká tu pořádné úzké hrdlo. Při poměrně nízkých cenách polovodičových pamětí není problém dát do systému větší množství paměti a přístup k datům tak zrychlit. Jenže takto se zrychlí pouze přístup k datům, která již byla z disku načtena. A o to tu právě jde.
Zejména krátce po startu systému je většina paměti nevyužita, přestože by mohla výrazně pomoci zrychlit přístup k datům. Takže není nic jednoduššího, než tam data natáhnout. Klíčovou otázkou ale je, která data to mají být. Můžeme mít démona, který bude podle určitých pravidel (např. podle stavu využití paměti přednačítat data. Musíme mu ale nějak říkat, jaká data zvolit.
Cílem tedy především je, navrhnout algoritmus (heuristiku) nebo více přepínatelných algoritmů pro volbu vhodných dat. Algoritmus může například nějak využívat zvyklosti konkrétního uživatele (které programy spouští těsně po startu, jaké dokumenty nejčastěji otvírá atd.) nebo serverových démonů běžících na počítači. Scénářů je mnoho, najít ten nejlepší nebude jednoduché a stejně to asi povede na více odlišných parametrizovatelných algoritmů.
Až bude toto hotovo, stačí už jen napsat démona, který bude data přednačítat. To už je v podstatě triviální úkol, dokonce někde nějakého takového démona mám, kromě toho už existují projekty, které jeho implementaci řešily.
Opět další nástroj na zrychlení přístupu k datům. Tentokrát jde ale o program, který bude jednak schopen analyzovat, jaká data se načítají společně a v jakém pořadí, a následně (po určité době sledování) přeuspořádat souborový systém tak, aby se načítalo bez zbytečných přesunů hlav (tj. co nejvíce lineárně).
Jako příklad mohu uvést spouštění OpenOffice.org. Balík je složen z mnoha souborů, které se z velké části načítají vždy stejně a ve stejném pořadí. Proto by tu šla provést optimalizace. Podobně třeba prostředí KDE a GNOME.
Je jasné, že se nástroj bude pro různé souborové systémy lišit. Bylo by ale dobré, aby byl aspoň pro ext2 a ext3, nejlépe též ReiserFS a pár dalších systémů. V každém případě by ale mělo jít o nástroj pracující v uživatelském prostoru (ne v jádře).
Již delší dobu existují v jádře tzv. rozšířené atributy souborů. Jedním z jejich účelů jsou také přístupové seznamy (ACL), umožňující jemnější a pohodlnější správu přístupových práv, než jaká je k dispozici přes standardní mechanismus uživatel-skupina-ostatní.
Problém ovšem je, že neexistují nástroje, které by s tím uměly pracovat. Existují jen konzolové utility, a to je žalostně málo. Proto bych viděl jako velmi důležité implementovat nástroje pro práci jak s rozšířenými atributy (uživatelskými), tak hlavně s ACL. Mám na mysli nástroje pro KDE (nejlépe jako součást Konquerora), GNOME a pokud možno také Midnight Commander. Mám na mysli nástroje pro GNOME (Nautilus) a Midnight Commander; v KDE (Konqueror) již podpora ACL existuje, ale vzhledem ke špatné srozumitelnosti by zasloužila revizi (přinejmenším do KDE 4).
Udělat takové utility není vůbec těžké, ale prostě to zatím nikdo neudělal. Takže současný stav je takový, že někteří uživatelé by to využili, ale nemohou - a samozřejmě se ohánějí stavem na Windows, kde je práce s ACL vcelku jednoduchá.
Většina svobodných programů má problémy s rychlostí. Jejich tvůrci se snaží do programů dostat co nejvíc "fíčur", výkon ale trpí. Proto, kdo by měl zájem, může poštvat profiler na libovolný program, pokud možno nějaký hodně používaný. Je dost možné, že se podaří odhalit nějaké nevhodně zvolené algoritmy, zbytečné opakované zjišťování hodnot (místo jejich ukládání) a jiné podobné brzdy.
Jako zvlášť důležitou bych viděl profilaci knihovny GTK+, resp. programů na ní založených. Nejsem sám, komu pomalost této knihovny pije krev. Určitě se podaří najít cesty, jak by šla zrychlit.
Možná jsem něco nepopsal úplně srozumitelně. Kdo by něčemu nerozuměl, rád to v diskusi vysvětlím. Každopádně ale věřím, že předložené náměty někomu pomohou při hledání vhodného projektu k realizaci. I když třeba nepůjde přímo o některý z těchto projektů, mohlo by to fungovat i jako obecná inspirace.
Tiskni
Sdílej:
v glibc aby se občas prasátko vyznaloTo je především tím, že jsou tam smixovány věci z POSIXu, *BSD, System V a z lecjakých dalších zdrojů. Pak jsou pro jeden účel třeba tři různé funkce s podobným názvem, ale různým počtem nebo pořadím argumentů a různým chováním. Též tam figurují staré funkce nevhodné pro multithreadové prostředí a jejich modernější náhrady.
man memcpy
, kde svítí datum 1993-04-10, nebo man socket
s datem 4. dubna 1997 socket()
zrovna ano - ne v syntaxi, ale v podporovaných rodinách a protokolech (ale ani tehdy nebyly zdokumentovány všechny).
Pokročilá oprávnění
- otevře se panel, ze kterého ale není hned jasné, že lze také pracovat s ACL), zasloužil by revizi.
Online dostupna treba http://www.gnu.org/software/libc/manual/html_node/index.htmlThis is Edition 0.10, last updated 2001-07-06, of The GNU C Library Reference Manual, for Version 2.2.x of the GNU C Library. Ehm... To je bohužel přesně ta obstarožní verze, o které jsem mluvil.
Osobne me prijde nejpraktictejsi v info-formatu.O tom by se dalo polemizovat. Příznivcům editoru VIM asi nejpraktičtější přijde, ale mně osobně přijde nejpraktičtější HTML.
To by znamenalo, že se všechny stránky aplikace odloží na disk a to sekvenčně.Nestačilo by jednoduše ve WM aplikaci skrýt a při dalším kliknutí na ikonku její okno znovu zobrazit? Možná ji ještě odříznout od smyčky zpráv ...
oom_adj
zapsala hodnota 15 (maximum), která říká, že takový proces je při sestřelování výrazně prefereován. Co se týká plánování, lze nastavit plánovač SCHED_BATCH
a nice na hodnotu 19. Při "probuzení" se to pak vrátí do původního stavu. Zjednodušeně např. takhle:
void sleep_process(pid_t pid) { char path[50]; sprintf(path, "/proc/%d/oom_adj", (int) pid); FILE* f = fopen(path, "w"); fprintf(f, "1"); fclose(f); struct sched_param sp = { .sched_priority = 0 }; sched_setscheduler(pid, SCHED_BATCH, &sp); setpriority(PRIO_PROCESS, pid, 19); }Při plnohodnotné implementaci by se hodnoty uložily a při "probouzení" použily.
Tak to se da spise udelat lepe, ze se zoptimalizuje spousteni aplikace. Coz se u OO2 deje. A asi jsou zde rezervy. Prednacitat data je podle me na nic. K prvnimu spusteni aplikace, ze si pockate par vterin vice ? Na co? A ze Word startuje o vterinu rychleji ? Je to i o volbe filesystemu. V kernelu snad i nejaka podpora je. Nebo nejaky projekt+filesystem na toto tema je. Ale kazdopadne nejvice problemu je na strane aplikaci. Nebo si to hodte do ramdisku, kdyz uz to musite mit o par vterin rychlejsi. Jenomze tady si lidi jaksi neuvedomuji, ze doba startu je zanedbatelna s dobou, po kterou s aplikaci pracuji.a) Zkoušel jsi někdy psát tak, aby to nevypadalo, že to vymýšlíš vícevláknově a píšeš podle toho, jak se jednotlivá vlákna dostávají k výstupu? b) k tomu poslednímu odstavci - doba startu nijak nesouvisí s dobou, po kterou budu s aplikací pracovat, nevidím tedy důvod, proč by i start nemohl být rychlý, obzvlášť když se vývojáři tím pádem budou moci starat o rychlý běh programu a rychlejší start nechat na tom hypotetickém démonovi. OO2 jsou krásný příklad - startují pomalu, běží pomalu... to že někdo zoptimalizoval spouštění je mi jaksi úplně k ničemu.
start @ Idea Pool
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.