Názory k článku
CERN končí s Red Hatem a přechází na Debian
-
Michal ŠmucrStříbrný podporovatelMrkněte na to video. Nemohli, protože mají u urychlovače asi půlku serverů a embedded systémů s proprietárním PCI hardwarem, co mají jen základní level x86-64 (v1). Na tom by jim nechodil ani speciální build Almy 10, která podobně jako poslední OpenSUSE nebo RHEL9 vyžaduje x86-64-v2.
Těch cca 2200 strojů, co tam mají, je jen ta část přímo řídící urychlovač.. a doteď tam používali Centos 7.
Ještě jsou tam vrstvy okolo, prac. stanice atp. tam už mají novější počítače, takže tam zůstávají víceméně pořád aktuální klony RHEL 9 a 10.Spíš přemýšlím, že mají opravdu velkou důvěru v ten hardware, který bude na konci plánovaných period (s protažením až do r. 2033) mít nejspíš u těch nejstarších kousků třeba 25 let. A trochu pochybuju, že by to v tomhle množství nezačalo být problematické.. i kdyby jich měli hromadu náhradních někde ve skladu.. ale kdo ví.
-
Spíš přemýšlím, že mají opravdu velkou důvěru v ten hardware, který bude na konci plánovaných period (s protažením až do r. 2033) mít nejspíš u těch nejstarších kousků třeba 25 let. A trochu pochybuju, že by to v tomhle množství nezačalo být problematické.. i kdyby jich měli hromadu náhradních někde ve skladu.. ale kdo ví.
Hardware dnes sa už tak nekazí, skôr zastaráva morálne. Ak majú dostatočnú zásobu komponentov na sklade, počítače im pôjdu. A so spotrebou asi tiež nemajú ťažkú hlavu, tam behajú lineárne urýchlovače, vyrábajú antihmotu a kadečo :) Že to veľa žere je tiež nepodstatné.
-
-
Už je to dávno co jsem se o CERN IT zajímal, ale pamatuju si, že ve velkém používají OpenStack (plus Puppet, atd):
* https://clouddocs.web.cern.ch/index.html
* https://clouddocs.web.cern.ch/bare_metal/index.html -
Tam je zajimava unifikace baremetal deploymentu pres Ironic. Ze nekdo nad tim premyslel hlavou a ne ze je mnoho nesourodych systemu na deployment jako v Typickem_Korporatu (Tm).
Tezko lze ale predpokladat migrace na hypervizory nekde na prijmu dat ze senzoru. Urcite jim nebude uplne sumafuk ultrapresne casovani nad kterym maji postaveny cely design a budou kvuli tomu taky budou rozebirat jeden z nejslozitejsich stroju na teto planete.3. 9. 2026, 08:51 editováno autorem komentáře
-
Jan HejzlBronzový podporovatelTím jsem spíš řečnicky myslel, že je velká pravděpodobnost, že jednak během oné doby stejně nějak budou výměnu toho HW muset vymyslet, jednak je dost pravděpodobné, že ani distribuce jako Debian už takové konfigurace stejně za pár let nebude podporovat. Celé to zní jako odkládání problému. Navíc je otázka, proč na prehistorických zařízeních takového typu vůbec potřebují neustálé aktualizace.
3. 9. 2026, 06:47 editováno autorem komentáře
-
Co ma asi tak spolecnyho to, ze nekdo pouziva zcela funkcni klidne 30+let stary HW ... a chce na nem udrzovat rozumne aktualni SW?
Treba (prekvapive ja vim) chce, aby to umelo neco jinyho nez ssl3 ze? Aby to treba umelo komunikovat s nejakym novejsim systemem ... divne.
A vymenovat ten HW specielne (ale zdaleka nejen) v tomto pripade zcela jiste nikdo nebude. Typicky by to totiz znamenalo vymenit uplne vsechno, Jiste jim ten uplne novy (a nejpozeji za tyden dostupny) urychlovac zapltis ... ze sveho.
Apropos, specilene v tomhle pripade je provozovani starych komponent primo ucel, jsou totiz radove odolnejsi proti ruznych chybam kterej vznikaji, kdyz na cip dopadne nejaka ta vysokoenergeticka castice.
-
Jan HejzlBronzový podporovatel
No jasné, to ano, jen to pořád obnáší tu ne docela malou pravděpodobnost, že přijde chvíle, kdy budou stát před tím stejným problémem, protože i Debian pak bude jinde. Nemyslel jsem tím, že tenhle krok nemá smysl. Jen mi to prostě přijde jako odklad.
-
Filip JirsákStříbrný podporovatelOdložit problém do doby, než se hardware stejně obmění a problém tím zmizí, je docela funkční strategie. Možná nepotřebují neustálé aktualizace, ale potřebují třeba opravy některých chyb. Nebo aktuální software. Navíc takové množství počítačů určitě bude připojené do sítě, asi nebudou přímo dostupné z internetu, ale nejspíš tam budou nějaké prostupy z nějaké méně zabezpečené sítě – takže i ty bezpečnostní aktualizace se hodí.
-
V čem byl "dosti nešťastný"?
Podle mě v tom, že se vydali pasivní, statickou cestou. Vyšli z formátu určeného pro sázení textů. Od té doby se neustále řeší, jak tento handicap obejít - přes různé flashe, JavaScript atp. Představte si, kdyby bývali vymysleli nějaký bajtkód a prohlížeč by byl virtuální mašina na provádění toho bajtkódu. Klasická statická stránka by byl primitivní program sestávající téměř výlučně ze samých volání nějakého formátovacího PRINTu. Ale byly by k dispozici i funkce vracející aktuální rozměry okna, fonty, jež jsou k dispozici, GUI prvky s kódem k reakci na ně atd. Parser toho bajtkódu by byl ve výsledku jednodušší než parser HTML, web by se dal vytvořit v čemkoli - naklikat v nějakém WYSIWYG nástroji, napsat v Pascalu, v C, v TCL nebo v čemkoli, co bude vymyšleno - výsledkem překladu by byl bajtkód pro prohlížeč. Z jeho pohledu by bylo jedno, zda pouze zobrazuje statickou stránku, nebo provádí program, interaguje s uživatelem atd. Nebylo by principiálně rozdílu mezi statickým webem a webovou aplikací.
HTML je v podstatě jen Gopher na steroidech, inspirovaný asi roffem nebo TeXem. Jasně, s odstupem času se to kecá, když jim šlo jen o snadné předávání vizuálně formátovaného hypertextu s obrázky. Ale myslím si, že v podobných momentech se vyplatí takové to cimrmanovské doporučení, že hrozí-li, že by se to mohlo stát významným, mělo by se k tomu přistupovat zodpovědněji.
-
"Vyšli z formátu určeného pro sázení textů. Od té doby se neustále řeší, jak tento handicap obejít - přes různé flashe, JavaScript atp. Představte si, kdyby bývali vymysleli nějaký bajtkód a prohlížeč by byl virtuální mašina na provádění toho bajtkódu."
Podle mne by měly být 2 cesty:
1) HTTP pro přenos formátovaného textu, který lze zobrazit i bez formátování v jakémkoliv textovém prohlížeči. Výhoda je třeba snadné přeformátování pro tisk nebo zkopírování do jiné aplikace (třeba tabulky s daty). To u něčeho vykresleného na csnvas už tak snadno nejde.2) nějaký vizualizační jazyk, umožňující práci s interaktivními prvky pro ovládání nějaké serverové služby. Něco jako jsou různá prostředí pro vizualizaci PLC.
Bajtkód, to už máte jako nějakou aplikaci, kterou si uživatel stáhne a spustí ve svém systému a která komunikuje se serverem. Kdysi byl takový hajp, že tohle bude Java (aplikace multiplatformní, spustitelné a zobrazitelné na čemkoliv). Pro zobrazování informací mi však tahle cesta připadá nevhodná. Pro šmírování a kontrolu co se komu zobrazí a co u toho dělá, je naopak vhodná ;-)
-
Ale napadlo vás, že oni v danou chvíli prostě jen řešili momentální problém, který měli a to je celé?
Vždyť jsem to na konci svého příspěvku snad napsal, ne? Jen narážím na to, že k řešení problémů se dá přistupovat různě. To, co říkáte, je naprosto správný přístup - řeš svůj konkrétní problém, neřeš hypotetické problémy jiných (1). Jenže s tím se pojí doporučení nevymýšlej si omezení, jež z podstaty řešeného problému přirozeně neplynou (2) a je-li řešený problém jen speciálním případem obecnějšího problému, jehož vyřešení tě nestojí žádnou námahu navíc, nebo je dokonce jednodušší, řeš tento obecnější problém (3).
Nemyslím si, že bych přišel na něco světoborného. Podobně kritizují koncept webu tak, jak se prosadil, i některé uznávané kapacity computer science - např. Alan Kay. Z mé strany to není snaha tvůrce webu nějak dehonestovat, spíš se jen postavit proti slepé glorifikaci toho, co vytvořili. Vytvořili něco, co vcelku uspokojivě řešilo jejich problém - nejde však o žádnou inspirativní ukázku mistrovské inženýrské práce, ale o nejvýše průměrný výkon, a bohužel se to začalo používat k řešení problémů, k nimž se to vůbec nehodí. Ten problém se dal tehdy zkrátka vyřešit mnohem lépe, snadněji a přitom univerzálněji. No - co už...
-
Filip JirsákStříbrný podporovatel
nejde však o žádnou inspirativní ukázku mistrovské inženýrské práce, ale o nejvýše průměrný výkon, a bohužel se to začalo používat k řešení problémů, k nimž se to vůbec nehodí.
Vy evidentně považujete za mistrovské inženýrské dílo něco, co je inženýrsky vymakané, používá to nejlepší finesy a nejnovější technologie – ale prakticky to klidně může být nepoužitelné. Já naopak považuji za mistrovské inženýrské dílo to, co se prakticky používá, a co se osvědčí tak, že se to dokonce začne používat i k věcem, ke kterým to původně vůbec nebylo zamýšleno.Ten problém se dal tehdy zkrátka vyřešit mnohem lépe, snadněji a přitom univerzálněji.
Myslím si, že snadněji to nešlo, aby to bylo ještě použitelné – resp. snazší byly předchůdci HTTP. A že to mohlo být technicky lépe a univerzálněji vyřešené? Ano, mohlo. Takhle byly vyřešené ty pokusy, které do dnešní doby nepřežily. Protože se ukázalo, že ta univerzálnost to komplikovala.To, že vyhrály neefektivní textové protokoly (a teprve v posledních letech se HTTP změnilo na binární formát), není historický omyl. To je proto, že se s nimi vývojářům lépe pracuje. To, že vyhrálo HTML jako značkovací formát, není historický omyl. Je to proto, že se s tím dá pracovat i bez speciálních nástrojů, bez webového prohlížeče. Že se vedle HTML prosadil Markdown a že se stal nativním jazykem AI, také není náhoda – je to pro člověka ještě čitelnější než HTML, a pro drtivou většinu věcí základní formátování Markdownu stačí. Přičemž je to bez problémů čitelné i pro lidi, kteří o žádném Markdownu nic neví.
Snadnost použití bez speciálních nástrojů je věc, která je pro samovolné rozšíření nové technologie nezbytná. Před nějakou technickou vyspělostí ta snadnost použití vždy vyhraje na celé čáře, pokud v zádech nemá nějaký tlak, který nahradí tu potřebu samovolného rozšíření.
-
Jak už jsem tu psal asi desetkrát: prakticky nikdy nevyhrává nejpokročilejší, nejfunkčnější a nejlépe navržené řešení. Skoro vždy vyhrává řešení, které je prostě dostatečné a dostatečně jednoduché v kontextu daného místa a doby a je ve správný čas na správném místě. To je celé. Nic víc v tom nemá smysl hledat. Zbytek je alternativní historie.
-
Nejsme ve při. Ale to ani nikomu nebrání konstatovat, že to řešení má k optimalitě daleko. Ve své praxi jsem už potkal tolik situací, kdy nějaké ad-hoc řešení ušité horkou jehlou, často zamýšlené jen jako provizorium, nakonec přežilo nečekaně dlouho a využívalo se k věcem, o nichž se při jejich zrodu ani náznakem neuvažovalo. Skoro se mi zdá, že je to až nějaká zákonitost. Takže i když budete mít za úkol vytvořit něco jen tak narychlo, "na prasáka", jen dočasně, vězte, že přesně tyto věci aspirují na mnohem vyšší mety, než si myslíte. :)
-
Filip JirsákStříbrný podporovatel
To je otázka, jak definujete optimalitu. V přírodě je za optimální považováno právě to, co se dál rozvíjí a přežije to dlouho.
-
Filip JirsákStříbrný podporovatel
Ale ono to bylo myšlené pro prezentaci textů, a dlouho to tak fungovalo. To, že pak někdo zjistil, že se to dá zneužít i pro dynamický obsah, je jiná věc. A svědčí to o dobrém návrhu, když se to dalo zneužít pro dost něco jiného, a ono to ustálo.
Kdyby tehdy vymýšleli nějaký bajtkód, bylo by to příliš složité a neujalo by se to. Respektive je docela pravděpodobné, že nějaké takové věci vznikly – ale neujaly se, proto o nich dnes nevíme. Ostatně už před internetem byla představa, že budou uživatelé pracovat s hloupými terminály, které budou vzdáleně připojené k serveru – to je trochu ten princip, který popisujete. Ale tehdy se to neujalo.
-
Já bych řekl, že naopak: HTTP/HTML je silně nadčasový, a i když vycházel z dobových omezení, funguje v podstatě dodnes - jen se často používá k věcem, na které není ani navržený, ani dimenzovaný.
Vždy mi vyloudí na tváři úsměv, když vidím, jak spolu komunikují dvě AI přes API, postavené nad HTTP a HRML, aby si v textové a
lidsky čitelné
podobě vyměňovaly data, která by v binární podobě a pod nějakým proprietálním protokolem mohla putovat rychleji a mnohem přesněji.3. 9. 2026, 18:39 editováno autorem komentáře
-
LHC čeká teď přestávka a přestavba na Hi Luminosity, pak pojedou do 2041 run4, pak kompletní přestavba na FCC (tam tuším ještě není schválený funding, ale možná se pletu).
Myslím, že to rozhodně "odkládání problému" není, naopak, klackem vyhánět ty, kdo by tam chtěl strkat latest greatest co nejdřív, to fakt není gamesovací stroj ;-)
a aktualizace potřebují m.j. i kvůli time(int32)
3. 9. 2026, 09:40 editováno autorem komentáře
-
klackem vyhánět ty, kdo by tam chtěl strkat latest greatest co nejdřív, to fakt není gamesovací stroj ;-)
Přesně totéž platí pro průmyslovou automatizaci. A je to podobný boj - frikulíni prostě nejsou s to pochopit, že není možné každých 5 let kompletně vyměnit řídící systém elektrárny, protože se někomu už nechce podporovat hardware z doby jeho instalace. Bohužel, zákon o kybernetické bezpečnosti zřejmě tvořil přesně ten typ lidí, co si pod pojmem "informační systém" není schopen představit nic jiného než PC na stole v kanceláři.
-
"frikulíni prostě nejsou s to pochopit, že není možné každých 5 let kompletně vyměnit řídící systém elektrárny"
Natoz aby chapali, ze ten HW bude tak +- 10let starej v dobe, kdy se ta (zdaleka nejen) elektrarna zprovozni ... ;D.
Obcas se trochu ochomejtnu kolem nejakych tech prumyslovych vecicek, a kdyz je v tom neco opravdu ubernovinka ... tak je to 3 roky stary. A to nikdo nechce, protoze to typicky jeste neni odladeny a je to divny, ale ani managori si neprejou, aby zrovna jejich firma delala toho pokusnyho kralika.
-
Ještě doplním AI slopem, pro kontext.
Má schválenou strategii, ne projekt ani plné financování.
Rada CERN 22. 5. 2026 přijala update evropské strategie: FCC-ee je preferovaný další flagship po HL-LHC. Feasibility study prošla, pokračují detailní studie a jednání o penězích.
Finální go/no-go má být v roce 2028. Odhad ~15 mld. CHF. Z rozpočtu CERN zhruba polovina, soukromí dárci slíbili ~860 mil. €, zbytek (řádově miliardy CHF) se teprve shání u členských států, EU a dalších. Stavba by začala až po schválení, provoz ~2045. -
Asi tak. Ostatně třeba na pracovním notebooku mám CPU staré deset let. A, světe div se, normálně stačí. Kdyby mi teď někdo řekl, že další verze systému nebude to CPU podporovat, poběžím koupit za dvacet tisíc nový notebook, který navíc dost pravděpodobně bude konstrukčně podstatně horší než tenhle starý ThinkPad? Nebo nějaký Framework za padesát? Ne. Vyměním ten systém. Protože potřebuju pracovat, ne být free, cool a in.
-
Narazil jsem na to s CentOSem taky, ALE na NASu s úsporným CPU (v2 z roku 2019).
V notebooku starém 10 let bude minimálně -v2 (Nehalem 2008), ale spíše už i -v3. Běžné mainstreamové procesory s podporou AVX jsou s námi už déle (Haswell 2013).
CERN má procesory s x86_64-v1 - tj. ještě o instrukční generaci starší. Ty už nebyly podporované celkem dlouho. Taky proto ještě pořád měli Scientific 7.
-
"ALE na NASu s úsporným CPU"
HP micro G8 ... v zakladni konfiguraci. E3-1220L v2 coz je Q2'12.
Problem? Mno trerba na tom nejde vubec kompilovat rust. Teda de kompilovat binarnim kompilatorem tu presne jednu pythoni vec. Ale kompilator na tom neprekompilujes zadnym zpusobem. Protoze firkulini pouzivaji nejakou uberinstrukci, kterou ten CPU (v pozici NASu nic nedelajici) proste nema.
Az na tom nepude nahodit novesi kernel, nebo ssh nebo samba ... je mi to burt, proste to pobezi se starym a deravym. Holt pridam svoje polinko k tomu nikym neudrzovanymu miliardovymu bordelaku. No a ...
Stejne 99,9999% uzivatelu krabek ma tu krabku deravou uz v okaziku, kdy ji koupej, a taky jim to nevadi, proc by melo me ...
-
Já na něco podobného narazil s administrací UniFi. Běželo to na mikro PC s nějakou starší Core i5 2. generace. Upgradoval jsem systém na Debian 13, ale už jsem nebyl schopen zprovoznit databázi Mongo.
- UniFi vyžadovalo databázi Mongo
- stará verze Mongo nedostupná, stažení nemožné atd...
- nová verze vyžadovala instrukce CPU, které uměl těsně následující CPU, ale ne ten v mém mikro PC, což jsem dohledal kdesi "zastrčené" až po mnoha segfaultech
- výkonově žádný problém i to prastaré PC se flákalo, 8G RAM stačilo s obrovkou rezervou, spotřeba v jednotkách wattů, bylo to spolehlivé, žádný důvod k upgradu, kromě absence instrukceNezbylo než PC odstavit, koupit nové s novým CPU, software zůstal stejný, na novém CPU funkční. UniFi to cca o rok později zabilo opět... ale to je jiná pohádka.
To prastaré PC pak mimochodem dvakrát posloužilo jako nouzově náhradní desktop. S tím problém nebyl, ale pro zcela "nenáročnou" úlohu jako administrace WiFi skrze web UI použít nešlo jen kvůli hloupému rozhodnutí autorů databáze Mongo.
Vnímám to jako plýtvání hardwarem.
-
"proč proboha potřebuje Unifi controller MongoDB"
To neni otazka, na tom nesejde, je to jen dalsi hlasny priklad na tema ... tak ty aktualizace proste vypnem.
Specielne u unifi controleru .. soudruzi z v mem pripade gentoo nevedi, ze mongodb se neda aktualizovat pres vic verzi ... a stejne tak nevedi, ze ten controler nema zavislost na mongodb ... ale na zcela konkretni verzi. A jako bonux, nejnovejsi verze controleru je uz par mesicu rozbita ... takze nejspis to uz nikdy aktualizovat nebudu. Ono to ostatne ani nemusi bezet, staci to zapnout kdyz je treba ze? Problem solved.
-
Chmm ... mam HW ... neco na nem bezi ... budu si porizovat hosting, aby mi bezel unifi controler, kterej nepotrebuje bezet vubec ... jo to je soluusssnnn.
A abych nezapomel, jako bonus tomu dam pristup zvenku do administracni vlany ... i kdyz vlastne, soudruzi z unifi sou prece odbornici a proto je administracni vlana ta defaultni ze? A nejde nijak svepravne zmenit ze? ... tomu se rika bezpecne reseni.
-
Michal ŠmucrStříbrný podporovatel
To není až tak problém UniFi, ale samotného Monga. To vyžaduje specifické další instrukce jak u x86-64, tak ARMu od MongoDB verze 5. Tzn. stejný problém je třeba na RPi 4/5.
Co vím (už nějakou dobu jsem nezkoušel), tak se to dá např. obejít tím, že pokud se to používá v kontejnerech, tak pak použít samostatně jeden na UniFi a druhý na MongoDB. Na Dockerhubu je pořád MongoDB 4.4.30, které chodí jak na starých x86 CPU, tak na RPi.
Ale samozřejmě je to bez upstream podpory, u toho kontejneru bude svítit hromada CVEček.. takže jen myslet na to, segmentovat.. omezit přístupy. -
Nie celkom chapem, preco na starom hardware prevadzkovat ostatny release operacneho systemu. Obzvlast, ked potrebujem pracovat a nie byt free, cool a in.
RHEL8 (Alma, Rocky, Oracle) aj RHEL9 budu podporovane este nejaky piatok; dost mozne, ze dlhsie, ako bude zivotnost daneho stareho hardware. Preco zabijat cas preinstalovanim (RHEL nema podporovany in-place upgrade), ked nemusim? Tieto systemy boli aktualne, ked dany hardware vysiel, funguju s nim a budu este chvilu fungovat. RHEL10 je urceny pre hardware, ktory vychadza teraz, nie pred 10-15 rokmi. Tento hardware tiez bude v prevadzke 10+ rokov.
Aj ja mam jeden stary thinkpad (t430s, ivy bridge, x86-64-v2). Nemam ambiciu na neho tlacit ani Windows 11 (nepodporovany CPU, nema TPM2) ani RHEL10 (nema x64-64-v3). Napriek tomu na nom bezi system, ktory je aktualny a podporovany.
-
Michal ŠmucrStříbrný podporovatel
> Coz jen krasne ilustruje do jake rite celej tux speje, protoze i ty widle jde provozovat na mnohem starsim HW...
Což jen krásně ilustruje, že ani po letech tady nerozlišujete mezi jádrem, distribucí a třeba upstream aplikacemi (např. zmíněné Mongo, co vyžaduje AVX instrukce resp. vyšší ARM arch level už od verze 5 cca r. 2021 a podobně ).
Distribuce i aplikace jsou různé a můžou mít odlišné cíle.
Připadá mi trošku delulu, jak tu má spousta lidí pocit, že spuštění na nejstarší možné archaické konfiguraci je ta největší ctnost.. a měl by to být automaticky pro každého ten ultimátní cíl.Komerční firmy se logicky snaží o to, aby to chodilo co nejlíp jejich zákazníkům. A jestliže majorita z nich používá novější CPU a benefitovali by z toho, můžou uvažovat i zvýšení toho základního levelu. Podobně tam může být i pragmatická úvaha or zúžení okruhu hardware nutného pro testování a podporu.. což bude hrát roli i v případě RHEL, kde je to s nejdelší placenou podporou klidně 14 let od vydání (např. RHEL 7 ELS verze).
Komunitní distribuce k tomu mohou přistupovat odlišně. Jak ze strany celkových minimálních požadavků, tak i třeba organizace repozitářů (multiverse, universe... kitchen sink).
A samozřejmě je tam spousta nuancí u konkrétních věcí.. ty novější instrukce tam nemusí být natvrdo přes flagy kompilátoru u jediného balíčku, může tam být runtime detekce nebo mít víc variant binárky vedle sebe (nařp. glibc-hwcaps) atd.
-
Ty sis zcela komernecne zjevne jeste nevsim, ze na HW dneska dostanu od libovolnyho dodavatele hned pri nakupu 8+ let supportu. I na uplne hloupej desktop mam 5let NBD ...v zakladu, nic extra ...kdycbych chtel platit navic, tak tech 8 mam lusknutim prstu.
Tudiz ten HW support uz dneska prezije ty tvoje uzasny distra.
Nikdo na tyhle planete nestoji o to, vymenovat zcela funkcni veci, na ktery mu navic dodavatel doda nahradni dily.
Kdyz si koupim widle, tak vim, ze mam minimalne 10+3 roky SW supportu. Co mi chces nabidnout jako TUX? Pochlub se ...
Nikoho nezajimaj nejaky cile distribuci nebo aplikaci nebo vi buh koho/ceho. Uzivatele zajima funkcni infrastruktura. Ktera bude mit funkcni support. Ze stojej widle za vyliz? Stojej ... cim dal vic, ale u tuxe je ta sestupna tendence o 2 rady horsi.
ČLÁNKY DO MAILU