Názory k článku
Stinné stránky CVS

http://subversion.tigris.org
http://www.backports.org/debian/dists/woody/subversion/

Když jsem se naposledy díval, konverzní program CVS -> SVN nějak nekonvertoval tagy. Už to funguje?

Přece nesvěřím svou práci nějaké betaverzi!!!

Uz to neni betaverze a za 14 dni tu mame 1.0 verzi, takze proc ne?

Kdyby tak to, co píšete, byl hlavní problém s velkými soubory... Zkusil jste někdy pracovat s CVS přes pomalou síť? I malé změny ve velkých nebo v hodně souborech jsou pěkná pruda... soubory o velikosti pár set MB by se do paměti třeba i vešly, ale commit by bylo to poslední, co bych ten den udělal ;-) (a kdokoli jiný)

velmi doporucuji:

cvs -z 9 ci -m "commit s kompresi"

(globalni option -z je mozne zadat ke kazdemu prikazu cvs)

hmm, neviem, neviem, ale pokial si spominam, tak prave nonexclusive lock je featureska do CVS dana zamerne

podla mojich skusenosti, vacsina "nedorozumeni" s CVS-kom spociva jednak v zlej architekture projektu a jednak v nespravnom pouzivani.

je pravda, ze existuju mozne featuresky, ktore mu chybaju (vacsinou su k dispozicii zaplaty tretej strany ...)

> hmm, neviem, neviem, ale pokial si spominam, tak
> prave nonexclusive lock je featureska do CVS dana
> zamerne

To jsem vyrozumel - CVS je proste zamerene uzce na textove soubory v hodne distribuovanem prostredi (vyvojari po celem svete). Pak jsou s exclusive locky problemy. Proto je tam nechteji dat. Ale kdyby tam byly, nikdo by prece nihoko nenutil je pouzivat...

> podla mojich skusenosti, vacsina "nedorozumeni" s
> CVS-kom spociva jednak v zlej architekture
> projektu a jednak v nespravnom pouzivani.

Prave proto jsem sestavil seznam (nekterych) veci, ke ketrym CVS neni vhodne :-)

:-)))

zeby zarodok noveho "CVS-Usage-FAQ" zameraneho na klasicke chyby a sposoby riesenia ich pricin?

- nepouzivajte .doc, alternativa docbook
- kazdy subor/adresar priradeny zodpovednemu cloveku, zasah niekym inym len v pripade zavaznych chyb (alebo zmene zodpovednosti ...)

a podobne ?

No, ono resenim techto problemu je vetsinou pouze "nepouzivejte CVS" :-|

a co chcete pouzivat ?

CVS je urcene na to, na co je urcene, je stabilne, funkcne (s muchami v architekture) ... ale tvrdim si povedat, ze 90% vsetkych chyb je chyba mimo CVS.

typicky priklad binarne subory ... *.gif, *.jpg ... to predsa ma na starosti grafik a nejaky programator mu to nema co menit.

*.doc, *.xsl ... to ma tvorit analytik a citat banda programatorov


vsetko ma svoje vyhody a svoje nevyhody. CVS pouzivam fuu, 9 rokov, doteraz neovladam vsetky moznosti ... a problemy som mal len ked som si neprecital dokumentaciu :-)))

> *.gif, *.jpg ... to predsa ma na starosti grafik a
> nejaky programator mu to nema co menit.

A co ma tedy pouzivat na synchronizaci a version control souboru ten grafik (respektive tym grafiku)?

Tento clanek (jen) ukazuje, na co je CVS urcene, respektive pro co se nehodi.

kdyz mate projekty pro win a linux , tak se bez binary option neobejdete pro ty win-soubory, nemluve o ikonkach, bitmapach atd.

Co je na vasem prispevku hodnotne, je to nevyslovene upozorneni na delbu prace - ale to jste na tomto serveru mimo.

Naopak na _hodne_ distribuovane prostredi se CVS moc nehodi. To, ze se na ne pouziva, je dusledek pouze toho, ze alternativy, ktere jsou na hodne distribuovane prostredi stavene (to znamena zejmena "vzdalene vetveni", tzn. si naklonuju repository, u sebe si delam co chci, a vysledek pak natlacim zpet do centralniho repository), jeste nejsou dostatecne zrale (tla) ci jsou problemy s jejich pouzivanim u opensource projektu (bitkeeper).

>....u sebe si delam co chci, a vysledek pak natlacim
>zpet do centralniho repository), jeste nejsou dostatecne zrale (tla)
Tak s tim, ze tla neni dostatecne zraly pro pouziti produkcnim programovani, bych hrube nesouhlasil.
Jedinou vyjimkou je pripad, kdy vyvijite i ve Windows, protoze 100% funkcni cygwin nebo native port tla zatim neni k dispozici.

> ci jsou problemy s jejich pouzivanim u opensource
>projektu (bitkeeper).
Tak s tim se souhlasit naopak da velmi dobre.

Nejake zkusenosti s prechodem na gnuarch?

http://wiki.gnuarch.org/

Dobré. Nejvíce práce dá opustit schémata zažitá z CVS, Arch pracuje úplně jinak. Jakmile si na něj člověk zvykne, zjistí, že CVS je z dnešního hlediska v několika směrech mimo mísu. Práce s Arch je jednodušší a mnohem logičtější, CVS mi vůbec nechybí. CVS není zase tak špatné, jak by se z komentářů zde mohlo zdát, svého času znamenalo velmi významný pokrok proti RCS, jen vývoj opět pokročil a CVS se už také stalo překonaným nástrojem.

No já jsem s cvs ani nezačínal a šel rovnou do GNUarch. csv i svn jsou orientované na snapshoty, kdežto arch spíš na změny, takže umožňuje více diverzifikovaný vývoj (možná až moc :-). Je to dost odlišné. Trochu je na štíru s obsazeným prostorem v pracovní verzi, ale je hezky nenáročný na síť při commitu i checkoutu. No a taky jsou nějaké problémy na neunixlike systémech. Inu chce to pořádný OS s kontrolou velikosti písmen, lomítky v tom správném směru, symlinky atd.

Skvele. Pouzival jsem CVS na projekt, protoze to jinak "neslo". Pak jsem objevil tla/gnu-arch a okamzite jsem ho zacal pouzivat na tuny veci, protoze narozdil od CVS to JDE. Napriklad se chystam pouzit tla k zalohovani. Evidentne mi vyhovuje mnohem vic. Skoda ze ostatni to odmitaji uznat a pokracuji ve vyvoji na CVS ... no co. tla replay. cvs commit. cvs update. tla make-log. tla commit ....

V CVS by me ani nenapadlo mit vic branchu. V tla to je naprosto prirozene ...

Ja se taky primlouvam za SVN. Uz kdybychom se bavili jen o te autentizaci a vubec sprave uzivatelu tak reseni SVN se mi libi mnohem vice. Jednodussi pouzivani a mnohem pochopitelnejsi vystup 'svn log' uz to cele jen potvrzuje. (BTW. popis RPM od svn je docela dostatecne vystizny)

Ukladani binarnich souboru do CVS je IMO ponekud kontroverzni (ackoliv jej (zatim) take timto zpusobem pouzivam :-), preci jen ty funkce CVS jsou cileny na soubory se zdrojaky, pripadne dokumentaci v necem jako je TXT nebo HTML ci XML. Bylo by asi lepsi vyresit repository binarnich souboru nejak jinak (napr. nove vznikajici buildovaci system MAVEN ( http://maven.apache.org/ ) pouziva pro binarni soubory repository zalozene na obycejnem FTP). Tim bychom se ovsem museli vzdat vyhody jednoho uloziste.

Jinak vrele soulasim s tim, ze menit strom projektu v CVS je na zblazneni. Malokomu se pritom podari vymyslet strukturu adresaru projektu napoprve tak, aby v pozdejsi dobe nebyly nutne zadne zmeny.

no ano, ale napr. create scripty databazy + data pre testovanie maju radovo 50MB v textaku, ked to zipnes tak to ma 8MB. Otazne je ci je lepsie vovalit tam VELKY textovy subor ktory to vie diffovat, alebo MENSI binarny subor, ktory sa nediffuje. pri desiatej verzii databazy tam mas potom 10x8MB binarku alebo 9x relativne kratky diff + 1x 50MB textak. ma s tym niekto skusenosti?
p.s.: este dodavam ze je tu RYCHLA siet, takze nie je velky rozdiel ci pride 8 alebo 50MB zo servera.

Testovaci data nemaj v source control co delat. V kazdym pripade pouzivat zkomprimovany zdroje je naprosto sileny, prave proto ze pak ztracis prehled o zmenach.

Co se tyce binarnich souboru - tak prave jde spis o UI grafiku, prestoze ji nedela programator tak je nedilnou soucasti projektu ktera by mela bejt pohromade se zdrojakama a verzovana, jako kazdej jinej zdroj. Nemluve o tom ze takovy Java zdrojaky v Unicode (i kdyz v UTF-8) uz moc textovy nejsou, o vicejazykovych textech uz vubec nemluve.

a kam doporucujes davat testovacie data ktore su verzionovane podla verzie aplikacie? neide tam ani tak o diff medzi nimi, skor o jednotne repository na testovany soft + data potrebne k behu testov...

Kez by alespon pro mne bylo v clanku jmenovane vse v cem CVS kulha. Co treba nejaka smysluplmna sprava uzivatelu (maintaineru). Moznost definovani adminu pro jednotlive adresare a nejake odstupnovani jejich hierarchie apod. Proste tak aby to umoznovalo elegantni praci ve skupine vyvojaru nejen tim, ze to udela merge. Super by byla i moznost nejakych reportu ohledne aktivity a zmen jednotlivych lidi a branchu/adresaru projektu apod.

Možnost sledování aktivity je. Stačí si přečíst dokumentaci ;-)

> Kez by alespon pro mne bylo v clanku jmenovane
> vse v cem CVS kulha.

Prostor je omezeny :-) Jinak ale souhlasim, ze o problemech administrace jsem se zminit mohl, v tom take CVS zrovna neexceluje.

>Moznost definovani adminu pro jednotlive adresare >a nejake odstupnovani jejich hierarchie apod.

A proc? Zbytecne zdrzovani, pokud udelas neco co nemas, CVS te za to stejne "nabonzuje" :)

Hm, ja si alespon pod timto predstavuji, ze urciti uzivatele budou moci pouze k nekterym modulum, pripadne nekteri admini budou moci pridelovat pristup pouze do nekterych modulu. A to bez toho, ze by na tom pocitaci msueli mit shellove pristupy.

(Mimochodem - pokud mam do repository write access, jsem schopen stopy, ktere zanecham zase vymazat nebo dokonce zfalsovat...)

Predstavuji si pripad z praxe, potrebuju nutne opravit bug, kod ale delal nekdo jiny, ktery je treba nemocny. Uz to, ze musim sehnat nekoho, kdo mi nastavi prava a cekat na jeho reakci je unavne.
Stejny pristup ma i bugzilla, pokud mam napr. pravo editovat bugy, tak mam pravo editovat vsechny. Zmeny se loguji a je hned videt, kdo to zvoral:)

>(Mimochodem - pokud mam do repository write >access, jsem schopen stopy, ktere zanecham zase >vymazat nebo dokonce zfalsovat...)
jestli to jde, tak je to fakt blby..

Hm, koukam, ze vnimate bezpecnost pouze jako neco, co vas brzdi v praci :-)

Jde o to, ze konkretni situace se silne lisi. Jsou tymy, kde je naopak dobre, ze musite sehnat nekoho, kdo vam tu editaci povoli. A pokud se CVS pouziva uvnitr firmy, tak to ani s tou reakci neni tak spatne, staci se treba otocit k jinemu stolu :-)

Bohuzel, CVS mi nedovoluje rozhodnout se, jaky bezpecnostni model je pro moji situaci vhodnejsi a ma jen jeden (ktery je vhodny pro distribuovanou praci).

Ad zahlazeni stop: Pokud mate write pristup, mate shell (obecne tedy plnou kontrolu nad pocitacem v ramci daneho uzivatele) a muzete tedy menit RCS soubory i log CVS.

na write access nemusite mat shellaccess. staci pouzivat :pserver: (popr s tunelom cez stunnel ... toto v CVS chyba)

a ak cvs daemon bezi od uzivatelom, ku ktoremu ma pristup iba root, aky problem ?

co sa tyka bezpecnosti ... predpokladam, ze pouzivate revision (project-stable, project-snapshot-2004-09-02, ...) plus pravidelne zalohovanie ... bezpecnost zachovania zdrojakov je i pri full access blizka 100%.

ad priklad z praxe ... pracoval som raz na projekte (pod windoze, ble), kde version system pouzival excluzivne locky, zodpovedny clovek nebol zastihnutelny, mal subor locknuty, windows s neznamym heslom ... a kriticky bug v aplikacii ...

jedine co sa tu bavime je flame-war o tom co sa mi paci a co nie. v konecnom dosledku ziaden version system nie je vhodny na vasu pracu, pretoze vzdy narazite na obmedzenia.

otazka ... zo nam brani aspon zacat pisat specifikaciu (ci wish-list?) pre projekt?

otazka ii ... je niekto schopny a ochotny poskytnut priestor pre zberanie roznych wish-listov, myslienok a podobne? (resp, existuje take daco?)

> na write access nemusite mat shellaccess. staci
> pouzivat :pserver:

Prectete si clanek jeste jednou a poradne, zvlaste kapitolu "Write access znamena shell".

> co sa tyka bezpecnosti ...

Tak mi predevsi mi vadi, ze clovek muze delat zmeny do projektu, ve kterem nema co pohledavat. A ne kazda zmena se musi projevit hned.

ad priklad: To je priklad blbeho managementu (spatna zastupitelnost), ne blbeho VC systemu.

Ale ja nepisu, ze se mi CVS nelibi. Ja jen pisu, jake ma omezeni. Treba se SourceSafe nejsou skoro zadne problemy - az na to, ze je na nasem mnozstvi souboru v repository (desitky tisic) silene pomaly.

A ohledne navrhu - mam napsanou kompletni specifikaci vyhovujiciho systemu :-) Neresi version control, ale resi distribuovanou modifikaci souboru (vpodstate se na nej zjednodusene da koukat jako na FTP s moznosti zamykani souboru).

hmm ... co keby ste sa s tou specifikaciou pochvalil ? :-)))

btw, zamykanie suborov je podla mna blbost.
a prava k projektom ... nepostacuje vam to, ze zodpovedny admin (ten predsa musi byt vzdy) bude priradovat k projektom ludi na zaklade user-group?

> hmm ... co keby ste sa s tou specifikaciou
> pochvalil ? :-)))

Asi myslite pochlubil... Psal jsem ji jako material pro mozne reseni uvnitr firmy v pracovni dobe za firemni penize, takze minimalne zatim ne :-( Pokud o to nebude zajem, tak to mozna zverejnim.

> btw, zamykanie suborov je podla mna blbost

Hm, vy jste ten clanek vazne moc dobre necetl... Zamykani souboru vidim jako nejjednodussi moznost, jak vyresit, aby si lidi vzajemne nemenili soubory, ktere se nedaji mergovat. Jestli vite lepsi zpusob, jak to zajistit, tak sem s nim. (Zpusoby "nejak se domluvi" a "musi davat bacha" nepocitam :-)

> bude priradovat k projektom ludi na zaklade user-group?

To je reseni (a pisu to i na jinem miste), ale implikuje to mit pro kazdeho uzivatele ucet na danem stroji a to neni vzdy zadouci :-|

ano to implikuje.

podla mna nie je dolezite, kto ma pristup k danemu projektu (presnejsie ... ak niekto pracuje na nejakom projekte, tak by ho mal vidiet cely a potom nie je dovod, preco by nemal mat pravo ho cely aj editovat). version control system je to, ze vzdy existuje cesta spat. a to je dovod, preco existuju.

cvs rozhodne nie je urcene ako databaza mp3-jok ci obrazkov.

a takisto by CVS repository nemalo ukladat kazdy shapshot suboru (zmazem riadok - commit - blbost, vratim spat, zmazem iny - commit ...).

typicka blbost je napr pouzivat CVS ako transportny system smerom od developera na testovaci server a tam zistovat syntakticke chyby.

a este jedna poznamka: to ze existuje ucet z nazvom xyz, prihlasovacim menom xxyyzz este neznamena, ze
a) existuje uzivatel daneho mena
b) ten uzivatel ma shell access

> podla mna nie je dolezite, kto ma pristup k danemu
> projektu

Prilis generalizujete. Jsou projekty, kde je to pravda. Jsou projekty, kde to pravda neni a kde by se podobne omezeni naopak hodilo.

> cvs rozhodne nie je urcene ako databaza
> mp3-jok ci obrazkov.

Ale pokud jsou ony mp3ky a obrazky integralni soucasti projektu (napriklad pocitacova hra), tak je velmi logicke, aby v tom CVS repository byly take. A cvs by to _mohlo_ umet.

> a takisto by CVS repository nemalo ukladat
> kazdy shapshot suboru

Souhlasim, o tom jsem nemluvil.

> a) existuje uzivatel daneho mena

Souhlasim, ale nevidim, v cem mi to pomuze.

> b) ten uzivatel ma shell access

Opravdu byste si mel precist ten clanek alespon zbezne. Pokud ma uzivatel write do repository, muze pomoci CVS ziskat shell access.

To je blbost. Od urcite velikosti projektu nema sanci nikdo vedet a rozumet vsemu. Nemluve o projektech kde se setkavaji naprosto ruzne technologie a lide kteri praci ostatnich nerozumeneji. U rady projektu jsou lide kteri se staraji o velmi male mnozstvi kodu (treba nejaky driver) a je vhodne je nicemu dalsimu nepoustet protoze nikdo o tom cloveku nevi nic jineho nez ze napsat par radek a urcite je silenost nekoho takoveho poustet ke vsemu. Nebo by se vam libilo pokud nekdo kdo napise sto radkovej driver k nejakemu HW mohl modifikovat treba memory managment celeho systemu. Resit to tim, ze nad vsim bude nejaky "policaj" ktery bude kazdy den prolezat logy a sledovat zmeny mi nepripada jako reseni.

To, ze potrebujete rychle opravit neco a nemate k tomu pristup je ciste organizacni zalezitost. Klidne muzete mit dve vetve a takovedle veci delat v stable branchu kde dochazi k minimalnim a snadno identifikovatelnym zmenam a kde bude mit pristup ke vsemu nekolik malo lec dobre overenych lidi.

Uplne super by byl system kde by se dala nastavit cesta schvalovani patche - tedy kdo vsechno ho musi v kontextu toho co meni prohlednout nez bude zarazen.

A jeste vic super by byla moznost pokud by primo sprava verzi a kodu umela i nejake planovani a propojovani patchu a TODO (bez berlicek a desitek nastaveb).

K tem statistikam. Mel jsem na mysli neco co by umoznovalo sledovat kolik casu na cem bylo straveno a kym. Tak aby se dala stanovit nejaka narocnost a pripadne hodnota veci. Sledovani poctu radek neni uplne to same.

generovane statistiky z CVS
http://statcvs.sf.net/

To je další věc se kterou se CVS nekamarádí.

To je sice skoda, ale davat mezery do nazvu souboru je stejne "nepekne" :o)

Nahodou, treba do jmen souboru s ruznymi multimedii (autor - nazev.(mp3|avi|ogg|...)) zasadne mezery davam, protoze to jinak vypada hnusne ;-). Ale je pravda, ze do CVS bych neco takoveho asi necommitnul :-).

Nejsem si uplne jist tvrzenim, ze CVS ignoruje ruzne konce radku. Zrovna o vikendu jsem prisel na to, ze jeden soubor v CVS mam s DOSovskymi konci radku, tak jsem je prekonvertoval a CVS to zaznamenal. Kdyz jsem delal patch tak v nem byl cely soubor out s jednim typem koncu radek a cely soubor in s druhym :)
Mozna se to lisi podle verze, nebo podle OS.

Tak, tak, CVS konce řádků rozhodně neignoruje. Jestli se nepletu, tak je může ignorovat diff při parametru -b (nebo -B), ale určitě ta změna jde commitnout.

CVS je dosti spatny nastroj s mnozstvim chyb, nejvice mi vadi nemoznost rename a pridavani souboru, ktere sly predtim do atticu. Zasahem do repository to vetsinou jde vyresit. CVS bohuzel pouzivam moc dlouho a jsem linej se naucit neco noveho. :(

Tak jestli tohle jsou jedine stinne stranky CVS tak to je pohoda.:-)

Neboj nejsou.

Clanek se mi libi i diskuska pod nim. Jelikoz jsem "zelenac" v tedle oblasti neslo by to jeste nejak rozvest? Jak je to s uzivatelskym prostredim, resp. existuje nejake GUI rozhrani? Existuje i pro ty ostatni zminovane verzovaci systemy? Co napojeni na nejake ty editory jako je emacs apod.? Nebo si to musim dodelat sam:(

Xemacs ... menu tools, polozka VC
hotkeys C-x v v (a ostatne nepouzivam)

GUI
- windoze: wincvs (wincvs.org)
- linux ... spomeniem si na projekt cervisia, nedavno som zhliadol na freshmeate

Dobre GUI ma CVSNT, ale to je jen pod Windows.

CVSNT was started as a conversion of cvs pserver for NT. It has since been greatly improved and is now available under Windows and Unix/Linux.
( http://www.cvsnt.org )

Pardon, vyjadril jsem se nepresne. Gui se nejmenuje CVSNT, ale WinCVS. To GUI CVSNT pouziva a distribuuje se s nim. A (to GUI) je pouze pod Win.

CVS je standard. Bohuzel refactoring s nim je tragedie, jak uz bylo zmineno. I s WinCVS clovek musi byt dost opatrny, aby udelal to, co chce (bezny commit/update). Klient Tortoise (www.tortoisecvs.org) vypada stravitelneji i pro novacka v CVS.

Varianta WinCvs je k dispozici i pro Linux: http://www.wincvs.org/shots.html#GCVS

Celkem pouzitelny GUI klient v Jave:
http://www.jcvs.org

Nebo pro Windoze, ktery se zahakuje primo do "shellu":
http://www.tortoisecvs.org

Nechtel by nahodou nekdo napsat "virtualni" pokracovani serialu o CVS (podobne jako tento clanek) o nejakem GUI pro CVS? Stacil by treba nejaky rozumny prehled ruznych alternativ se strucnym popisem. Ja v teto oblasti bohuzel nemam naprosto zadne zkusenosti, takze bych pro to asi nebyl prilis kvalifikovany, ovsem myslim, ze by to bylo celkem dobre doplneni serialu (asi nekdy ke konci CVS, coz je tak odhadem ctyri/pet tydnu|dilu pred nami ;). Pokud byste meli zajem, smerujte maily na pasky@ucw.cz a johanka@ucw.cz ;-) (pokud mozno prosim oboum z nas).

Dovolil bych si polemizovat s doporucenou metodou prejmenovani/presunu souboru. Skutecne je to nejrozumnejsi primo zasahem do repository, ovsem dosti bych varoval pred presouvanim souboru, spise bych doporucil _zkopirovani_ souboru na novou lokaci, a pak v checkoutovanem stromu serii:

cvs up

cvs remove stary/soubor

cvs ci -m"stary/soubor -> novy/soubor" -f stary/soubor novy/soubor

Tento pristup ma nekolik zasadnich vyhod - mame v historii zaznam o presunu souboru, nemame problem s ruznymi vetvemi (v jedne je soubor tam, v druhe onde), a nemame ani problem s "cestami do historie" (vyskytoval se ten bug jeste pred mesicem? oops, ono to nejde zkompilovat, chybi tomu nejaky soubor... aha, on je jinde, zatr...).

Jedina nevyhoda je, ze v onech cestach historie a jinych vetvich mame onen soubor dvakrat (stary/soubor i novy/soubor), ovsem to je myslim lepsi, nez nemit tam ten soubor vubec ;-).

Omlouvam se, ze dnes "vynechal" vylet do rise verzi. Puvodne jsme tenhle clanek planovali az na konec casti o CVS (kam by take nejprirozeneji zapadl), ovsem bohuzel diky me nesikovnosti musel byt zarazen uz dnes. Delal jsem si trochu poradek v ~/txt/root, a najednou jsem mel dva osme dily, a zadny devaty. Sice jsem ho pres nedeli narychlo napsal, ovsem poslal jsem ho uz moc pozde, takze se ho dockate priste (to se ale tesite, vidte? ;).

Zdravim,
Kdyz uz takhle na CVS "nadavate", poradili byste jakou alternativu k CVS zvolit pro cca 6 vyvojaru software pod win (tedy win klient) se skladistem zdrojaku (vcetne bin) na linuxu? Zatim pouzivame CVS ale jestli je neco lepsiho, uzivatelsky prijemejsiho s win klientem tak bych se nezlobil... :-) Diky ph

Seznam alternativnich SCM, popis klicovych vlastnosti a prehledne porovnani je na
http://better-scm.berlios.de/.