Ještě si dovedu představit jeden druh rozhraní: Vzdálené grafické. Byl by to tlustý klient a připojoval by se (přes SSH, TCP nebo HTTP) ke spravovanému systému. Dal by se tak spravovat i lokální systém - výhodou by bylo, že GUI aplikace by nemusela běžet pod rootem.
Jako ideál bych viděl XML konfigurační soubory, nad kterými si napíše kdo chce co chce (rozhraní). A chtělo by to přidat tyto vlastnosti: Překrývání uživatelským nastavením - některé vlastnosti by si mohl předefinovat uživatel, ostatní by se braly ze systému. Verzování - celé /etc by se mohlo spravovat třeba pomocí subversionu, správce by pak viděl, co kdy změnil a nemusel by si psát nějaké trapné komentáře. Taky by bylo možné se při chybě snadno vracet zpět k fungující konfiguraci.
Vazne chceme navrhovat GUI v konfiguraku? ;-)
A co Firefox, Thunderbird ad. (byv. Mozilla)? Ty maji GUI v XUL (XML User-interface Language). IMHO nevypadaji az tak spatne ;) Nad takovym abstraktnim prostrednim se pak muze napsat jiz jakykoli klient (GUI/TUI, lokální/vzdálený), ktery "pouze" prelozi XUL do GTK/QT/Widli.
Tahle myslenka neni az tak spatna, vyuziva moderni prostredky a prinesla by potrebnou flexibilitu. O "hezkost" prostredi bych se az tak nestaral - jestlize lze navrhnout hezke prostredi primo v programu, pujde to i pomoci strukturovaneho jazyka XML.
Ad redundance - pokud bude konfigurace jednotna, standardizovana a snadno udrzovatelna, mozna par bajtu navic neni tak strasnou cenou.
A proč pořád ty textové soubory? Jak se udělá validace? Kvůli tomu budeme něco programovat? Proč nepoužít XML a schémata, kde validace funguje sama od sebe? Problém obyčejných textových souborů je rovněž v nemožnosti vyjádřit složitěji strukturovaná data.
U textu nemám možnost formální validace - to je jasné. Na druhou stranu formální validace v XML je pro řadu vazeb nedostatečná (vím o čem píši, pár xml schemat už mám za sebou), nad formální XML validací ještě občas potřebujete další aplikaci. Dost dobře vím, co se dá schématem vyjádřit a co ne. Jinak, tam kde je potřeba vyjádřit složitější strukturu, tak tam už se XML dávno používá. A ohledně výhod plain textu - snažší vyhledávání, editace, diff. Někdo rád gedit, jiný vim, třetí emacs nebo joe. Prostě Vám nikdo nenutí, co máte používat.
Non BFU se od BFU liší hlavně v tom, že BFU neví, co dělá - zkouší to. I když nakliká formálně správnou validací, tak to neznamená, že neudělal kardinální blbost. Proto se používá plain text, pro zkušeného uživatele je řádově správa jednodušší a efektivnější než GUI. Na druhou stranu je to tragédie pro BFU. Pravda je taková, že BFU nemá co konfigurovat comp. Ten ho pouze používá.
Ale prispeje. Mit kod cisty znamena nadrit se mene v budoucnosti, a tedy usetreni na nakladech. Ale pokud firma planuje 1 max. 2 verze dopredu, jak je tomu obvykle, tak tuhle usporu nemuze nikdy spatrit. Vzdycky se s tim pak radeji vyporadaji tak, ze sezenou vic vyvojaru, kteri to nejak pro tu chvili zbastli. OSS vyvojar predpoklada, ze jeho SW tu bude vzdycky, takze muze venovat vic casu na cisty kod, lepsi pomocne nastroje ke svemu projektu apod.
Nerikam, ze neco je lepsi nez to druhe. Trh optimalizuje na tak sotva 3 roky, a jsou k tomu dobre duvody (po 3 letech uz muze byt firma mrtva). OSS vyvojar je na trhu nezavisly, tak optimalizuje na delsi obdobi. Ale je jasne, ze na cim delsi obdobi optimalizujete, tim efektivnejsi jste (pokud ovsem udelate spravne predpoved, coz je stale vetsi problem pri delsim obdobi). Naopak tvrzeni o tom, ze je neco efektivni, bez uvedeni casoveho horizontu pro ktery se optimalizuje, nedavaji smysl.