Názory k článku Dlaždice trochu jinak: rozšíření správce Awesome

Autor byl uz na tento blud opakovane upozornovan a ze opisuje cisla jejichz vyznamu zjevne vubec nerozumi. Misto aby se chytil za nos a omyl napravil, tak dal pokracuje v demonstraci sve nekompetentnosti. To uz hranici s ignoranstvim.

Memory plugin z xmobaru (pominu ze v clanku byla uvedena nefunkcni konfigurace) skutecnou spotrebu pameti procesu neumi a nikdy neumel a slouzi jen k hrubemu zobrazeni celkove obsazene + rezervovane pameti, tzn. vcetne virtualni o ktere autor evidentne netusi co znamena. Upozornoval jsem na to, ze timhle skutecnou spotrebu nelze merit a ze xmobar k tomu ucelu nabizi monitor TopMem, ale je to marny, je to marny …

Jen pro dokresleni, nainstaloval jsem nejaktualnejsi verzi subtle, awesome 3.5.5, xmonad 0.11 a xmobar 0.21 a uvadim realne obsazeni pameti (RSS, swap vypnuty) a take X (RSS, vliv alokace zdroju spustenym WM):

• subtle 14982 (14,6 MiB), X 34112 (33,1 MiB)
• awesome 13548 (13,2 MiB), X 31816 (31,1 MiB)
• xmonad 8320 (8,1 MiB), xmobar 16616 (16,2 MiB), X 26872 (26,2 MiB)

Testovano s vychozi konfiguraci.

p.s. Pro příště: pokud mi u měření srovnatelných jevů vychází diametrálně odlišné číslo, s velkou pravděpodobností je někde chyba a začnu pátrat po příčině. To je ale elementární logika, na kterou stačí selský rozum.

Problém je asi s velikostí alokované virtuální paměti procesu. Já XMonad taky používám a top mi ukazuje VSZ přes 200 MB a RSS kolem 10 MB. Garbage collector haskellu zřejmě rezervuje víc paměti než je běžný u programů napsaných v cécčku s ruční správou haldy. Faktem je jak píše předřečník, že fyzicky obsazená paměť včetně swapu se plus mínus drží kolem těch 10 mega i když běží třeba měsíc v kuse.

> XMonad je ale hlavně díky nutnosti instalace GHC slušný moloch

Stejně tak můžu říct, že

#include <stdio.h>
int main() { printf("Hello world\n"); }

je slušný moloch kvůli nutnosti instalace gcc.

áno je to slušných 41 Kb :-)

tak dobre, veľkosť nainštalovaného gcc mi aptitude ukazuje na 42 kB :-))

To byste teda nemohl. Ten program by musel vypadat zhruba takto:

...

int main() {
if ( filetime("/et­c/config.c") < filetime("/et­c/config.o") ) {
system("gcc /etc/config.c -c -o /etc/config.o");
}
dlopen("/etc/con­fig.o");
}

...

Pak by teprve binarka vyzadovala nainstalovane gcc. Stejne jako v pripade xmonadu. Konfigurace je od toho aby se dalo snadno upravit chovani programu. U programu jako je windowmanager je potreba menit konfiguraci casto, protoze clovek postupne upravuje navyky a pridava do konfigurace dalsi a dalsi vychytavky. (Ted mam na mysli opravdove windowmanagery, coz jsou vetsinou prave ty dlazdicove. Ty ostatni vetisnou nechaji spravu oken (ve smyslu velikosti, virtualnich ploch a toho ktere je na vrchu) na uzivateli. )

Pardon, nerovnost je obracene. Ale jinak by mela byt jasna idea.

> Pak by teprve binarka vyzadovala nainstalovane gcc. Stejne jako v pripade xmonadu.

Jenže vtip je v tom, že binárka XMonadu nainstalované ghc nevyžaduje. Takže si myslím, že jsem použil správné přirovnání.

Navíc já jsem reagoval na úplně jinou věc. Autor totiž tvrdil, že XMonad je obrovský moloch pouze kvůli tomu, že je pro jeho kompilaci potřeba nějaký konkrétní překladač (který není nejmenší). Ta logika prostě nedává smysl. Navíc pokud vám stačí výchozí konfigurace, tak ten překladač nemusíte vůbec instalovat.

U mnou předvedeného programu je také potřeba gcc jen v případě změny konfigurace (ano, musel by být napsaný o trochy lépe, než jsem naznačil). A to co se snažím říct je, že použít winowmanager typu XMonad s defaultni konfiguraci je jako jezdit s Ferari z D5 na D1 skrz centrum Prahy (protoze prece pres centrum se dostanete vsude).