Vlákno názorů k článku Microsoft otevírá PowerShell a vydává ho pro Linux od čumil - A teď ještě registry pěkně prosím smutně koukám,...
-
Registry jsou, tak to už u Microsoftu často bývá, docela dobrý nápad se strašně zmršenou implementací. Pro uživatelské aplikace už máme dconf, který, ač není bez chyby, má většinu výhod registrů bez většiny jejich problémů. Kdyby systemd zavedl, tedy ano, v podstatě vnutil, trochu koherence a pořádku do té odporné slátaniny zvané /etc, tak co by ne.
-
Ted je otazka, jestli registry lze udelat jinak, nez tak, ze je konfigurace jedne veci rozptylena po tisici ruznych klicich a ruznych mistech registry, bez komentaru, bez moznosti zjistit, ktere klice uz nicemu nepatri a dalsimi lahudkami. Dekuji, ale davam prednost te odporne slatanine v /etc a doufam, ze ani Poettering nedostane napad vylepsit Linux o registry.
-
To je právě jeden z důvodů, proč tvrdím, že implementace registrů ve Windows je katastrofa, což ovšem neznamená, že je nutně špatná i samotná idea.
Představme si, že místo desítek souborů v /etc, bez ladu a skladu a každý samozřejmě s jinou, čistě arbitrární syntaxí, by důsledně platilo pravidlo, že každá položka obsahuje právě jednu jedinou informaci. Prostě tak, jako máme /etc/hostname, by bylo i např. /etc/passwd/honza/uid, obsahující jedinou hodnotu typu integer.
Adresář /etc by byl namontován na speciálním FS typu klíč-hodnota, který by vynucoval správné typování a zároveň by zaručil, že jakékoliv změny proběhnou atomicky. Jednotlivé "registry" by pak mohly podléhat normálním přístupovým právům, čímž by odpadla nutnost mít setuid a sudo. Výborný princip, že "všechno je soubor" by se tak posílil, aplikace i admin nástroje by byly mnohem jednodušší a spolehlivější a jakékoli nastavení čehokoliv by se dalo snadno provádět programově.
Kdyby tohle někdo prosadil, tak mu bude patřit všechna čest.
-
mhi (neregistrovaný)
Problem registru je zejmena v tom, ze spousta aplikaci vyzaduje ulozit specificka konfiguracni data a to se potom nejak roubuje na registry, vznikaji "foreign klice" (treba GUID), ruzne se to matla, etc. Nevidim taky zadny prakticky duvod k centralnimu ulozisti konfigurace (samozrejme, jednotlive konfiguracni soubory by mely byt nekde smysluplne ulozene, treba v tom /etc ). Rychlost take neni argumentem, jednotlive soubory se bud' daji cachovat nebo staci nepsat prasacke aplikace.
Daleko lepsi zpusob se mi jevi Applovsky .plist, ten se alespon da snadno rucne editovat a zadnymi velkymi nevyhodami netrpi (opet-je to ale vynuceni urciteho formatu, kteremu se podrizuji aplikace). Kdyby se doplnil o nejake vazby mezi soubory, tak to ma i moznost automatizovane s tim pracovat.
-
Prostě tak, jako máme /etc/hostname, by bylo i např. /etc/passwd/honza/uid, obsahující jedinou hodnotu typu integer.
Uzasne. Takze /etc by primo editovat neslo, protoze by se z toho clovek posral. Byl by tam milion adresaru, podadresaru a klicu. Pristup by se zpomalil, protoze by bylo nutne prohledavat slozitu adresarovou strukturu.
Adresář /etc by byl namontován na speciálním FS typu klíč-hodnota, který by vynucoval správné typování a zároveň by zaručil, že jakékoliv změny proběhnou atomicky.
Takze namisto parsovani souboru aplikaci ziskame parsovani milionu malych souboru pomoci virtualniho FS. To bude urcite rychlejsi. Dalsi hezka vec je, ze na kazde a=5 se spotrebuje jeden alokacni blok, takze budeme mit "registry" jeste vetsi, nez ma MS registry.
Otazka je, co tim ziskame. V Linuxu parsuje konfigurak typicky jenom aplikace, ktere patri a to typicky jen pri startu, obcas nektera kdyz dostane SIGUSR (ve Widlich tomu tak neni, tam Widle i aplikace porad dokola ctou a casto i zapisuji klice - oni to asi pouzivaji misto /tmp).
Tak kvuli tomu se takova harafika urcite vyplati. Zejmena, kdyz tim ziskame dalsi uroven nekompatibility s ruznymi *NIXy. Tedy uz nejen systemd bude komplikovat portaci softu, ale i "registry". Ne, dekuji, ale o napodobeniny MS techologii opravdu nestojim.
-
Jenda (neregistrovaný)
> Dalsi hezka vec je, ze na kazde a=5 se spotrebuje jeden alokacni blok
To není pravda, psal, že se použije speciální FS. Můžeš si to představit jako kdyby někdo napsal FUSE nad sqlite. Tam se taky pro každou hodnotu nespotřebuje celý blok.
Stejně si ale myslím, že tím nic nezískáme. A navíc tím rozbiješ třeba možnost mít /etc v gitu.
-
@Jenda: Precti si jeste jednou, co napsal: Představme si, že místo desítek souborů v /etc, bez ladu a skladu a každý samozřejmě s jinou, čistě arbitrární syntaxí, by důsledně platilo pravidlo, že každá položka obsahuje právě jednu jedinou informaci. Prostě tak, jako máme /etc/hostname, by bylo i např. /etc/passwd/honza/uid, obsahující jedinou hodnotu typu integer.
Co s tim pak udela nejaky virtualni system, ktery nad tim pobezi, je totalne nezajimave.
-
@Jenda: A ten specialni FS, potvora, bude take mit alokacni jednotku. Pricemz ten specialni FS bude pouzit jen tehdy, pokud se uzivateli bude chtit pri instalaci opruzovat s tvorbou extra oddilu se specialnim FS jen kvuli par desitkam KB v /etc. Take by ten specialni FS mohl byt vytvoen v souboru, prislusne naformatvanem a namotovanem na /etc. Takze budeme mit vlastne jede velky konfigurak, ktery bude skoro jako registry. Bravo, v Redmondu by z vas meli radost.
-
Uzasne. Takze /etc by primo editovat neslo, protoze by se z toho clovek posral. Byl by tam milion adresaru, podadresaru a klicu. Pristup by se zpomalil, protoze by bylo nutne prohledavat slozitu adresarovou strukturu.
Proč by nešlo?
echo "true" > /etc/network/enp1s0/ipv6/slaac/auto
S klávesou TAB by to bylo mnohem jednodušší, než editovat nějaký dlouhý román a hledat v něm, kdeže to vlastně je. A nevím, proč by to mělo být pomalejší, než např. přístup do /usr/local/lib/python2.7/site-packages. Jestli je v Linuxu něco vyřešené opravdu dobře, tak je to directory traversal.Takze namisto parsovani souboru aplikaci ziskame parsovani milionu malych souboru pomoci virtualniho FS. To bude urcite rychlejsi. Dalsi hezka vec je, ze na kazde a=5 se spotrebuje jeden alokacni blok, takze budeme mit "registry" jeste vetsi, nez ma MS registry.
Zaprvé by se nespotřeboval, pokud FS umí tail packing. Zadruhé spousta jiných věcí žere alokační bloky jak zjednané a nikomu to nevadí. Podívej se například na alokační algoritmus v ZFS a garantuju ti, že ne nebudeš stačit divit. Zatřetí jsem říkal, že by na to měl být zvláštní FS kvůli typové kontrole a atomičnosti, takže nic nebrání tomu, aby jako úložiště používal nějaký kompaktní formát. No a začtvrté je to v době mnohoterabytových disků úplně jedno.
Otazka je, co tim ziskame. V Linuxu parsuje konfigurak typicky jenom aplikace, ktere patri a to typicky jen pri startu,Získáme tím to, že aplikace nebude muset "parsovat" vůbec, pouhý read() poskytne okamžitě hledanou hodnotu. Dneska ano, každá aplikace musí obsahovat parser, v 50% případů je to moloch vyblitý yaccem, v dalších 49% zprasený ručně s obligátními buffer overflow a memory leak a to všechno běží jak jinak, než pod rootem.
A pochopitelně jenom při startu, protože za běhu... už jenom, co by se stalo, když by se při dynamické rekonfiguraci objevil parse error, he?
Tak kvuli tomu se takova harafika urcite vyplati.
Asi vyplatí, protože přesně takovou harafiku používáme každý den už léta: /sys. Celá konfigurace kernelu už dávno funguje výhradně na tomhle principu a neslyšel jsem, že by si na to někdo stěžoval. Jediný rozdíl je v tom, že zatímco /sys je čistě virtuální FS bez perzistence, pro systémové služby a nastavení by perzistence byla nutná, takže nějaký diskový back-end by byl potřeba. Toť vše.
Zejmena, kdyz tim ziskame dalsi uroven nekompatibility s ruznymi *NIXy. Tedy uz nejen systemd bude komplikovat portaci softu, ale i "registry". Ne, dekuji, ale o napodobeniny MS techologii opravdu nestojim.
Neboli učebnicový příklad Baby Duck syndromu ;-)
Předpokládám, že logicky nestojíš takové napodobeniny MS technologií, jako je podpora ACPI nebo power management?
-
Proč by nešlo?
echo "true" > /etc/network/enp1s0/ipv6/slaac/auto
Fantasticky napad. Takze zatimco dnes si otevru jeden soubor, kde mam vsechna nastaveni prehledne i s komentari, v buoucnu budu editovat bordel, kde bude jedna polozka na soubor a bez komntare (ten bude eventuelne v dalsim souboru a cely konfigurak neuvidim nikde. A az budu hledat, co mam blbe, ze to nechodi, tak si to budu soubor po souboru vypisovat na kus papiru a v manu hledat, co je co.
Získáme tím to, že aplikace nebude muset "parsovat" vůbec, pouhý read() poskytne okamžitě hledanou hodnotu. Dneska ano, každá aplikace musí obsahovat parser, v 50% případů je to moloch vyblitý yaccem, v dalších 49% zprasený ručně s obligátními buffer overflow a memory leak a to všechno běží jak jinak, než pod rootem.
Tak nevim, proc by parser mel jet pod rootem, kdyz je to jen na cteni. A jinak brani neco tomu, aby spise byl sjedncen frmat konfiguraku a parser byl obsazen primo v systemu, k dispozici vsem aplikacim? Dokud totiz konfiguraci dela rucne clovek, je textovy konfigurak lepsi. Nebo budeme mit povinne v kazdem systemu GUI a ke kazde aplikaci klikatko?
Asi vyplatí, protože přesně takovou harafiku používáme každý den už léta: /sys.
/sys je zalezitost jadra, ne aplikaci. Existence ci absence /sys nebrani portaci aplikaci. Byly doby, kdy na Linuxu zadny /sys nebyl.
Předpokládám, že logicky nestojíš takové napodobeniny MS technologií, jako je podpora ACPI nebo power management?
Jak na APM, tak na ACPI se MS pouze podilel. Na ACPI se asi podilel hodne, je to videt na tom, jaky je to bordel a jak to a spouste stroju nefunguje. Ke vzniku veci, jako ACPI, MS vubec neni potreba. Ucast MS je naopak nezadouci, protoze tim vznikaji veci, jako Secure Boot v UEFI, ktery na ARMu dokonce ani nesmi jit vypnout.
-
ebik (neregistrovaný)
Hmm, a ted treba konfiguraci apache, vcetne virtualnich serveru, rewritu, atd...
A propos, zrovna ta sitova konfigurace - kdyz si tam clovek nepusti networkmanager (coz jde posledni dobou docela spatne), tak to maji distribuce vytvorene docela pekne. Ja na debianu pouzivam /etc/network/interfaces (nebo /etc/network/interfaces.d/*), a musim rict, ze se v tom vyznam vyrazne lepe, a funguje to 100%. Network manager je notoricky znamy problemy s 802.11X na wired interfacech. Kdyz nejaky problem vyresi tak o par verzi dal zavedou jiny.
Vetsina radku (tedy hodnot v tom vasem konfiguracnim FS) je stejne textovych, ale presto do nich nemuzete napsat cokoli. Takze vase syntakticka kontrola je zde na nic. Konfigurace se musi vzdy otestovat a rozumne programy na to maji rezim, kterym konfiguraci otestuji, a reknou jestli je formalne v poradku. (Napriklad pokud pouzivate volby pro nejaky modul, tak ze ten modul mate uvedeny v seznamu modulu, ktere se maji pouzit.)
Nejlepsim prikladem flexibility textovych souboru je pak konfigurace varnishe. Tomu date v podstate "program" v jazyce vcl (to je jeho vlastni jazyk), ktery se pri nacteni zkompiluje. Ostatne i muj windowmanager se konfiguruje programovacim jazykem (Lua), a mnohokrat jsem to jiz ocenil (mohl jsem si napsat kratky kousek kodu, ktery napravil chovani spatne aplikace, windowmanager mi ho pak spusti na definovane udalosti).
-
Sto let to funguje, vsichni jsou na to zvykli a hlavne to umeji, pak prijde nekdo s genialnim napadem, presvedci particku lidi ve vedeni a pak maji vsichni uzivatele polofunkcni vec, a nikdo to navic neumi, procez se musi ucit nejlepe novy jazyk.
Nejak by me neudivilo, kdyby lidi ve vedeni distribuci mely na notesech windowsy, vlastne by to mnohe vysvetlovalo.... -
Proboha ne! Už to tu sice pár lidí uvedlo, ale aby to nezapadlo v Jardově absurdním šumu:
Problém je v tom "FS typu klíč-hodnota"!!
Tento kocept totiž sám od sebe naprosto nedostačuje!
Opravdu jednoduché aplikace si s tím ještě vystačí, ale už tam dost vadí absence komentářů.
Cokoliv složitějšího už požaduje nějaké složitější datové struktury (hlavně hierarchické) a to se do KEY-VALUE už pasuje hodně, hodně špatně - viz právě ten bordel ve Windows Registry.A to ani nemluvě o případech kdy "konfigurák" je přímo v nějakém programovacím jazyku (např. ten varnish, jak tu někdo uváděl).
