Názory k článku
Utilita run0 je bezpečnější náhradou za sudo založenou na systemd

Běží proces != služba není zatuhlá. To pak systemd umožňuje řešit díky keepalive, které si služba ale posílá sama. Předřečník by asi chtěl napojení na nějaký skutečný monitorovací systém, ale to stejně nemůže být v systemd, protože by si stěžoval, že je toho v systemd moc.

Jenže bez prezdivky ... právě napsal „servisa běží“. Kdyby napsal, že nedokáže zjistit, zda poskytuje služby, bylo by to něco jiného. Ale „běžet“ se u programů obvykle používá pro to, zda existuje proces, ne zda poskytuje služby v kvalitě, které by měl poskytovat.

Monitoring služeb je něco úplně jiného, než monitoring procesů. Monitoring služby musí být specifický pro danou službu, takže je v pořádku, že se SystemD nesnaží umět monitorovat služby.

Nikoli Jirsaku to jen ty jako vzdy a ve 100% svych postu blabolis. Bezici sluzba === fungujici sluzba.

A povezte Kefalin, co si predstavujete pod takovym fungujici sluzba? :-) To ze na jednom definovanem API endpointu neco odpovi, nebo ze korektne odpovidaji vsechny endpointy a zadny nekonci neocekavanou chybou pri nejake nezvykle kombinaci na vstupu...? No preju hodne stesti pri tvorbe toho vaseho podle vas dokonaleho monitoringu, co zajisti skutecne fungujici sluzbu za vsech okolnosti... :D

Presne, tesat do kamene. Videl jsem sluzby co bez problemu vraceli 200 na liveness probe, ale k funkcnosti meli hodne daleko, protoze tak nejak ztratili konektivitu k db.

"A povezte Kefalin"

Ja narozdil od tebe nerestartuju sluzby kdyz zbuchnou, protoze me sluzby padaji jedine za zavaznych pricin a tudiz je naprosto mimozni se je snazit automaticky restartovat, protoze to povede maximalne k dalsi destrukci.

Ale jo, nejlepsi napad kdyz ti auto zastavi motor je ... ten motor znova a znova a znova startovat ... to ze napadaly ventily do valcu je takova drobnost kterou netreba resit.

1000x deravejsi...? :-) A muzete tento vyplod prosim necim podlozit? Treba vypisem CVE?

To je ale vůl, že to dělá podle sebe a ne podle tebe, co?

Ale to je dnes úplně se vším. To není jen Linux. Na všechno se hledá a implementuje úžasné, kůl, in, -kompatibilní řešení. To je pak tak komplikované, vyžaduje cloud, appku v telefonu a účty a... že je v praxi úplně na nic. A to nejjednodušší a více než dostatečné řešení je snad schválně opomíjené.

Například, viděl jsem jakýsi návrh na implementaci zpětného sběru PET lahví. To bylo tak složité, že jen na elektřině by to stálo víc, než jaká je užitná hodnota toho odpadu a výsledek by byl, že by ten voser stál za to jen pár hipsterům.

Na všechno se hledá a implementuje úžasné, kůl, in, -kompatibilní řešení.

Před nedávnem tady byla zprávička, že nějaká firma byla prodána jiné firmě a první věta ve zprávičce byla "firmu X určitě není potřeba představovat". No mě jo. Tak jsem se podíval, co to je za borce a co vlastně dělají. Vůbec nikdy jsem o tom neslyšel a v praxi nezavadil.

Potom zprávičky o tom, že to či ono už není pod svobodnou licencí a teď už je to jen komerční. Ok, tak jsem se podíval do svých poznámek, jestli o tom něco někde nemám. A ono jo. 5 let stará poznámka v TODO listu, že na tohle bych se mohl podívat, vypadá to zajímavě, ale chce to velmi důkladně otestovat, protože se mi na tom něco nezdá. Nakonec jsem skončil klasicky u PostgreSQL a to mongo jsem nikdy nepoužil.

Prostě ty projekty nikdy nebyly nic extra. Nikdy. A některé z nich roky vypadaly jen jako trik na nalákání dostatečného počtu "followerů" jen proto, aby je mohl někdo střelit větší firmě a nebo prostě jenom zkusit změnit licenci. A ve výsledku, slušný programátor si to naprogramuje "za víkend". (Čumím na jeden YT kanál, kde borec každou takovou věc napíše v Golangu za pár týdnů.)

IMHO
- SystemD přináší objektivní výhody v podobě deklarativních definic služeb
- Problémem bylo, že byl nasazen ještě dost čerstvě. A stejně jako si tuto ostudu nese KDE už přes tři verze, tak to stejně SystemD, Lennartovy a RedHatu bude komunita připomínat ještě desítky let.
- Docela velkým problémem se zdá byla Lennartovat osobnost.

...jenže ono to tak vypadalo...

Ale díky za vysvětlení, protože tyto informace nejsou úplně veřejně odstupné. Mimochodem, Debian naopak dlouho odolával přechodu na systemd. Jeden z průkopníků byl, myslím, Arch.

Fedora to nastartovala, Arch to nejvíc drajvoval a Debian tomu dal razítko. RHEL 7 to přinesl do korporátu, ale rozhodně neprosadil v linuxové komunitě. Než RHEL 7 vyšel, už bylo rozhodnuto. Red Hat byl tenkrát hodně bottom-up, takže do zorného pole vedení se to dostalo celkem pozdě. Na jednu stranu systemd řešil hodně problémů zákazníků, na druhou stranu to byla velká změna z mnoha riziky. Ale hlavně systemd už byl tak integrovaný do Fedory, že pro RHEL 7 už bylo těžké hodit zpátečku, i kdyby chtěli.

uherský rok, fakt si to nepamatuju

Jenže tohle se dá řešit tím, že místo vim rc.local uděláš cp example.service x.service; vim x.service a změníš jeden řádek. Prostě nemá smysl dělat věci 20 let špatně a ještě navíc je předávat nové generaci, když řešení je doslova triviální. Jednak má existovat veřejná dokumentace (ta existuje) a potom může existovat pomůcka pro vytvoření té unity. Přičemž ale v praxi stejně stačí zkopírovat a změnit existující service file.

Ale opět, tohle je téma na článek, kde má být vysvětleno, proč je něco špatně a jak to dělat lépe. Ostatně o existenci rc.local se také někde musíš dozvědět, to také nevíš od narození. Takže místo 20 let starého recyklátu o 30 let obsolete rc.local je lepší napsat článek aktuální k danému roku a tam to vysvětlit.

Vše lze řešit. Ale i to, co jste napsal znamená "řešit". Jenže nejen já chci řešit to, co řešit chci a nikoliv to, co řešit musím. Takže když je něco good enough, je zcela bezpředmětné, že to lze udělat i lépe když tohle řešit nechci a lze to zároveň udělat možná sice hůře, ale dostatečně a snáze.

Stejně tak vás může překvapovat úspěch třeba Windows nebo různých jiných technologií. Nejsou dobré. Ale jsou dostatečně dobré na to, aby stačily. Tohle by se mělo nejen v IT učit někde ve čtvrťáku na střední jako jedno ze základních pravidel poptávky. Ekonomická teorie k tomu pochopitelně existuje, ale čím dál víc zjišťuju, že v praxi ji většina lidí vůbec neumí aplikovat na jevy běžného života a praxe.

30. 4. 2024, 14:06 editováno autorem komentáře

nemá smysl dělat věci 20 let špatně

Ano, to nemá. Ale... KDO tu definuje co je spatně? Ty? Já? LP? Co když je něco špatně pro TEBE, ale ne pro MNE? Nebo je něco špatně pro MNE a ne pro TEBE?

Vymyslíme si (umělý) problém a budeme hledat pro něj řešení. A budeme se cítit ukřivděně, když pro ostatní ten problém není problém.

Příklad: provozuji pro svoji potřebu službu, která implementuje web server pro své potřeby. Jakmile ta služba přešla na systemd, tak není možné, abych ji nastartoval na privilegovaném portu (nechci mít webserver na portu 8080, chci, aby poslouchal na portu 80). Žádný návod na opravu nefunguje, prostě se systemd není schopná se nabindovat na port 80, přestože při přímém spuštění to funguje. Už jsem toho zkusil tolik a nic. Dokonce jsem si celou unitu napsal od nuly a co nejjednodušší. Port 80 ne. Tak jsem začal tu aplikaci startovat přes rc.local. To zlobilo zase jinak, tak jsem se na to vy*al a posadil před to (úplně zbytečné) haproxy. No krása. Bugreport uzavřen „Mě to funguje, máš to rozbitý“ (to vím i bez tebe, jinak bych to nepsal). Co jsem před přechodem na systemd dělal špatně, že mi to fungovalo?

Vůbec mi není jasné, jak a proč by měl port 80 souviset se systemd. Pokud si ta služba potřebuje otevřít port 80, tak buď musí běžet po rootem nebo mít příslušné capabilites. A pokud ani jedno z toho není možné z nějakého důvodu splnit, tak je vhodné tam mít proxy. Takto používám nginx pro služby, které opravdu pod rootem spouštět nechci, naopak chci je spouštět ve velmi omezeném prostředí (freebsd jail) a tedy je nutné mít reverzní proxy. Se systemd tohle vůbec nijak nesouvisí.

> Se systemd tohle vůbec nijak nesouvisí.

Evidentně to _nějak_ souvisí, když přímo spustit jde, ale přes systemd mu to nejede.

Kde to "nějak" úplně klidně může znamenat to, že s přechodem na systemd do té unity někdo dal (správně) user, takže to neběží pod rootem jako před tím. A je tedy vhodné to buď vyřešit pomocí reverzní proxy (nginx, haproxy) nebo na firewallu. A tohle tady nevyřešíme bez toho, že bychom věděli alespoň název té služby a taky obsah toho unit file.

To je přesně to, co řeším. Jak souvisí port se systemd!

Pro upřesnění... Služba běží pod NEprivilegovaným uživatelem, spuštění po rootem se aktivně brání (už to mi přijde naprd, ale to se systemd nesouvisí). OK, dostane patřičná privilegia (setcap 'cap_net_bind_ser­vice=ep' /path/to/file), ručně ji spustím a vidím, že port otevře a běží pod uživatelem (setuid si aplikace řeší sama). To samé udělám v systemd unit a služba není schopná otevřít port. (Pro upřesnění, už jsem důvody zapomněl a pátrat po nich nehodlám, každopádně to souviselo se systemd, které dělalo věci navíc.)

Jelikož se jedná o LXC kontejner v limitovaném prostředí, tak nevidím důvod předsazovat před aplikaci proxy, protože ta proxy stejně v tomto případě aplikaci nijak neochrání a nic jiného v tom kontejneru neběží. A i v rámci celého stroje neběží nic dalšího, co by potřebovalo/využilo reversní proxy.

A taky je jednodušší nastavit síť pomocí ip nebo přidat pravidlo do firewallu spuštěním iptables. Jenže každý, kdo si to zkusí takhle párkrát udělat, musí po pár pokusech zjistit, že je to neudržitelné. Že se mu pak spouští služby dřív, než je nakonfigurovaná síť, firewall mu zůstává z půlky nenakonfigurovaný kvůli chybě apod. Proto vzniká ta spousta nástrojů, které řeší start a provoz systému. Ať je to SysVinit, systemd, distribuční skripty, Network manager, firewalld apod. Samozřejmě můžete všechno nacpat do rc.local a nepoužívat žádné distribuční skripty ani jiné nástroje. Ale z mnoha dobrých důvodů se to tak nedělá.

Ale ten stav distribucí před tím odpovídá tomu, že nebyly odpovídající nástroje, na které by se vyplatilo přejít. Byly nástroje, které řešily některé problémy, ale nevyplatilo se na ně hromadně přejít.

Takže se čekalo na nástroj, který 1. vyřeší více problémů (když už se musí inicializace systému předělávat, ať ta změna přinese co nejvíce výhod), 2. shodne se na něm co nejvíce distribucí, ať se to nedělá pokaždé jinak, 3. rozšíří se dost rychle, aby se jeho výhody začaly rychle uplatňovat. A splnil to systemd.

Dneska mají někteří pocit, že byl systemd nějak „tlačen“ (ale nikdy nenapíšou kým), jenže ten princip rozšíření (že tu budou větší změny, napříč distribucemi a docela rychle) byl zakódován v těch požadavcích, bez jejichž splnění nemohl uspět žádný nový nástroj pro správu procesů.

na které by se vyplatilo přejít

Proč by se na mě mělo přecházet? Vrátím se k té architektuře. Tomuhle se říká nechat problém vyhnít tak, že už není jiné řešení, než to zbourat. Takže otázka je, opravdu budeme každých 10 let měnit podvozek jen proto, že předchozí řešení nechal někdo vyhnít?

Tohle totiž klidně může postihnout i systemd. A zatím v reálu vidím přesně ty věci, o kterých jsme se hádali před 10 lety. V každé unitě u nových service vidím restart. V každé. Tohle pro mě neznamená pokrok, ale krok zpět do bažin.

A psal jsem to už tady vícekrát. Pokud někdo není schopen vyrobit deb/rpm balíček, tak to znamená, že ten jeho projekt je hnůj. Zabalit ten hnůj do lepšího kontejneru nepomůže. Pokud někdo má problém s tím, že mu jeho server padá, tak restart opravdu nepomůže. Naopak to jen zakryje ten problém a na řešení se bude čekat déle.

Takže ano, systemd je super. Jen ho nikdo nepoužívá ke věcem, které systemd opravdu umí. Nechal jsem tady hint u diskuse o Monit. Monit neumí pracovat multithread. Přitom je v systemd triviální si jednotlivé checky dát jako timery. A nikdo to nedělá. Neviděl jsem žádný nový projekt, který si ke svému uživateli dá do systemd správu procesů, timery apod.

A takových věcí by se našla hromada. Takže ano, s velkou slávou jsme přešli na lepší systemd, ale výhody toho nikdo nepoužívá.

Dneska mají někteří pocit, že byl systemd nějak „tlačen“

Tohle platí u každé konspirace. Pokud není ve veřejnosti známa pravda, tu pravdu nikdo nesděluje apod. tak se vždy najde nějaká historka, která tu pravdu nahradí.

Proč by se na mě mělo přecházet?
Protože to stará architektura neumožňuje.

Vrátím se k té architektuře. Tomuhle se říká nechat problém vyhnít tak, že už není jiné řešení, než to zbourat.
Ne, tomuhle se říká, že evoluce občas vede do slepých uliček, ze kterých se nedá dostat jinak, než větším skokem. Prostě uváznete u nějakého lokálního maxima a výš už se dostanete jedině tak, že nějaká ta údolí přeskočíte větším skokem.

Evoluce skriptů používaných se SysVinit vedla k tomu, že služby dělaly dvojitý fork, aby se dostaly z dosahu správce procesů (což tak nějak samo o sobě vypovídá o kvalitě správce procesů). Abychom se posunuli dál, bylo potřeba z téhle evoluční slepé větve skočit zpět k tomu, že proces spuštěný správcem procesů je hlavní proces služby a správce procesů nad ním tudíž může mít kontrolu. Například. Pak ale zase potřebujeme nějakou signalizaci toho, že příslušná proces začal poskytovat své služby a je možné startovat závislé služby.

Pokud někdo má problém s tím, že mu jeho server padá, tak restart opravdu nepomůže. Naopak to jen zakryje ten problém a na řešení se bude čekat déle.
To, že nějaký proces spadne, nemusí být nutně problém toho procesu. Třeba došel nějaký zdroj. Ve spoustě případů naopak průzkum problému nijak nebrání běhu aplikace, takže stejně první co uděláte, že nastartujete službu znova, a teprve pak budete zkoumat, co se stalo. A to není potřeba dělat ručně. Databázi nebudu znovu startovat automaticky, protože pád mohl způsobit (nebo být způsoben) poškozením dat a restart situaci jenom zhorší. Webový server servírující statické soubory klidně můžu hned nastartovat znova, protože to nejhorší, co se může po startu stát, je to, že to znovu spadne. Jako správce mám na výběr a vyberu si to, co nejlépe vyhovuje pro danou službu.

Mimochodem, tenhle přístup, že dokonalý software běží na dokonalém hardwaru, byl už ve spoustě aplikací překonán. První masové použití toho principu byl Internet. Ten přišel s tím, že nebudeme budovat dokonale odolnou síť, místo toho udělám síť tak, že s výpadky počítá a umí si s tím poradit. Na stejném principu pak vznikly cloudy a orchestrace kontejnerů. Nespoléháme se na hardware, který nemůže (skoro) nikdy selhat. Místo toho navrhneme infrastrukturu tak, že se se selháním nějakého hardwarového uzlu počítá a infrastruktura je navržená tak, že s tím počítá a přežije to. A podobně je to i s kontejnery. Pokud počítáte s tím, že kdykoli může nastartovat nový kontejner kvůli větší zátěži, a s tím, že může kontejner kdykoli zmizet, protože umřel hardware pod ním, máte tím vyřešenou i situaci, kdy kontejner umře kvůli softwarové chybě. Což neznamená, že budete v programu záměrně nechávat chyby – ale znamená to, že pád serveru není takový strašák, jako dřív, protože holt spadne jedna instance z více.

Jen ho nikdo nepoužívá ke věcem, které systemd opravdu umí.
Nepoužívají ho tak do hloubky autoři aplikací, protože když to udělají, snese se na ně kritika, že tam zadrátovali závislost na systemd. Důležité je ale i to, že to může použít konkrétní správce. Ono kdyby stačilo nainstalovat balíčky z distribuce a měl jste nakonfigurované všechny služby podle svých potřeb, včetně monitoringu, auditu, upozorňování, pak by nebyli potřeba správci těch systémů. Jenže zatím každá konfigurace serveru/clusteru vypadá trochu jinak a musí se tomu přizpůsobit i ty systemd jednotky.

Tohle platí u každé konspirace. Pokud není ve veřejnosti známa pravda, tu pravdu nikdo nesděluje apod. tak se vždy najde nějaká historka, která tu pravdu nahradí.
A stejně je to i v případě, kdy veřejnosti sice je známa pravda, ale některým lidem nezapadá do jejich představ o světě. A to je právě případ systemd.

1. 5. 2024, 10:31 editováno autorem komentáře

nějakého lokálního maxima

Tohle je dost subjektivní. Fascinují mě lidé, kteří nejdřív podepíšou nějaká pravidla a potom se diví, že podle těch pravidel něco nejde. No ano, od toho máme pravidla, aby něco nešlo. A proto jsme je podepsali a tím podpisem stvrzujeme, že tohle dělat nebudeme. A pokud někomu vadí, že tohle nejde, tak měl nejdřív vyjednávat o těch pravidlech. Tím současně odpovídám i na ty slepé uličky, staré architektuře apod. Já mnohem raději budu používat systém, kde někdo 5 let přemýšlí a potom to 50 let stojí v podstatě beze změn, než systém, kde nikdo nad ničím nepřemýšlí a všechno neustále přestavuje.

Třeba došel nějaký zdroj.

A jak se to tak jako stane? Já, protože jsem jednoduchý člověk, tak jsem si vytvořil jednoduchá pravidla. Třeba nemám na virtuálkách swap. Proč? Protože špičky jsou na všech VM přibližně ve stejný čas, takže když začne swapovat jedna, tak velice rychle začnou swapovat všechny. A tedy se vytíží diskové pole až do smrti. Takže swap nedává vůbec žádný smysl.

Který další zdroj by měl dojít? Paměť. No samozřejmě, procesy potřebují paměť, kdo by to byl čekal. Paměť nelze nahradit swapem, takže kupodivu, jaké překvapení, ten HW musí mít paměť. Je to mrzuté, pro některé je to šok a než řešit problém, tak na svůj blog jednoho nejmenovaného projektu napíší, že si mají do systemd dát 10minut timeout per service, protože jejich diskové nezvládá boot všech vm současně. Super no, kromě paměti tam nemají ani disky.

Tím jsem chtěl říct, že pokud někdo používá systemd restart proto, že mu dochází zdroje, tak se má postarat o ty zdroje.

A nebo se nad tím zamyslet o něco víc než jen 1ms. A třeba doplnit systémové volání "hele, dochází mi paměť, vážené procesy uvolněte vše, co můžete". No, jenže, ten proces tu paměť k něčemu potřebuje, takže potom začne více hrabat na disky. A pokud je tam nějaký proces, který si jen tak z nudy potřebuje alokovat 640TB paměti, tak by jej bylo vhodné opravit a ne restartovat.

Evoluce skriptů používaných se SysVinit vedla k tomu, že služby dělaly dvojitý fork, aby se dostaly z dosahu správce procesů (což tak nějak samo o sobě vypovídá o kvalitě správce procesů).

A tím se vracíme do diskuse 10 let zpět. Chtěl opravdu někdo správce procesů? Chtěl to někdo? Ok, dobře chtěl. Tak máme správce procesů. Který se ale současně brání tomu to spojit třeba s monitoringem toho, co ten proces má dělat. Takže jsme se ve výsledku jen zbavili dvojitého forku, který někdy někomu možná z nějakých neznámých důvodů vadil. Tleskám.

Mimochodem, tenhle přístup, že dokonalý software běží na dokonalém hardwaru, byl už ve spoustě aplikací překonán.

Moc hezký trolling. Hezky si upravuješ realitu.

Moje poznání z praxe je následující. Místo toho, aby se koupil prachobyčejný komoditní hw a ta appka se napsala nudně dle 50 let starých standardů a ono by to bohatě stačilo po dobu next business day záruky, tak se právě nasazuje cool moderní řešení, které ale nikdo neumí ovládat. Takže to padá. Padá to mnohem víc, než ultranudný server ve vedlejším racku. A argumenty jsou "no co když tam náhle přijde více lidí?" "kolik je více?" "no třeba 1000!", "pardon, to ale náš ultranudný server zvládá levou zadní s prstem v nose a ani nezapíná druhý cpu", "hmmm a jak to?"....

V praxi jsem viděl mnoho řešení navržených pro celý vesmír, které v realitě vůbec nezvládalo prachobyčejných 10M lidí v ČR.

Netuším, o jakých pravidlech a jejich podpisu je řeč. Já jsem nikde nepodepisoval, že se má Apache odforkovat z dosahu SysVinitu ani že má mít vlastní utilitu na správu procesů. To prostě vyplynulo z toho, že SysVinit neposkytoval služby, které potřeboval Apache a jeho správci.

Tím jsem chtěl říct, že pokud někdo používá systemd restart proto, že mu dochází zdroje, tak se má postarat o ty zdroje.
Ale ony mu nemusí docházet systematicky. Může se stát, že se jedna aplikace zblázní a vyžere všechnu dostupnou paměť nebo zaplní disk. Nemělo by se to stát, ale je lepší počítat s tím, že se něco takového stát může. Stejně jako by se nemělo stát, že vypadne napájení – přesto dáváme do datových center UPS a agregáty, protože je lepší počítat s tím, že se něco takového může stát.

Pořád je to o tom, zda se snažíme postavit systém, který nemůže selhat (a nakonec stejně selže), nebo jestli stavíme systém, u kterého se se selháním komponent počítá a systém se z toho umí zotavit, pokud možno automaticky.

Chtěl opravdu někdo správce procesů?
Ano, chtěl. Kdyby to nikdo nechtěl, nejsou ve všech distribucích pomocí shell skriptů nad SysVinitem dobastlení správci procesů. Přičemž to „dobastlení“ nemyslí nijak zle vůči autorům – v době, kdy to vznikalo, to jinak nešlo.

Který se ale současně brání tomu to spojit třeba s monitoringem toho, co ten proces má dělat.
Jak se tomu brání? systemd je správce procesů, není jeho starostí řešit, zda ten proces dělá, co má. To je starost jiných nástrojů, monitoringu – a ty mají možnost, když zjistí, že je s procesem něco špatně, chtít nějakou akci po správci procesů –třeba ukončení procesu nebo jeho restart.

Takže jsme se ve výsledku jen zbavili dvojitého forku, který někdy někomu možná z nějakých neznámých důvodů vadil.
Ten důvod není neznámý a řešili to snad všichni správci procesů, kteří přišli po SysVinitu. Základní věc, co musí správce procesů vědět, je zda jím spravovaný proces běží nebo neběží. K čemuž je potřeba, aby ten proces byl potomkem správce procesů. Zapsat PID procesu do nějakého souboru a občas otestovat, zda proces s takovým PID pořád máme v systému, a doufat, že je to pořád ten samý proces a ne nějaký jiný, který náhodou dostal stejné číslo, fakt není systémové řešení.

Hezky si upravuješ realitu.
Neupravuju. Stavěla se datacentra s třemi nezávislými přívody elektřiny a internetové konektivity, uvnitř minimálně dva nezávislé napájecí okruhy, to samé v serveru, značkový server se záručním listem podepsaným samotným ředitelem HP, na serveru certifikovaný aplikační server… Všechno navržené pro provoz 24×7 se spoustou devítek, protože spolehlivost celého řešení znamenala ty devítky mezi sebou pronásobit.

A pak přišel Google, který řekl, že kašle na superdrahé servery, protože spolehlivějšího výsledku dosáhne, když místo jednoho drahého serveru pořídí deset levných počítačů a bude počítat s tím, že mu každý týden jeden lehne. Tak nebude řešit nějakou záruční opravu, ale prostě tam dá jiný levný počítač.

appka se napsala nudně dle 50 let starých standardů a ono by to bohatě stačilo
Akorát že by ta appka taky stála podle 50 let starých cen. Jinými slovy – nikdo by ji nezaplatil. To se řeší možná u řízení vlaku nebo letadla, nebo ještě o několik úrovní dál u řízení jaderné elektrárny. Chtěl jsem napsat ještě u vesmírných raket, ale tam už Musk také ukázal, že se to nevyplatí.

Chápu, že je to paradoxní, že vývoj neznamená vždy to, že by něco nového bylo kvalitativně lepší. Často to znamená, že je to kvalitativně jen 90 % předchozího, ale za 10 % ceny. Takže to najednou má daleko víc možností užití a odvede to daleko větší službu.

Netuším, o jakých pravidlech a jejich podpisu je řeč.

Už jenom tím, jaký systém používáš. Když jdeš hrát fotbal, tak je taky nesmysl si tam brát tenisovou raketu.

Může se stát, že se jedna aplikace zblázní a vyžere všechnu dostupnou paměť nebo zaplní disk.

No to jistě může. Jenže na tohle jsou techniky. Ta appka může dostat diskový prostor pouze na jednom oddíle, případě mít kvóty. Totéž pro paměť.

A pak přišel Google

Ale to jo. Jenže já se bavím o tom, že někdo staví "Google" na místě, kde opravdu stačí koupit server za půl mega a tím je vše vyřízeno. Pro ČR to stačí, ten HW se bude nudit a tak dále.

Vedle toho je projekt typu "Google", HW za X mega a ve výsledku to ještě navíc nefunguje. A tohle já jsem viděl mnohokrát. A mám pocit, že oba žijeme v jiném světě. Ty to v diskusích stavíš tak, že ten "dokonalý hw" je super drahý a že je mnohem levnější to dělat jinak. A já vidím zcela nesmyslné a ultradrahé řešení typu "Google", zatímco by stačilo koupit obyčejný server za půl mega. A do toho ještě od tebe čtu poznámky typu "opravdu si myslíš, že to CloudFlare dělá špatně?" Ne nemyslím, mě je cloudflare úplně u pr... Ale, píšu to asi po padesáté, že na ten problém vůbec nebyl cloud flare ani google potřeba, stačí opravdu jen jeden prachobyčejný server doslova za pár kaček.

Ono ve světě linuxu zas tak velký výběr nebyl, takže jsem obvykle používal distribuční SysVinit+shell skripty (protože tak to měly skoro všechny distribuce) a pro své věci pak daemontools od DJB.

Ano, jsou na to techniky – a někdy se vyplatí do toho investovat, a někdy se naopak vyplatí jednou za dvacet let vyřešit problém způsobený tím, že ty limity nastavené nejsou.

Ano, jeden server za půl mega by to často vyřešil. Jenže pak si někdo usmyslí, kolik tam má být devítek, a najednou to s jedním serverem nejde.

Drahý není jen hardware, ale hlavně lidé. Takže stejně, jako mnoho aplikací nevyžaduje drahý „dokonalý HW“, nevyžadují ani dokonalou konfiguraci a provoz. Takže třeba stačí, když tam nejsou nastavené limity na diskový prostor a paměť, nebo stačí, když to po pádu procesu automaticky restartuje systemd, než abyste platil člověka, který vyzkoumá, jaké limity tam mají být nastavené, nebo platil člověka za to, že v noci tu službu restartuje.

Když píšeš o dokonalém softwaru a dokonalé konfiguraci, je k tomu podle mne potřeba i dokonalý HW. Pokud stačí server za pár kaček, pak asi stačí i správci za pár kaček a vývojáři za pár kaček, a na začátku nějaký lépe placený architekt, který to navrhne tak, aby to i za těch pár kaček dobře fungovalo.

Ano, jeden server za půl mega by to často vyřešil. Jenže pak si někdo usmyslí, kolik tam má být devítek, a najednou to s jedním serverem nejde.

Tímhle jsme si prošli také. Jenže tu zakázku nemáš povinnost vzít. A pokud ji někdo vezme a dodá nefunkční něco za 1mld (zatímco naše stálo do 10M), tak se potom nesmí divit, že u něj zvoní policie a tahá se to v médiích apod. Prostě někdo zcela konkrétní vymyslel velmi divné kritérium, které nemá žádnou oporu v realitě (zákonné lhůty na cokoliv), takže je velmi správné, že je dotyčný tahán médii a po soudech.

Potom někdo přišel s tím, že plánovaná odstávka jednou měsíčně vlastně vůbec ničemu nevadí a my jsme to zvládli za malé jednotky M po celou dobu existence projektu. A bez výpadků. Doslova bez jediného výpadku za celou dobu projektu na levném HW.

Proč to píšu. Nemůžeš argumentovat tím, že si někdo vymyslí pár devítek a následně argumentovat cenou. Pokud si někdo vymyslel X devítek, tak to taky musí veřejně obhájit před daňovými poplatníky, proč zrovna tady, když to žádný zákon nevyžaduje, mít extra super dostupnost a proč mají občané platit extra cenu navíc, když jim to ve výsledku vůbec nic nepřinese. A taky to ale musí fungovat. Nesmí se vyhodil 1mld korun s argumentem "no někdo chtěl dvacet devítek" a už vůbec neodpoví na otázku, proč to teda vůbec nefunguje. Kde těch 20 devítek uvidíme, když to už dva roky vůbec nejede.

Takže třeba stačí, když tam nejsou nastavené limity na diskový prostor a paměť, nebo stačí, když to po pádu procesu automaticky restartuje systemd, než abyste platil člověka, který vyzkoumá, jaké limity tam mají být nastavené, nebo platil člověka za to, že v noci tu službu restartuje.

Proč by to měl někdo zkoumat? Ty pracuješ pro nějaké mimozemšťany a každý den se potýkáš s něčím, co lidstvo nikdy nevidělo?

Služby nemají padat. Nikdy jsem neviděl spadnout apache a postgresql. Takže kupodivu ty moje nestabilnější systémy neměly žádnou možnost automatického restartu, protože jsem to nikdy nepotřeboval.

Tahle tvoje argumentace je stylem: "přistáli jsme na mimozemské planetě a všechno vidíme poprvé". Pardon? Ten SW se musel nějak vyvinout, že ano. Takže během vývoje (a to je za mě dost pozdě) jsou známy limity. Proč je to dost pozdě? Protože před samotným vývojem proběhla diskuse, jaké všechny služby použijeme. A tyto služby ti navrhovatelé znají už před tím. Takže to "zkoumání" je hotové 10 let před tím, než je tento SW uveden do provozu.

Takže argumentace, že musím platit člověka, který bude za provozu zkoumat co se kde má nastavit je pouze známkou dost špatné praxe. V týmech, kde jsem se podílel na stavbě vývojového a produkčního prostředí to probíhalo tak, že jsme si sedli s vývojem, dali jsme na stůl služby, které známe, vybrali jsme nějaký společný bod - technici věděli, jak se to instaluje a nastavuje a vývojáři s tím chtějí pracovat a oba týmy s tím mají dobrou zkušenost, chtějí to použít, rádi to používají apod. Takže to není vůbec o tom, že až za provozu se teda poprvé zjistí, jak se to má nastavit a ten technik je úplně mimo, protože to nikdy neviděl.

Pokud stačí server za pár kaček, pak asi stačí i správci za pár kaček a vývojáři za pár kaček, a na začátku nějaký lépe placený architekt, který to navrhne tak, aby to i za těch pár kaček dobře fungovalo.

Což v praxi znamená, že 6 lidí v naší firmě vyrobilo funkční produkt, který za celou dobu provozu dle zákona ani jednou nespadl, zatímco produkt za 1mld se pro jistotu ani nerozjel a bylo nutné jej o několik let odložit.

Takže ono naše ultranudné řešení je nakonec i nejlevnější a nejproduktivnější.

Pokud si někdo vymyslel X devítek, tak to taky musí veřejně obhájit před daňovými poplatníky, proč zrovna tady, když to žádný zákon nevyžaduje, mít extra super dostupnost a proč mají občané platit extra cenu navíc, když jim to ve výsledku vůbec nic nepřinese.
Jenže daňoví poplatníci to vidí úplně opačně. „Měli jsme na to 30 dní, ale 1/3 se nás tam musela na zkoušku připojit hned první den a systém to nezvládl. Fůj, kdo to dělal, vládo octup, platíme daně, tak to musí fungovat na 100 %.“ Předpokládáte, že občané ve vztahu k veřejné správě uvažují racionálně, což je v ČR chybný předpoklad. (Rovnou dodávám, že je irelevantní, jestli to ten systém měl nebo neměl zvládnout. Podstatné je to, že občané ve vztahu ke státu neuvažují způsobem „zákon úřadu něco nenařizuje“, ale způsobem „platím daně, tak musím dostat daleko lepší služby, než v komerčním sektoru“.)

Proč by to měl někdo zkoumat?
Aby zjistil, jaký diskový prostor bude potřeba nebo jaká paměť. Protože když to mám omezit víc, než co je dostupné na serveru, musím to vědět přesněji.

Služby nemají padat.
A hardware nemá odcházet a datová centra nemají ztrácet externí napájení.

Nikdy jsem neviděl spadnout apache a postgresql.
Já ano.

Takže kupodivu ty moje nestabilnější systémy neměly žádnou možnost automatického restartu, protože jsem to nikdy nepotřeboval.
Jo, a nikdy jsi nepotřeboval obnovu ze zálohy, tak nezálohuješ.

Akorát že v praxi se neřeší jenom ty problémy, se kterými se už dotyčný setkal, ale je snaha poučit se i od ostatních a předcházet problémům, které mohou nastat, protože se s nimi už setkal někdo jiný.

Ten SW se musel nějak vyvinout, že ano. Takže během vývoje (a to je za mě dost pozdě) jsou známy limity. Proč je to dost pozdě? Protože před samotným vývojem proběhla diskuse, jaké všechny služby použijeme. A tyto služby ti navrhovatelé znají už před tím. Takže to "zkoumání" je hotové 10 let před tím, než je tento SW uveden do provozu.
Takový software má jednu drobnou vadu – že je absolutně k ničemu. Protože je napsaný podle 10 let staré specifikace, která už vůbec neodpovídá současným požadavkům.

Jinak odhad potřebných zdrojů se samozřejmě na začátku udělá, aby bylo jasné, jaký hardware je potřeba. Jenže tam se počítá i s nějakými rezervami a počítá se to se vším, co na tom serveru poběží. To ovšem neznamená, že by někdo dělal odhad, kolik spotřebuje hlavní aplikace, kolik ssh démon, kolik logovací démon atd. To, že začne nekontrolovaně požírat paměť nebo disk se může stát u každého procesu, který na tom serveru běží, nebo se třeba spouští jen jednou za čas.

Jenže daňoví poplatníci to vidí úplně opačně.

Tak jednak si tohle vůbec nemyslím, ale to není podstatné. Podstatné je: TAK JIM TO MÁ NĚKDO VYSVĚTLIT. A nemůže to probíhat tak, že přijde státní zmocněnec pro GDPR do ČRo a není schopen vysvětlit ani triviální případ s fotbalem na vesnici. Lidi reagují jako trollové právě proto, že mají 30 let zkušenost, že nejvyšší státní úředník doslova pro cokoliv je absolutně neschopný odpovědět na cokoliv z jeho oboru. Proto se lidi snaží někam přihlásit první den, protože vědí, že následujících 29 budou řešit neschopnost státních úředníků. A vědí, že nikdo neposune zákonnou lhůtu pro cokoliv, protože by tím přiznat totální neschopnost státní správy. Takže tihle lidé jednají naprosto logicky.

A za druhé, kdyby se ten SW vyvíjel stylem: ano, bude tam nonstop paralelně 10M lidí a ne, vůbec žádný HW navíc nedostanete, protože jej k ničemu nepotřebujete, tak je také po problému. A tohle mě jako technika štve o to víc. Že v očích veřejnosti je náš obor neustále očerňován a že "dnešní technika" to nezvládá. Přitom vím, že se to dá zvládnout levou zadní a jsem naštvanej na ty autory toho díla.

Aby zjistil, jaký diskový prostor bude potřeba nebo jaká paměť. Protože když to mám omezit víc, než co je dostupné na serveru, musím to vědět přesněji.

A není levnější koupit nové disky? Myslím to doslova. I doma jsem řešil, co s daty, jak to roztřídit apod. a po měsíci bádání jsem naklikal v alze a druhý den jsem měl doma 4x větší úložiště.

Totéž kdysi dávno náš šéf. Nevydržel poslouchat naši mikrooptimalizaci čehosi, následující den bylo na stole 256GB RAM za cenu nižší, než na nákladech stála naše diskuse.

Jo, a nikdy jsi nepotřeboval obnovu ze zálohy, tak nezálohuješ.

Zálohuju, protože disky se kazí a uživatelé sem tam něco smažou.

Argumentačně úplně mimo. Server má dva zdroje, když jeden odejde, tak se za provozu vymění. Má redundantní disky, takže se za provozu vymění. Ano, může odejít základní deska, ale ta pravděpodobnost je tak malá, že se to za 4 roky nikdy nestalo. A i kdyby se to stalo, tak se ten projekt do pár hodin rozjede na druhém HW. Tohle se mi ale v praxi nikdy nestalo. Tím neříkám, že nemůže, ale kdyby se to stalo, tak vůbec o nic nejde. Ona i ta jaderná elektrárna má scram, že ano.

Protože je napsaný podle 10 let staré specifikace, která už vůbec neodpovídá současným požadavkům.

Zase to překrucuješ. Pokud na příští produkt použiju apache a postgresql stejně jako před 12 lety, tak to vůbec neznamená, že je ten projekt 12 let starej. Já jsem nemluvil o specifikaci projektu, ale o použitých komponentách. A jestli je tam apache, nginx, nebo něco, co vyjde až jako superhorká novinka zítra, tak to na té podstatě toho projektu vůbec nic nemění. V konečném důsledku je úplně jedno, kdo ten HTTP protokol vygeneruje.

Tak jim to má někdo vysvětlit.
Kdo?

Lidi reagují jako trollové právě proto, že mají 30 let zkušenost, že nejvyšší státní úředník doslova pro cokoliv je absolutně neschopný odpovědět na cokoliv z jeho oboru.
Ta závislost je opačná. Třicet let pravicové strany lidi přesvědčují, že na státu je potřeba hlavně šetřit. No tak se šetří a pak máme takovéhoto nejvyššího státního úředníka, který není schopen odpovědět na cokoli z jeho oboru – protože kritérium pro jeho výběr bylo hlavně ušetřit.

Že se tím reálně nic neušetří, právě naopak? No jasně.I u státu platí, že nejsme tak bohatí, abychom si mohli dovolit kupovat levné věci. Ale zatímco u zboží už to mnoha lidem došlo (ale zdaleka ne všem), u státu to pořád drtivé většině lidí nedochází.

A není levnější koupit nové disky?
V okamžiku, kdy se nějaká aplikace zblázní a disky zaplní? To ani nákup nových disků nepomůže, protože se to nestihne.

Nevydržel poslouchat naši mikrooptimalizaci čehosi, následující den bylo na stole 256GB RAM za cenu nižší, než na nákladech stála naše diskuse.
To tady ale tvrdím celou dobu.

Zálohuju, protože disky se kazí a uživatelé sem tam něco smažou.
Stejně, jako občas selhávají disky nebo uživatelé, občas selhávají i aplikace.

Server má dva zdroje, když jeden odejde, tak se za provozu vymění. Má redundantní disky, takže se za provozu vymění.
No a aplikace má několik nodů, a když jeden odejde, tak se za provozu nastartuje jiný.

Já jsem nemluvil o specifikaci projektu, ale o použitých komponentách.
No jo, ale on už ten projekt možná nikdo nebude chtít psát v PHP, ale třeba v JavaScriptu, Go nebo Javě. A možná dokonce usoudí, že na uložení dat je vhodnější něco jiného, než relační databáze.

A jestli je tam apache, nginx, nebo něco, co vyjde až jako superhorká novinka zítra, tak to na té podstatě toho projektu vůbec nic nemění. V konečném důsledku je úplně jedno, kdo ten HTTP protokol vygeneruje.
Ona to taky může vygenerovat nějaká lambda běžící v cloudu, takže u mne žádný Apache ani nginx nebude. Nebo se většina logiky odehraje na frontendu a většinu HTTP obstará nějaká CDN. A pak tam bude nějaký RESTový backend – možná rovnou nějaká cloudová databáze jako Firebase nebo SurrealDB. Dost možná, že provozovat to v cloudu bude po nějaké době dražší, než kdyby se to provozovalo na vlastním, ale na začátku se dost ušetří na nákladech na vývoj i správu. Což je důležité třeba v okamžiku, když se vůbec neví, jestli ten projekt uspěje.

Kdo?

Ten, kdo to po nich chce.

Třicet let pravicové strany lidi přesvědčují, že na státu je potřeba hlavně šetřit.

Politiku sem netahejme. A ono je šetřit a šetřit. Můžu zrušit 80% všech úřadů, optimalizovat počet lidí na těch 20% zbývajících a dát jim větší plat. Celkově se velmi výrazně ušetřilo, ti lidé mají lepší peníze a občané lepší služby. Takže ono mávat s praporem "oni chtěli ušetřit a proto je to rozbité" samo o sobě nedává žádnou odpověď na to, proč je to rozbité.

No tak se šetří a pak máme takovéhoto nejvyššího státního úředníka, který není schopen odpovědět na cokoli z jeho oboru

To už jsme ale doslova na hranici psychiatrické diagnózy. Pokud někdo není schopen ani interpretovat dokument, který mu někdo jiný předložil (protože zrovna tohle bylo na úrovni EU), tak o čem se jako chceš bavit. Tohle vůbec není o penězích. Kdyby do toho pořadu šel někdo z ulice Vinohradská a ten by dostal hodinu před tím do ruky papír, tak je schopen odpovědět lépe, než úředník, který to měl x let na starosti.

No jo, ale on už ten projekt možná nikdo nebude chtít psát v PHP, ale třeba v JavaScriptu, Go nebo Javě.

A tohle nějak koliduje s tím, co jsem psal? Prostě si tým vybere komponenty/jazyky, se kterými všichni umějí pracovat, pro nikoho to nebude překvapení a všichni budou vědět, kde to má limity apod. Přesně tohle jsem napsal.

A možná dokonce usoudí, že na uložení dat je vhodnější něco jiného, než relační databáze.

To se klidně může stát, ale opět to vůbec nijak s ničím nekoliduje.

Já osobně, soukromě, postgresql taky nepoužívám zrovna akademicky správně. Já jej používám více méně jako key-value db s výhodou datových typů a s výhodou sql. A to pro to, že uložit v roce 2006 na disk 300milionů souborů nešlo a pro DB (tehdy MySQL) to byla absolutní hračka. Takže v PG mám několik TB dat a skoro miliardu záznamů a ano, jistě by nějaký analytik našel mnohem lepší a mnohem výhodnější projekt. Ale o to právě jde. Že ten PG to zvládne tak dobře, že zrovna tuhle komponentu vůbec nemusím řešit a po pravdě o ní vlastně ani nevím. A o tohle mi jde nejvíc. Mě je celkem jedno, jestli je k disposici vhodnější nástroj, který bude o 50% rychlejší. Stejně čekám na HW, takže optimalizace SW mě vůbec netankuje. A ano, až budu mít problém vytížit nvme úložiště, tak se možná podívám po jiném projektu, ale zcela upřímně vůbec nevím, v jaké situaci bych musel řešit desítky GB/s u tohoto projektu.

Takže pokud v tom "zastaralém" projektu se použije postgresql místo něčeho, tak jako v čem to vadí? Jako v čem? Stejně to čeká na disky.

Ten, kdo to po nich chce.
Ale on to po nich nikdo nechce. Pro úředníka je jednodušší přidat do zadávací dokumentace další devítku než něco vysvětlovat občanům. A pro politika nakonec taky. Měli by to chtít občané – ale ti se přece nenechají někým poučovat, sami ví všechno nejlíp.

Politiku sem netahejme.
Jenže když píšeš o veřejných institucích, ty politika ovlivňuje zásadně.

Můžu zrušit 80% všech úřadů, optimalizovat počet lidí na těch 20% zbývajících a dát jim větší plat. Celkově se velmi výrazně ušetřilo, ti lidé mají lepší peníze a občané lepší služby.
Nemůžeš, protože nevíš kterých 80 % můžeš zrušit a jak služby zlepšit. Musíš nejprve investovat do lepších služeb a kvalifikovanějších lidí, a ti pak teprve mohou řešit, co a jak zefektivnit.

Snad každý chápe, že firma musí nejprve investovat, aby díky té investici mohla něco dělat lépe. Zvláštní je, kolik lidí si myslí, že u státu to půjde bez té investice.

Takže ono mávat s praporem "oni chtěli ušetřit a proto je to rozbité" samo o sobě nedává žádnou odpověď na to, proč je to rozbité.
No, vlastně dává. Pokud je dlouhodobě na prvním místě jenom snaha ušetřit, vždycky se to rozbije. Na to není potřeba jiná odpověď. Pokud chceme, aby bylo něco funkční, musí být požadavek na funkčnost na prvním místě.

Tohle vůbec není o penězích.
A o čem to teda je?

Prostě si tým vybere komponenty/jazyky, se kterými všichni umějí pracovat, pro nikoho to nebude překvapení a všichni budou vědět, kde to má limity apod.
Takže ten tým nikdy nepoužije žádnou novou technologii, nikdy neudělá žádnou větší aplikaci, než dělal dříve? To se obávám, že místo něj brzy začne dostávat zakázky jiný tým, který si troufne i na věci, které ještě nedělal.

Ale o to právě jde. Že ten PG to zvládne tak dobře, že zrovna tuhle komponentu vůbec nemusím řešit a po pravdě o ní vlastně ani nevím. A o tohle mi jde nejvíc.
Ano, o to právě jde. Že v praxi se řeší poměr cena/výkon, a ne to, aby bylo vše naprosto ideální a podle příruček. Takže někdo uloží do databáze 300 milionů souborů, protože to v době vzniku bylo nejefektivnější řešení, a někdo má v systemd nastavený Restart, protože je to to nejrychlejší, co se dá s aplikačním serverem udělat, když jeho proces umře. Neplyne z toho ani že tam není žádný monitoring služeb, ani že se ten Restart někdy uplatní v praxi.

Takže pokud v tom "zastaralém" projektu se použije postgresql místo něčeho, tak jako v čem to vadí? Jako v čem? Stejně to čeká na disky.
Třeba v tom, že kdyby se použilo něco jiného, nemusí to na disky čekat. Nebo v tom, že tu aplikaci musíš odstavit, když budeš chtít aktualizovat databázový stroj. Nebo v tom, že se s tím bude těžko řešit distribuovanost po celém světě.

To neznamená, že by nebyla spousta úloh, kde je PostgreSQL skvělá volba. Je. Ale jsou úlohy, kdy jsou lepší řešení než PostgreSQL. A snažit se všechno ohnout do toho, co už znám, znamená, že už se nikdy nenaučím nic nového a buď budu některé úlohy řešit neefektivně nebo nakonec budu řešit jenom takové úlohy, ke kterým se hodí nástroje, které znám.

Ale on to po nich nikdo nechce.

Stát po občanech chce, aby se někam přihlásili. Nebavím se o devítkách, bavím se o povinnosti občana použít nějaký nástroj.

Nemůžeš, protože nevíš kterých 80 % můžeš zrušit a jak služby zlepšit. Musíš nejprve investovat do lepších služeb a kvalifikovanějších lidí, a ti pak teprve mohou řešit, co a jak zefektivnit.

Tohle je jak z Jistě, pane ministře...

Snad každý chápe, že firma musí nejprve investovat, aby díky té investici mohla něco dělat lépe. Zvláštní je, kolik lidí si myslí, že u státu to půjde bez té investice.

Otázkou je, co myslíš tou investicí. Z mě není moc potřeba lít někam peníze, ale spíše pozitivně motivovat lidi, aby přišli s nápadem. Ti lidi ty nápady mají, a to, že tu věc dělají "blbě" má svůj důvod. Velmi často vědí, že to dělají blbě a často to dělají blbě právě proto, aby si toho někdo všiml a nebo čistě jen proto, že si toho roky nikdo nevšiml (což je takový bezmocný trolling).

A ono nalít někam peníze, když to vedení vlastně vůbec neví, kde je problém a problém je třeba právě v tom, že vůbec nikdo nikdy nedal hlas těm zaměstnancům velmi často znamená doslova vyhozené peníze. Protože ti zaměstnanci vědí, že vedení něco řeší a proč to řeší a tak to budou šikovně bojkotovat.

A o čem to teda je?

V tom, že je to doslova všem jedno. Úplně všem je jedno, že NEN stál miliardu a měl roky zpoždění. Nikdo nebyl vyhozenej, nikdo nesedí ve vězení, Michal Bláha si na tom udělal kariéru a dneska obhajuje v TV šlendrián v podobě přijímaček apod. Takže pohoda, ne? Před lety odstřeloval jeden průser z pozice neziskovky Hlídač Státu, dneska obhajuje jiný průser z pozice poradce vládní strany. Takže pohodička. Daňový poplatníci někomu do kapsy věnovali miliardu, někdo možná ponížil, někdo povýšil, takže pohodička, žádný stres.

Stejně tak ten GDPR. Nějaký úředník blábolil v rozhlase, pohodička, žádný stres, vážení podnikatelé, zajděte si na školení, raději třeba na 10 ať se o tom něco dozvíte. S pozdravem, Vaše státní správa která tady vůbec není od toho, aby vám cokoliv vysvětlovala. A už vůbec ne to, co od vás bude požadovat.

Takže ten tým nikdy nepoužije žádnou novou technologii, nikdy neudělá žádnou větší aplikaci, než dělal dříve?

Právě naopak. Tím, že používá komponenty, které velmi dobře zná, si potom může troufnout na náročnější projekt.

Neplyne z toho ani že tam není žádný monitoring služeb, ani že se ten Restart někdy uplatní v praxi.

To samozřejmě neplyne. Uvidíme za pár let. Třeba s těch projektů něco bude. Ehm, pokud tedy nezmění licence a nebo se nenechají koupit.

Třeba v tom, že kdyby se použilo něco jiného, nemusí to na disky čekat. Nebo v tom, že tu aplikaci musíš odstavit, když budeš chtít aktualizovat databázový stroj. Nebo v tom, že se s tím bude těžko řešit distribuovanost po celém světě.

S tebou se fakt nedá diskutovat. Ty jsi schopen v diskusi o formuli 1 diskutovat o tom, že se s tím špatně orá pole.

Ok, tak pro ostatní. V tomhle případě je uložení na disk základ. Cílem je mít data bezpečně uložená, ošetřená nějakými součty a zajištěná referenční integrita. Tohle je absolutní základ. Cílem není mít distribuovanou db po celém světě.

A snažit se všechno ohnout do toho, co už znám, znamená, že už se nikdy nenaučím nic nového a buď budu některé úlohy řešit neefektivně nebo nakonec budu řešit jenom takové úlohy, ke kterým se hodí nástroje, které znám.

Tak ono to taky trochu záleží, co děláš za reálnou práci. Já se neustále pohybuju v oblasti, kde je prioritou mít data správná, ošetřená z mnoha úhlů a bezpečně uložená. Vyzkoušel jsem mnoho jiných "DB" a u mnoha z nich jsem se s autory neshodnul na tom, že hlavním účelem DB je ochrana a uložení dat. Oni to velmi často viděli jinak a bezpečné uložení dat pro ně mělo dost nízkou prioritu. Ale jistě se i tyhle produkty v reálu používají. Je mnoho oblastí, kde hlavním cílem je data ztrácet.

Nebavím se o devítkách, bavím se o povinnosti občana použít nějaký nástroj.
Nebavíme se o povinnosti, ale o možnosti. Z všeobecných služeb je povinné jen elektronické podání daňového přiznání, pokud máte datovou schránku. Pak už jsou to jen různé okrajové věci jako různé žádosti o dotace apod., kde už je sporné i to použití slova „povinnost“.

Tohle je jak z Jistě, pane ministře...
To jsou normální ekonomické principy. Kdyby fungovalo ekonomické perpetuum mobile, že něco získám bez předchozí investice, s radostí by to používal i komerční sektor.

Z mě není moc potřeba lít někam peníze, ale spíše pozitivně motivovat lidi, aby přišli s nápadem.
Peníze jsou docela dobrá pozitivní motivace. Další motivace, proč přijít s nápadem, je třeba vize, že se ten nápad zrealizuje. A ne že budou proti lidé na daném úřadě, úřady okolo i veřejnost. („Stát má šetřit a místo toho tady vymýšlí něco nového.“)

A ono nalít někam peníze, když to vedení vlastně vůbec neví, kde je problém a problém je třeba právě v tom, že vůbec nikdo nikdy nedal hlas těm zaměstnancům velmi často znamená doslova vyhozené peníze.
Jenže bez peněz to nepůjde. Ano, je dobré, když tam je někdo, kdo ví, co s těmi penězi udělat. Ale zkušenosti z různých zemí a oborů ukazují, že vlastně opravdu stačí přidat peníze lidem. Protože to zvýší konkurenceschopnost a přitáhne lidi, kteří chtějí a umí něco změnit. Takže už tam není jen pár srdcařů, kteří jsou na to sami, ale mají k sobě další lidi, se kterými se mohou spojit.

V tom, že je to doslova všem jedno. Úplně všem je jedno, že NEN stál miliardu a měl roky zpoždění.
No ano, všem je to jedno, protože bylo splněno zadání. Zadání bylo vybrat ve VŘ nejlevnějšího dodavatele, a to bylo splněno. Že bylo špatně zadání? Že bylo špatně řízení projektu? To nikoho nezajímá, to jsou věci týkající se fungování státu, a funkční stát tu nikoho nezajímá. Naopak, když se někde ukáže nějaký daňový podvod nebo třeba porušení dopravních předpisů, spousta lidí to oslavuje, jak je to super, když je stát nefunkční a není schopen zákony vymáhat.

Tím, že používá komponenty, které velmi dobře zná, si potom může troufnout na náročnější projekt.
Nemůže. Protože ten projekt by vyžadoval jiné komponenty, nebo jiný způsob použití těch stávajících komponent.

Ty jsi schopen v diskusi o formuli 1 diskutovat o tom, že se s tím špatně orá pole.
Jenže my se nebavíme o formuli 1. Bavíme se o pozemních dopravních prostředích. Na něco je lepší formule 1 a na něco je lepší traktor.

Cílem není mít distribuovanou db po celém světě.
No jak u kterého projektu. Za celou dobu jsi nenapsal, že by byla řeč o jednom konkrétním projektu. Teď jsi poprvé zmínil NEN – a tam bych viděl hlavní problém v zadání, použité technologie jsou až někde daleko za tím.

Já se neustále pohybuju v oblasti, kde je prioritou mít data správná, ošetřená z mnoha úhlů a bezpečně uložená.
Já se pohybuju v oblasti, kde pro drtivou většinu dat platí to samé. Ale jsou tam i data, u kterých je prioritou rychlý přístup a bezpečné uložení není potřeba řešit, protože se dají snadno vyrobit znovu. Nebo v jiné oblasti, kde je prioritou nízká cena, rychlý a nárazový přístup – a bezpečnost uložení nikoho nezajímá, protože ta data jsou druhý den nezajímavá. Zkrátka požadavky jsou různé a tomu odpovídá i volba nástrojů, a také volba toho, zda má proces po pádu znovu sám nastartovat nebo ne.

To jsou normální ekonomické principy.

Jasně. Ale současně to zní jako bezvadná dojná kráva na rozpočet. Máme blbý a drahý stav. Abychom zjistili, v čem je to blbé (jako kdyby to nikdo nevěděl), nalijeme do toho další peníze. Výsledek je, že máme blbý a ještě dražší stav. A tohle kolečko se dá opakovat až do zkrachování státu. Takže ano, je to ekonomický princip. V tom máš pravdu. Ale současně ty peníze je potřeba použít účelně a očekávat jasný výsledek v jasném termínu. A tohle posledních 30 let chybí.

Nemůže. Protože ten projekt by vyžadoval jiné komponenty, nebo jiný způsob použití těch stávajících komponent.

Takže v podstatě říkáš, že všechny komponenty jsou pouze na jedno použití a pouze pro jeden projekt. :-D

Teď jsi poprvé zmínil NEN

Jo, ale ten můj soukromý příklad nebyl vůbec směrem k NENu ani nic podobného. Pro mě osobně je DB především o konzistenci, ochraně, datové správnosti uložených dat. Bez ohledu na projekt. A možná mi něco doporučíš, pro mě je PG o tomhle všem. Mám bezpečně uložená data. Mám dokonce datové typy a PG (na rozdíl od jiných DB) mě nenechá uložit do sloupce INT TEXT. Jiným DB je to zcela jedno a mají k tomu i vysvětlení v dokumentaci (SQLite). Automaticky zapnutou referenční integritu (SQLite opět vypnuté, lze zapnout; v MySQL dle storage engine a podle počasí) a tak dále. Zmiňoval jsem to Mongo. Měl jsem to v TODO, potom jsem zjistil, že je to více méně jen storage engine pro JS a tedy všech důsledků z toho plynoucích (více méně vše je string, na data vám kašleme) a navíc to má jen 16M na záznam, což je pro mě v tom soukromém projektu už zcela nepoužitelné.

A klidně to napíšu znovu, jistě a nepochybně existuje pro 20 různých použití 20 lepších a úžeji zaměřených DB. Ale PG to zvládne. Jistě, v některých projektech mám taky všechno string, takže datové typy v PG se v tomto projektu nepoužijou. Ale je to jedno. Jistě, také to někde zneužívám jako temporary cache. Ale je to jedno. Ono to prostě funguje.

A ono je to také o nějakém profesionálním přístupu. Viděl jsem projekty, kde to bylo doslova na procenta výkonu. Ano, tam by PG asi nejspíš neobstál, ale současně, jaký je přesně důvod mít HW dimenzován doslova na 99% požadovaného výkonu, když za "jeden dolar", by vytížení mohlo být klidně 5%. Já bych, jakožto zodpovědný pracovník, teda moc dobře nespal. Já chci mít mnohem větší prostor než 1%. A taky současně mám určitou morálku, takže projekt, který je nutné osekat na pár centů bych rozhodně nedělal. Až budu mít takto pokleslou morálku, tak rovnou můžu jít vyrábět drogy nebo zbraně a vydělám si víc, než osekávat cosi o jeden dolar.

prioritou rychlý přístup a bezpečné uložení není potřeba řešit, protože se dají snadno vyrobit znovu

Tomuhle říkám cache a ne db.

Ale současně ty peníze je potřeba použít účelně a očekávat jasný výsledek v jasném termínu. A tohle posledních 30 let chybí.
Chybí to, protože to posledních 30 let skoro nikdo nechce. Protože spousta lidí po státu chce jenom to, aby šetřil, další aby jim platil, a mnozí obojí.

Takže v podstatě říkáš, že všechny komponenty jsou pouze na jedno použití a pouze pro jeden projekt. :-D
Neříkám. Já jsem neříkal, že tým nemůže dělat i na projektech, kde použije jenom to, co dobře zná. Psal jsem, že kdyby dělal jenom na takových projektech, nikdy se neposune nikam dál a nenaučí se používat nové technologie nebo stávající technologie jiným způsobem.

Ono to prostě funguje.
Stejně tak v některých případech prostě funguje použít Restart v systemd jednotce. Přestože by se určitě také našlo 20 jiných způsobů, jak docílit restartu procesu, když z jakéhokoli důvodu skončí.

Přestože by se určitě také našlo 20 jiných způsobů, jak docílit restartu procesu, když z jakéhokoli důvodu skončí.

Jenže tohle nebylo potřeba. Do příchodu systemd to bylo k disposici, ale nebylo to vystavováno a tak to skoro nikdo nepoužíval. Tohle je funkce, která nemá mít reklamu. Ale to už jsem psal před 10 lety. Mezitím, od roku 2015 na FreeBSD pochopitelně bez systemd mi, stejně jako na Linuxu, některé služby nikdy nespadly. Tedy to rozhodně není tak nutná funkce, jak se to snažíš stavět. Jestli ti padá webserver poskytující statický obsah, tak s tím webserverem je něco hodně špatně. A to i za stavu, že je zcela bezpečné jej restartovat. Atd. Fakt nemá smysl recyklovat 10 let starou diskusi.

Já neříkám, že je to funkce nutná. Ostatně nutné nejsou ani init skripty, klidně je možné jako PID 1 spustit jeden dlouhý shell skript, který všechno nastartuje. Nevím, jak by sis představoval, že to nebude mít reklamu – prostě je to jeden z mnoha parametrů, který je jako všechny ostatní parametry zdokumentován. Podobně jako třeba parametry pro spuštění pod nějakým uživatelem. To by také nemělo být potřeba, ideální aplikace přece nebude nebude nijak škodit, když poběží pod rootem, i když ta práva nepotřebuje. Přesto radši služby nespouštím pod rootem, pokud to není nutné. A stejně jako použití Restart neimplikuje, že se ta aplikace někdy restartuje, tak použití User/Group neimplikuje, že ta aplikace je děravá a kdyby běžela pod rootem, bylo by možné ji zneužít.

Věřím, že rozdíl mezi „může nastat“ a „nastává“ chápeš a zaměňuješ je jenom v zápalu diskuse.

Nevím, jak by sis představoval, že to nebude mít reklamu

Bylo to doslova v každém článku. Ani ses nedozvěděl, jak správně nastavit závislosti mezi službami, ale už v druhém odstavci jsi se dozvěděl, že tu službu můžeš nechat restartovat.

To, že je to v dokumentaci je samozřejmě v pořádku. V popularizačním článku se máš dozvědět o důležitých funkcích a u těch dalších by ses měl dozvědět, k čemu jsou a k čemu rozhodně nejsou a kdy je jejich použití vyloženě nevhodné a nebezpečné. (A ne nebudu psát, že by to měla kontrolovat redakce. Nepodařilo se mi to prosadit ani na vnitrofiremním LinuxExpresu, ani na AbcLinuxu, takže nepředpokládám, že by to prošlo tady.)

To by také nemělo být potřeba, ideální aplikace přece nebude nebude nijak škodit, když poběží pod rootem, i když ta práva nepotřebuje.

Právě naopak, tohle je základ bezpečnosti. Nikoliv pro to, že by ta služba byla a priori škodlivá (autor by chtěl škodit). Ale proto, že ta služba vůbec nemusí implementovat něco jako správu uživatelů, protože její správné použití je pouze v kontextu daného uživatele. Tedy toto ušetří náklady na vývoj. Tedy vhodným oddělením uživatelů se ušetří vývoj, zvýší bezpečnost, protože je to implementováno na velmi hlídaném místě v kernelu.

A stejně jako použití Restart neimplikuje, že se ta aplikace někdy restartuje

Ano, ale je rozdíl, který ty 10 let ignoruješ. Ten rozdíl je v tom, jestli je ten restart dán jako třešnička na dortu u služby, která byla milion kumulativních let testována na 10000 konfiguracích a vůbec nikdy nespadla - v tomto případě nemám vůbec žádný problém s restartem, který se nikdy nepoužije a dá se to nastavení považovat spíše za easter egg.

Ale realita je přesně opačná. A psal jsem ti to už tehdy. Ten restart se používá u služeb, které padají doslova každou půl hodinu. Tým je evidentně neschopný napsat něco funkčního, takže se tam dá restart always. Viděl jsem to. Tu službu jsem odmítal dál nasazovat, upozorňoval jsem na to, že to bude problém a bylo mi důrazně doporučeno tam dát prostě restart a víc se o to nestarat. Potom v logu stovky restartů za den. Gratulujeme.

Ale proto, že ta služba vůbec nemusí implementovat něco jako správu uživatelů, protože její správné použití je pouze v kontextu daného uživatele. Tedy toto ušetří náklady na vývoj. Tedy vhodným oddělením uživatelů se ušetří vývoj, zvýší bezpečnost, protože je to implementováno na velmi hlídaném místě v kernelu.
Stejně je to může být i s tím restartem. I ten se dá využít smysluplně a může to ušetřit náklady na vývoj.

Ten restart se používá u služeb, které padají doslova každou půl hodinu. Tým je evidentně neschopný napsat něco funkčního, takže se tam dá restart always. Viděl jsem to.
To je ovšem problém tvého týmu, ne problém systemd.

Stejně je to může být i s tím restartem. I ten se dá využít smysluplně a může to ušetřit náklady na vývoj.

Jako že: "hmm, přišel divný packet, raději spadnu s exit code 255 a nechám se restartovat? Místo jednoho ifu? No to fakt ušetří miliardy...

To je ovšem problém tvého týmu, ne problém systemd.

Tu konkrétní službu rozhodně nevyvinul můj tým, ta je normálně v distribuci. Já ti jenom 10 let popisuju (marně), jak to v tom týmu probíhá.

ne problém systemd

Tohle je mimochodem stejné jako v autoškole. Pokud někomu "zatajíš" existenci všech asistentů, tak si bude dávat pozor na každou značku, člověka, psa apod. Bude dávat u řízení pozor. Ano, potom jednou za 10 let ho nějaký asistent zachrání.

Pokud někomu od první hodiny budeš vysvětlovat, že tam má jízdu v pruzích, front asistent, parkovací asistent, abs apod. tak se rozseká v první křižovatce po získání řidičáku. Protože ten asistent zrovna selhal.

A přesně takto vypadají ty služby. Pokud někdo od roku 2010 spoléhá na restart always, tak ta služba podle toho taky vypadá.

"zatímco by stačilo koupit obyčejný server za půl mega"

...
Ale ne ... nekdy zacatkem 90', vypocet mezd. Pro cca 250 zamestnancu ... na i386 s nevim ... 1/2MB ram tam urcite nebylo a 40MB disk. Davalo to rekneme 30 lidi za hodinu.

Soucasnost ... SQL server s 128GB ram, cca 1/2TB dat na disku, 16 jader +- 5GHz, fullssd pole, + aplikacni server ... a dava to cca 60 lidi za hodinu. Lol ...

Nekdy zacatkem 90' ale ta i386 stala taky... ranec penez. Navic ono i hodnota koruny se v case meni... takze po prepoctu na dnesni ceny na tom pulmilionu klidne budete.

A co se vypoctu mezd tyce - ona se v case krom jineho i meni (komplikuje) legislativa, takze i samotny vypocet je slozitejsi. A zamozrejme se muzeme bavit o tom, jak moc je ten software pricetne napsany. Z toho, ze tu sermujete gigabajty RAM a storage a poctem jader jeste nejde dovozovat, ze software ty hardwarove zdroje umi opravdu pouzit. Aneb taky se muze treba stat, ze vam to pocita na jednom jadre, ze? :-) A nebo si to treba ani vic pameti proste nevezme, protoze pouziva nejake frikulinske socka reseni ala Oracle XE, bo "cesky chytrolin" chtel usetrit na licencich, ale nutne potreboval Oracle DB.

"Tohle je dost subjektivní. Fascinují mě lidé, kteří nejdřív podepíšou nějaká pravidla a potom se diví, že podle těch pravidel něco nejde."

Jenže ta pravidla se mění. Jeden z problému třeba přinesla potřeba lepšího zabezpečení a vznik selinuxu. On totiž kernel jaksi sleduje cestu spuštění daného procesu a nastavuje podle ní práva.

A init -> sysV skripty -> httpd byla jiná cesta než ssh -> bash -> service httpd start -> sysV skripty -> httpd.

Správce procesů to řeší. Poslouchá příkazy uživatele na vedlejším kanále (třeba dbus) a zajistí, že cesta spuštění je vždy a v obou případech init -> httpd.

Nemůžu si pomoct, ale přístup „provozuju jenom služby, které my ani jednou nespadly“ je podle mne stejně zvrácený, jen s opačným znaménkem

No to jsem si v diskusích všiml, ale vůbec nechápu proč. Jestli je cílem někoho nonstop konfigurovat server, tak OK, jenomže to taky znamená, že ten server nefunguje pro produkci
(zákazníky). Pro mě je mnohem lepší používat nástroje typu "nainstaluj a zapomeň". A pro zákazníka taky, protože ta věc běží nonstop 4 roky, které to má (třeba ze zákona) běžet. Zákazníci jsou happy, já jsem happy.

To se ovšem nevylučuje s tím, co dělám doba. Doma mám bleading edge unstable freebsd a třeba 3x do týdne rekompiluju nějaký balíček, protože mě to baví. Tohle ale na produkčním serveru nemá co dělat.

Až pak teda přišel někdo s tím, že když nástroj pro konfiguraci sítě má být složitější, než čtyři řádky volající přímo ip, musí ten nástroj také poskytovat nějaké služby navíc.

Psal jsem to už do komentáře níže. Ten nástroj musí fungovat. Je úplně jedno, jestli je napsaný v shellu nebo Rustu, je jedno, jestli má tisíc grafů a monitoring běží i na android hodinkách. Pokud selže u správy sítě, tak jde na black list.

No to jsem si v diskusích všiml, ale vůbec nechápu proč.
Třeba proto, že kdybys ten přístup opravdu uplatňoval, tak kdyby ti jednou spadl nginx, třeba kvůli vadné paměti, nahradíš ho nějakým experimentálním serverem v alfa verzi – protože ten ti ještě nespadl.

Pro mě je mnohem lepší používat nástroje typu "nainstaluj a zapomeň".
To pro mne také. A součástí toho „zapomeň“ je pro mne i ošetření možných problémových stavů. Třeba nastavení zálohování a monitoringu zálohování. Nebo nastavení toho, co se má stát, když proces skončí.

To se ovšem nevylučuje s tím, co dělám doba. Doma mám bleading edge unstable freebsd a třeba 3x do týdne rekompiluju nějaký balíček, protože mě to baví. Tohle ale na produkčním serveru nemá co dělat.
Je možné provozovat systemd i na neprodukčním serveru? Já se domnívám, že tomu nic nebrání – a že je tudíž v debatě o vlastnostech systemd irelevantní, jestli jde o produkční nebo neprodukční server. Zkrátka se na produkčním serveru některé vlastnosti nepoužijí.

Psal jsem to už do komentáře níže. Ten nástroj musí fungovat. Je úplně jedno, jestli je napsaný v shellu nebo Rustu, je jedno, jestli má tisíc grafů a monitoring běží i na android hodinkách. Pokud selže u správy sítě, tak jde na black list.
To bych musel dát na blacklist i ty distribuční shellové skripty.

třeba kvůli vadné paměti

Proč bych měl kvůli vadné paměti nahrazovat nginx? Ty jsi úplně mimo. Pokud má server vadnou paměť a třeba i spadne, tak to vidím na monitoringu serveru. A - tvoje oblíbená věta - ještě se mi to nestalo. Několikrát si server stěžoval na ECC chybu paměti, stačilo ve vmware kliknout na maintenance, vmka se odstěhovala na jiné servery a tento HW byl vyměněn. Takže ten nginx dokonce ani nespadl. A dokonce si ani nevšiml vadné paměti.

Nebo nastavení toho, co se má stát, když proces skončí.

Psal jsem ti tady příklad s autoškolou. S tímhle bez kontextu nemám žádný problém. Ale mám problém s tím, pokud někdo restart procesu používá jako zcela standardní metodu řešení problémů. A mám stejný problém s řidiči, kteří spoléhají na front assist. Protože tihle velice rychle narazí do zadku auta, protože ten front assist v jednom z 10 tisíc případů selhal. Takže tihle řidiči nabourají hned první den po autoškole.

To bych musel dát na blacklist i ty distribuční shellové skripty.

No však ano, však tohle kritizuju i v této diskusi. Místo ifcfg-eth, což nefunguje, máme NM, který nefunguje. To jsme si pomohli, že?

Proč bych měl kvůli vadné paměti nahrazovat nginx?
Protože říkáš, že když jakýkoli program spadne, je to chyba programu a nebudeš ho používat. Já jsem přesvědčen, že to tak nemyslíš, ale celou dobu to píšeš – tak když na tom trváš, beru to tak, že je to opravdu tvůj postoj.

No však ano, však tohle kritizuju i v této diskusi. Místo ifcfg-eth, což nefunguje, máme NM, který nefunguje. To jsme si pomohli, že?
Možná je na čase začít rozlišovat, jak moc něco nefunguje. A pokud chceš tvrdit, že používáš jenom programy, které fungují – žádný program není ideální a bezvadný. Ani TeX. Takže je potřeba rozlišovat, jestli něco funguje lépe či hůře.

Takže je potřeba rozlišovat, jestli něco funguje lépe či hůře.

Výborně. Takže se někam dostáváme.

Příkladem budiž nástroje lvm nebo mdadm. Tyhle nástroje, pokud něco bez řečí povolí udělat, tak je to vždy bezpečné. Pokud se jim něco nelíbí, tak se interaktivně zeptají a nebo vyžadují speciální a velmi dlouhý parametr příkazové řádky. Tohle je zcela v pořádku. I kdyby v těch programech byl jen hloupý seznam bezpečných akcí a na zbytek by vyžadoval extra potvrzení, tak je to v pořádku. Dává vám na vědomí, že to co děláte, může být nebezpečné.

Vedle toho NM, který zcela evidentně vůbec nekontroluje konfiguraci sítě. Fajn ok. Tak proč jej mám použít? Že má API? To těch 200 dalších nástrojů také. Kde je teda ta výhoda? Tohle totiž potom vede k tomu xkcd vtipu o N+1 standardech.

A tohle mimochodem kritizuju i v té debatě o DB. Pokud si tu DB spíchnu za víkend, tak se o ten nabízený produkt vůbec nemusím zajímat. Pokud jsem schopen si za víkend udělat API na nastavení sítě v linuxu, tak jsem právě jednak vytvořil N+první standard, ale hlavně, mě těch N standardů vůbec nemusí zajímat. A pokud někdo (neříkám že ty) kritizuje roztříštěnost linuxu, tak přesně tohle je ten důvod. Pokud mi někdo nabízí nástroj, který jsem schopen sám vyrobit (viz ten Monit, nebo network api), tak je ten nástroj zcela zbytečný a vůbec se o něm nemusíme bavit.

Takže, pokud ode mne nástroj vyžaduje naučit se jinou syntax ( nmcli) nebo rovnou API, tak mi současně musí nabídnout nějakou výhodu. Ale ono to nakonec dopadlo tak, že abych teda mohl správně použít NM, tak jednak musím znát způsob nastavení sítě v linuxu (a tedy znát ip), musím znát syntaxe nebo api nástroje nm, musím vědět o všech jeho "vlastnostech" a musím jej správně použít. Pardon, pokud tohle nástroj požaduje, tak vůbec nemá právo na existenci. Proč se mám učit nástroj nm, syntax nmcli, nebo si psát python skripty, když to co chci je ve výsledku mnohem jednodušší udělat v shell skriptu pomocí ip? Teď jsem si zahrál na ďáblova advokáta, ale myslím to zcela vážně. Tohle je názorná ukázka toho, kdy je ten shell skript ta nejsprávnější možnost, protože ty nástroje jsou hnůj.

Až bude v roce 3251 existovat nástroj, který, stejně jako mdadm v roce 2010, zkontroluje vstup od uživatele a aktuální stav nastavení sítě, tak teprve pak přestaneme viděl ip příkazy v náhodných skriptech.

Přiznám se, že tam teď úplně nevidím souvis se systemd.

To nesouvisí se systemd. Mě prostě fascinuje, jak někteří lidé říkali, že se nebudou učit nic jiného než předchozí rc-v. OK, v pořádku. Ale potom se podíváš na jejich servery a tam je bastl daemontools a dalších. Prostě pokud někomu vyhovují rc skripty (což v diskusích tvrdí), tak má všechno dělat v rc skriptech. Tedy ta jejich nenávist nebyla vůči systemd, ale vlastně vůči všemu, protože byli schopni se naučit pouze jeden nástroj (třeba daemontools) a potom to bastlili hlava nehlava do předchozích rc systémů.

Ty tři zmíněné jsou jen příklady, a ani jeden nemá za cíl nahrazovat (lowlevel) příkaz ip z iproute2.

To já vím.

NetworkManager má dbus api, a dá se ovládat jak příkazem nmcli z shellu, tak přes ncurses nmtui, tak třeba z nějakého desktop ovládacího programu, webového rozhraní, nebo třeba python skriptu pro nějakou automatizaci při větším množství ifaců.

Super. Skvělé. Ale za mě, bod 0 - musí to nejdřív fungovat. Mě opravdu nezajímá, kolik má nástroj možností, pokud vůbec nefunguje. A jestli v roce 2021 na čistě nainstalovaný aktuální CentOS, dle návodu nastavím síť v NM a při páté statické routě mě to odpojí od sítě, tak pardon pánové, opravte to. Nástroj je od toho, aby mě kontroloval. Pokud jsem někde udělal chybu (ať už omylem, nebo záměrně jako tester), ten nástroj mě na to má upozornit. A jestli tohle není (podle někoho) funkce toho nástroje, tak pardon, vůbec jej nemusím používat a stačí mi ty 4 ip příkazy v náhodném skriptu. Pokud chcete takto pracovat, tak já se rád přizpůsobím.

A tohle mě na aktuálním IT štve. Všichni se chlubí, kolik to má grafů, kolik to má funkcí, jak je to pěkné a jaké bonusové funkce si můžete dokoupit, ale ve výsledku se na to stačí špatně podívat a ono to spadne.

Mě prostě fascinuje, jak někteří lidé říkali, že se nebudou učit nic jiného než předchozí rc-v. OK, v pořádku. Ale potom se podíváš na jejich servery a tam je bastl daemontools a dalších. Prostě pokud někomu vyhovují rc skripty (což v diskusích tvrdí), tak má všechno dělat v rc skriptech.

OK. díky za vysvětlení, to určitě souhlasím. ;)

Super. Skvělé. Ale za mě, bod 0 - musí to nejdřív fungovat. Mě opravdu nezajímá, kolik má nástroj možností, pokud vůbec nefunguje. A jestli v roce 2021 na čistě nainstalovaný aktuální CentOS, dle návodu nastavím síť v NM a při páté statické routě mě to odpojí od sítě, tak pardon pánové, opravte to. Nástroj je od toho, aby mě kontroloval. Pokud jsem někde udělal chybu (ať už omylem, nebo záměrně jako tester), ten nástroj mě na to má upozornit. A jestli tohle není (podle někoho) funkce toho nástroje, tak pardon, vůbec jej nemusím používat a stačí mi ty 4 ip příkazy v náhodném skriptu.

Tak jo, možná jsi narazil na specifický bug. A beru, někdy to fakt může být ta poslední kapka, než to člověk vzdá. Já jsem psal o těch fíčurách proto, že tím jak to dělá abstraktní vrstvu nad různými síťovými subsystémy, vpn klienty a má to API pro další ovl. software, řeší to stavovou logiku, delegování práv, logování, profily atp., tak to nemá úplně moc ekvivalentů. To, co to nabízí, prostě nepokryji jen shell skripty, krom nejjednodušších případů. Přecházel jsem na NM postupně - nejdřív logicky na desktopech, kde tyhle dynamické konfigurace byly třeba nejvíc (WiFi, VPN) a postupně i na serverech, kde můžou být také i relativně složitější nastavení, různé failovery, dynamické bridge na virtuály, tunely atp.
Na začátku, když NM začínal v těch větších distr., jsem to při výskytu problému také vzdával (hlavně pod vlivem různých návodů, kde bylo na úvod napsáno - NM je na <|>, vypněte tu službu a obejděte to), ale pak když jsem dělal víc instalací RHEL/CentOS 7, tak jsem tomu zkusil přijít na kloub a nastavoval pak víceméně vše, co šlo, v NM.
Takže mě subjektivně to nepřijde, že by to vůbec nefungovalo. Ale možná mám jen vyšší práh citlivosti :) A samozřejmě, je to relativně komplexní projekt s tím, co všechno to řeší, mohou tam být chyby. Navíc tam mohou být rozšíření mimo ten hlavní projekt (typicky VPN klienty třetích stran), která nemusí být úplně v pohodě, udržovaná atd.

Jinak k té konkrétní věci. Snad jsem to pochopil dobře, a asi to teď jen tak nenasimuluji. Tak jen pár bodů.
- počet stat. rout > 4 nebude problém. Používám to běžně a teď jsem se díval do profilů a nejvíc, co mám tady v NM, tak je 15. U mě to má krom fyz. ifaců smysl hlavně u VPN, kde nechci používat vzdál. def GW, takže musím všechny podsítě přidat staticky do routovací tabulky. Ale určitě bych našel někde i profily, kde toho je víc.
- základní verifikace tam je. Určitě v případě nmcli. Nedá se tam nabouchat nesmyslná IPv4 nebo IPv6 adresa. U def. gw to ověří, jestli je v nastaveném rozsahu sítě. Pokud se přidává statická routa a použitý next hop není přímo dostupný, tak se po aktivaci profilu vytvoří zároveň v tabulce další linková (scope: link) routa pro next hop. Tam se to chová jinak než příkaz ip, který vrátí chybu, pokud next hop není dostupný. Někdy se hodí jedno, jindy druhé. Je to za mě jiné chování, což může být diskutabilní, ale ne bug.
- jinak pokud děláš vzdáleně terminálem něco, co může po chybě odstřihnout spojení, tak je na to v NM jiná funkce - checkpoint.
To uloží aktuální profil od zařízení, provede napsaný příkaz za dvěma pomlčkami a pokud to nepotvrdíš do 30s (dá se nastavit), tak to profil vrátí zpátky.
Takže např. když nastavuješ parametry eth0, ať už přes nmcli nebo nmtui, tak se neprovedou hned, musí se pustit příkaz nmcli connection up, aby se změny projevily.
Tohle uděláš s checkpointem.
nmcli dev checkpoint eth0 -- nmcli con up eth0
Když se něco pokazí, vrátí se to samo zpátky, můžeš to opravit.
https://networkmanager.pages.freedesktop.org/NetworkManager/NetworkManager/nmcli-examples.html
- pokud už na něco potřeba manuální skript (byť by to byly ty routy :)), tak se dá hezky spouštět přes NM dispatcher. https://networkmanager.pages.freedesktop.org/NetworkManager/NetworkManager/NetworkManager-dispatcher.html
Je tam spousty užitečných proměnných. Já to třeba párkrát využil, když jsem potřeboval se spojením zároveň inicializovat BPF filtr, co běží na procesoru síťovky. Nebo nějaké parametry, co jsou přístupné pouze přes proprietární nástroje, např. u Mellanox karet.

A beru, někdy to fakt může být ta poslední kapka, než to člověk vzdá.

To ne, takhle ten můj komentář neber. Tohle nebyla poslední kapka. Já dost často (vlastně pořád ;-) ) komentuju stylem "za hranou a ironicky" jen abych upozornil na problémy. Ať si NM klidně existuje, mě je to fakt jedno.

Navíc si dost často říkám, proč taková funkce vůbec existuje. Zase příklad. Používal jsem a psal jsem články o mdadm (a btrfs a zfs), ale potom v praxi zjistíš, že je levnější koupit pořádný řadič, další problém máš z krku. Prostě už se nemusíš starat o to, jak dobře jsi vytvořil to pole a jaký je přesně příkaz na přidání disku. (A samozřejmě doma mám btrfs i zfs pole.)

Stejně tak, v roce 2006 jsem pomáhal zakládat místní ISP. Psali jsme si vlastní FW skripty, vlastní skripty pro distribuci fw a trafic shaping skriptů u nás na sít. Dneska mám doma mikrotik router a psát si vlastní iptables / nftables / pf na freebsd mě už ani nenapadne.

Tedy co všechno umí NM z hlediska koordinace nastavení sítě a fw a vpn mě vlastně vůbec nezajímá, protože to umí router krabička za cenu jednoho oběda.

A ten můj příklad z NM fakt nebyl o nějakém bugu nebo o nějakém mém trápení s NM. Jen jsem chtěl ukázat (a o tom jsem psal možná už před 15 lety) že je vhodné se zamyslet nad tím, jestli má opravdu cenu vyvíjet, distribuovat, uživatelům vnucovat a tak dále systém, který ty uživatele nutí znát ip+iptables+NM, když jim fakticky stačí znát ip+iptables a mají to jednodušší.

Jo, prostě u mnoha těchto pomocníků dojdeš k tomu, že znalosti vyžadující jejich obsluhu vlastně jednak značně přesahují znalosti nutné pro přímé ovládání té vrstvy pod tím a dost často taky musíš mít znalost té vrstvy pod tím. Takže proč bych se měl učit ip+NM, když mi bohatě stačí jen ip. Tohle byl jenom příklad. Viděl jsem hromadu pomocníků pro lvm, no jednodušší je přímo příkaz lvm a další z jeho balíčku. V jenom článku jsem si dělal srandu z nějakého komerčního nástroje pro iscsi, přičemž to iscsi stačilo nastavit doslova třemi řádky v konfigu. Zatímco v nástroji jsi musel definovat abstraktní skupiny, pravidla skupin, zabezpečení bla bla bla a vypadly z toho 3 řádky. Které ses dozvěděl po zadání man iscsi na freebsd.

Zase Jirsákujete? Si přečtěte, jak a na co reagujete, a pak si najděte někoho jiného na spolutrollení.
/ignore.

Strucne: jste liny problemy resit, radsi budete hodiny nadavat :-)

Ale to prece neni chyba systemd, ze ostatni si jeho sluzby nejakou formou integruji.

To jste ale jen jinými slovy přeformuloval problém, o kterém jsem psal. Jen ho holt ve svém nadšení odmítáte vidět.

Trochu mi to připomíná strašidelnou část z jistého videokanálu o fotografii. Ten člověk tam popisoval, jak svého času používal nějaký smartphone s androidem, protože mu vyhovoval nejvíc. Jenže po nějakém čase už jeho blízcí příbuzní nemohli déle snášet, jak je nekompatibilní s jejich oblíbenými (pouze) jablečnými vychytávkami, až uspořádali intervention a vymluvili mu díru do hlavy, takže si ten iPhone pořídil taky. Když to vyprávěl, tak už to vyznělo tak, že měli vlastně naprostou pravdu a on díky nim prozřel, jen občas trochu lituje, že přišel o spoustu těch vlastností, kvůli kterým původně používal ten nejablečný smartphone. Pointa je, že taky můžete říct, že za to vlastně Apple vůbec nemůže a je to jen a pouze hloupost těch příbuzných (a nakonec i jeho). Ale bude to stejná demagogie jako v případě systemd, který také cíleně vytváří tu umělou provázanost a nekompatibilitu nutící ostatní přejít kompletně na "jejich svět".