Vlákno názorů k článku Linuxu chybí univerzální konfigurační systém od curley - Každému, kdo už léta s Linuxem pracuje jako...

Každému, kdo už léta s Linuxem pracuje jako nástroj v práci, t.j. píše dokumenty s OpenOffice, programuje v Eclipse a podobné příklady je důležité zminimalizovat čas, který stráví s administraci systému. Jen fanatik chce půl dne studovat konkretní textové konfiguráky k účelu jak přidat tiskárnu, zaintegrovat se do cizích sítí na služebních cestách a všeobecně spolupracovat s Windowsem ve firemních sítích, a nebo otevřít databázový port přes vlastní firewall. Prostě způsob konfigurace podle principu Gentoo je v praktickém "byznysu" nemyslitelné, alespoň natrvalo.
Kdo použivá počitač jako nástroj a nehodlá se zrovna seznámit s konkretní části OS bude vděčný za konfigurační nástroj. Všichni ostatní studenti (byl jsem takovým dřívě taky) ať poeditujou konfiguráky ve VI, nic proti tomu. Myslím, že znát syntax konfiguráku není žádné vyšší vzdělání, a pokud se člověk s ním nezabývá každý den, pak ho stejně rychle zase zapomíná.
Pracuju v práci s openSUSE 10.3 a jsem až na nějaké drobnosti velmi spokojený s YaSTem. YaST prochází také evoluci, a nebyl od začátku tak pěkný jako teď. Pochybuji, že si někdo, kdo zrovna neadministruje počitače každý den nakonfiguruje tolik věcí najednou rychleji.
Doma mám Kubuntu Gutsy a tam je těch možností už míň - ale doma mně to zase až tak nevadí, protože už čas nehraje takovou roli, doma se můžu učit. Také Gentoo 2007.1 jsem si už zkusil a považoval jsem ho za poučné.
Když jsem ještě studoval v roce 1993/94, jsem použival první distribuce Debianu a nexistoval žádný nástroj, také jsme seděli v každý volné minutě před bednou a experimentovali. Teď jsem jen rád, že si někdo vymyslel YaST, KDE Control Center a podobné kusy softwaru.
Ale univerzální nástroj pro konfiguraci Linuxu by _mohl_ být geniální, ale rovněž mně nevadilo kdyby makáči u různých distribucí vyrobili svoje. Konkurence by taky v Open Source mohla oživit projekty, i kdyby to bylo jen za hubičku a pochvalu.

Pokud jde o YAST, tak jedinou jeho výhodu vidím v obsáhlosti. Naopak vidím hned několik nevýhod.

1. Je špatně integrovaný do desktopových prostředí jako KDE a GNOME, úmyslně nerespektuje jejich zvyklosti (konfigurace v KDE by měla být uložena v kcontrol/systemsettings atd.)

2. Je to velká, nenasytná obluda - co jsem slyšel, definuje si pro konfigurační dialogy nějaký vlastní jazyk.

3. Je úmyslně neportovatelný na jiné distribuce. Tedy on portovatelný je, ale potřeboval byste několikačlenný vývojový tým a několik měsíců času. Důvody jsou alespoň tři - jednak je každá distribuce o krapet jiná a YAST je najisto natvrdo uzpůsobený SUSE, jednak bod 2. a jednak to, že Novell to tak chce - takhle mohou YAST distribuovat pouze SUSE-like distribuce.

Dokud firmy jako Novell budou kopat jen za své distribuce a budou házet klacky pod nohy vizím jako je unifikované konfigurační rozhraní pro všechny distribuce společné (a nedej bože i pro ne-Enterprise verze!), tak máme smůlu. Můžeme poděkovat tomu starému "closed-source" myšlení.

1) Co má YaST společného s konfigurací KDE a GNOME? Na počítači s YaSTem přeci vůbec žádné KDE a GNOME ani být nemusí, dokonce tam nemusí být ani normální login účet pro běžného uživatele.

2) FUD. Ten "nějaký vlastní jazyk" je značně úsporný, generuje kompaktní bajtkód, je léty prověřený a funguje. Nechcete snad říct, že by se vývojáři YaSTu měli soustředit na přepsání YaSTu do Javy či co?

3) Takže *je* portovatelný. Jenom nikdo nezvednul svůj línej zadek a nenaportoval ho. Podívejte, SUSE zcela pochopitelně vyvíjí YaST pro sebe. Už to stojí dost času a práce, proč by měli dělat práci za jiné distribuce? V YaSTu není nic "úmyslně neportovatelného" a veškerý kód je volně přístupný.

1) že by měl KDE a GNOME frontendy, které by se měly chovat slušně alespoň v prostředí, pro které byly naprogramovány?

Ten "nějaký vlastní jazyk" je značně úsporný, generuje kompaktní bajtkód, je léty prověřený a funguje.

Jo, funguje. Možná je jeho bajtkód kompaktní, ale na starších počítačích IMHO příliš rychlý nebude (budu rád, pokud mne příště "uzemníte" nějakým důkazem, ne nepodloženými tvrzeními).
3) Ten samý argument slýchám od zastánců OOXML. To *je* rovněž naportovatelné... tak proč ho už všichni nepoužíváme v OpenOffice.org, KOffice a vimu? Ach, vskutku, může za to lenost programátorů, zvláště pak těch, co pracují zadarmo, ti jsou největší lenoši.

proč by měli dělat práci za jiné distribuce?

A proč by nějaká firma měla dělat svůj software "ohleduplný" a podporující jiné platformy? Měli bychom raději všichni aktivně bránit naše intelektuální vlastnictví.

A co přesně KDE frontend dělá špatně? ;-)

ale na starších počítačích IMHO příliš rychlý nebude (budu rád, pokud mne příště "uzemníte" nějakým důkazem, ne nepodloženými tvrzeními).

Hlavně že Vy mě "uzemňujete" tunami důkazů a ne jen dohady. Tak namátkou - timing načtení konfigurace různých modulů a její uložení na počítači s 1GHz procesorem:

# time yast users

real    0m5.857s
user    0m3.152s
sys     0m0.680s

# time yast lan

real    0m4.339s
user    0m2.464s
sys     0m1.180s

# time yast disk

real    0m6.791s
user    0m2.928s
sys     0m1.524s

# time yast repositories

real    0m5.038s
user    0m1.756s
sys     0m0.804s

# time yast sshd

real    0m10.861s
user    0m0.616s
sys     0m0.136s

# time yast mail

real    0m10.226s
user    0m3.180s
sys     0m1.188s

Tak to je opravdu strašně náročné. Naparsovat konfiguraci, prezentovat uživateli, znova ji uložit. S transakčním zpracováním všech operací a důkladnými logy na požádání. U většiny věcí pod tři sekundy User CPU time na stroji, který bych koupil jako poslední výkřik techniky někdy v roce 2001, možná. Nechci prudit, ale Vy asi musíte Novell hodně nenávidět.

proč by měli dělat práci za jiné distribuce?

A proč by nějaká firma měla dělat svůj software "ohleduplný" a podporující jiné platformy? Měli bychom raději všichni aktivně bránit naše intelektuální vlastnictví.

Vy jste, s prominutím, kus vola. Různé distribuce různě balíčkují různý software, mají vlastní defaultní konfigurace a tak, a Vy čekáte, že vývojáři SUSE budou procházet /etc jiných distribucí a dělat switche v SCR agentech, podle toho, jak se třeba frantík v Mandrive zrovna vyspal a rozhodl se rozdělit nebo nerozdělit httpd.conf na tři, sedm nebo deset souborů a jak vyřešil vhosty? Vývojáři YaSTu velmi úzce spolupracují s balíkáři v SUSE. Budete po nich chtít, aby začali totéž řešit s balíkáři jiných distribucí? Právě proto, že tohle je "distribučně závislá" věc. To už můžete rovnou obvinit Debian z toho, že jeho /etc strom není ohleduplný k YaStu. To, že si distribuce, která chce YaST používat, vyhradí pár lidí na to, aby nejnižší konfigurační vrstvu YaSTu nasadili nad vlastní konfiguraci, je jediná možnost.

Neodmítám to, netvrdím, že YaST se má migrovat, ale YaST je ohledně designu nejlepší inspirace.
V openSUSE funguje bezvadně a neviděl jsem zatím podobně vymakaný nástroj, máš všechno na jednom místě - je v tom tá mohutnost a je to špatné? Myslím, že to je právě ono - integrace a najít všechno na jednom místě. A opakuju, jde o nápad a design.
GNOME nepouživám, ale umím si zatím ještě logicky rozlišet nastavění systému a nastavění KDE desktopu. Dodělat integraci Yastu s KDE určitě nebude taková práce, byl by to krok "nice to have". Áno, třeba si musím nadefinovat nastavění http proxy dvakrát - v systémových proměných a v KDE Control Centeru - souhlasím, zatím.

Ale mám ještě jinou otázku: Máš nějaké konkretní příklady, proč by se YaST nedal snadno migrovat do jiných distribucí? Největší práci bych viděl na aktualizaci softwaru, že podporuje YUM a YaST repositories. Ale přidání jiných repositářů funguje třeba ve smartu, takže nemožné to nebude. A jinak? (Určitě se Ti povede najít něco, nějakou rozdílnou cestu a nebo pod., ale zásadně...)

Nícméně si myslím, že YaST je hodně dopředu a jsem za to vděčný, ušetřilo mi to už hodně času.

Nikoli, taková mohutnost je správná. YaST, který vidí uživatel, je poměrně dobrý nástroj. To "nepěkné" je až uvnitř.

Jedna z nevýhod YaSTu je jeho přístup. Má naivní vize říká: pokud SUSE (a kdokoli jiný) využívá zdrojového kódu třebas KDE, měl by svoje vlastní projekty vyvíjet tak, aby z toho měli výhody i ti vývojáři KDE, kteří zrovna pod SUSE nepracují. Vývoj rozhraní pro KDE by tedy podle mého měl probíhat v KDE SVN, kde sídlí i ostatní projekty z KDE, čímž by se také zajistilo, že by se toto rozhraní muselo "oddrátovat" od SUSE samotného.

Navíc by mělo rozhraní pro KDE respektovat již stávající rámec konfigurace KDE, tedy KControl/systemsettings. Pokud by se konfigurační moduly YaSTu bezchybně integrovaly do KControlu/systemsettings, kde by byly vidět stejně jako standardní KDE nastavení, byl bych spokojen. Styl, kdy něco musíte nastavit v YaSTu, něco v KControl atd. se mi zdá poněkud nešťastný a neintuitivní. KDE frontend je něco, co KDE rozšiřuje, nikoli "zneužívá". Doufám, že je jasné, co jsem chtěl říci.

Problémem současného YaSTu je, že nabobtnal do takového rozměru, že už není v silách individuálních vývojářů (dobrovolníků) naportovat YaST do jakékoli jiné distribuce. Nemůžeme se na ně hněvat nebo je obviňovat z lenosti - vlastní konfigurační jazyk a jeho interpret, několik frontendů ... věřím, že kdyby se nějaký nadšený programátor Franta rozhodoval, bylo by pro něj jednodušší napsat nový konfigurační modul do KDE než portovat YaST. Na to prostě někdo, kdo za to není placen, nemá.

Kdo by tedy měl naportovat YaST do jakési "neutrální" verze, která jde spustit na vícero distribucích, pokud to nadšenci nedokáží? Musela by to udělat nějaká firma. Jenže bohužel, jak jeden komentátor správně podotkl výše, firmy se soustředí na zisk. Novellu samotnému by neutrální verze YaSTu nepřinesla žádný viditelný zisk, pouze respekt komunity. Naopak pro ostatní, menší firmy (jako je třeba Canonical) by portování YaSTu znamenalo zaměstnat skupinu vývojářů po několik měsíců, a i potom by byl hlavní kód YaSTu plně v rukou Novellu. Novell by potom mohl snadno "zabít" takovéhle snahy o portování tím, že by nové vlastnosti přidával jen do toho "svého" starého YaSTu, takže by se vlastnosti musely portovat znovu a znovu a znovu.

Pokud to shrnu: Pokud by Novell samotný nechtěl podpořit tuto snahu vytvořit "univerzální konfigurační systém" z YaSTu, mohl by snadno takovou akci potopit. A jemu se do takové akce nechce, protože zisk by mu to nejspíš nepřineslo žádný.

Slovo "univerzální" je pro mne úzce spojeno se slovy "standardní" a "nezávislý". HTML je tak univerzální právě proto, že nad ním nemá kontrolu jen jedna firma, ale neboť se vyvinulo na nezávislé půdě. Souhlasím, YaST jako nástroj ukazuje, jak by přibližně měl výsledný "univerzální konfigurační systém" vypadat. Zdá se však, že Novell má v současnosti zájem spíše o portování technologií Microsoftu ( Mono, Moonlight - což jistě přináší Novellu nové zákazníky a nové finance, nemůžeme se mu tedy divit) než o vytvoření kvalitního konfiguračního nástroje nezávislého na distribuci, doporučuji se kódu YaSTu vyhnout a stavět raději na otevřenějších, přátelštějších programech.

Nevyčitám Novellu, že vyvíjel YaST po svém. Neumim odhadnout, kolik by migraci na jiné distribuce stálo času. Myslím, že teď stejně polemizujem naprázdno o něčem, co nikdy nenastane.

Chci ale podotyknout, že Novell je sice "zisková organizace", ale mohli by si šetřit založení openSUSE, kdyby z komunity nic neměli - code patches, test x tisicemi lidmi, jako každá firma, kdo se vydá na tuto cestu. Jestli by se Novell bránil unifikovaným nástrojem, je čistá spekulace. Ale o to tady ani nejde.

Co YaSTu samozřejmě chybí, je architektura klient-server a vzdálená konfigurace. V tom bude asi největší práce, není žádná vrstva mezi GUI a konfigurákem. Jako bezprostrední front-end je ok a neviděl jsem zatím nic lepšího.