Názory k článku Nebojte se systemd: co to je a co umí? - Root.cz\nRoot.cz » Linux » Nebojte se systemd: co to je a co umí? » Všechny názory\nNázory k článku Nebojte se systemd: co to je a co umí?\n23. 5. 2016 0:43\nSe systemd jsem se už tak nějak smířil, i díky tomu že start systému je, zvlášť na SSD, bezkonkurenčně rychlý (v rámci sekund). Taky se nám objevily už i nějaké nástroje se kterými se dá rozumně konfigurovat. Docela se těším na další díly tohoto článku...\nJeště jsem se nesmířil, vadí mi, že porušuje "Keep it simple, stupid" a " doing one thing and doing it well", takové věci se rády vymstí v budoucnu ... ale taky se těším na další pokračování.\nNepobral jsem ale jednu věc: Píše se tam, že "konfigurační soubory – odpadá nutnost psaní redundantního kódu démonů", ale tak stejně musím psát kód pro ty cíle a jejich závislosti, takže buď to udělají maintaineři jak v systemd nebo v sysinituV nebo to v obou stejně udělám já?\n23. 5. 2016 6:55\nJeště jsem se nesmířil, vadí mi, že porušuje "Keep it simple, stupid" a " doing one thing and doing it well"\nJak to porušuje?\n23. 5. 2016 7:01\nPo 30 letech života systému přinese používání "Keep it simple, stupid" neoptimální granularitu systému, příliš mnoho jednoduchých prvků, které se svou funkcí překrývají nebo duplikují funkce jiných prvků, logickým evolučním a optimalizačním krokem je pak integrace služeb, která granularitu systému zoptimalizuje. Tedy systemd. Ten nějakou dobu poroste, až granularita se stane neoptimální a dojde k evolučnímu zvratu a návratu k "Keep it simple, stupid", a časem se celý cyklus bude zase opakovat.\n23. 5. 2016 7:18\nJako proti jejich záměru ani slovo, ale problémy, resp tu část, kdy měli vlastně vymyslet ten sjednocující a cool mezi-čánek, prostě nevyřešili a místo toho píšou nekompatibilní blob odznova\nAno, možná. Ale zase na druhou stranu i jádro je blob, či black box, pro uživatele vyšších vrstev. sytemd vytváří topologicky protiváhu jádru, black box, přes který ovládáte služby systému. To, že to uživateli zůstává skryto, je evoluční výhoda, optimalizace granularity systému, protože v budoucnosti bude možnost měnit vnitřek tohoto blobu, aniž by bylo třeba měnit jeho komunikaci s okolím. Je možný i návrat zpět, když se do systemd v budoucnosti přidá vhodné API pro vyčlenění ovládání některých služeb do jiné části systému.\nStejným evolučním vývojem si prošly i programovací jazyky, od strojového kódu k Javě, která má vlastní virtuální počítač a vlastní instrukce, dnes už zase virtuální (JIT). I tento vývoj narážel na odpor části odborné veřejnosti. Časem možná systemd přeroste ve virtuální operační systém, s vlastními virtuálními službami, které bude realizovat přes funkce jádra, tak jak to dělá VM Javy.\nPůjde pak udělat jednu věc, za běhu vyměnit operační systémy, aniž by bylo třeba měnit nastavení aplikací. Situace za pár let bude taková, že poběží miliardy IOT zařízení a bude třeba mít prostředky k automatizované aktualizaci jejich software, včetně operačního systému, situace kdy by nějaký admin vůbec věděl, kde mu co běží, ani nenastane, bude pracovat jen s datovou abstrakcí na úrovni systemd. Jednotným způsobem bude spravovat najednou miliony zařízení s různými operačními systémy, ale jednotným systemd (prakticky virtuálním OS).\nMicrosoft je už v tomto popředu s automatickou aktualizací W10.\n23. 5. 2016 8:20\nTak ona je to celkem otázka. Podle mě není "linux" tak oblíbený proto, protože se čeká až to bude stejný blob jako W -W10. A co se týká aktualizací - no to potěš, jestli budou jak na widlích ....\n"Půjde pak udělat jednu věc, za běhu vyměnit operační systémy, aniž by bylo třeba měnit nastavení aplikací"\nA čemu? Jádro bude celkem stejné a zbytek spolyká systemd\n23. 5. 2016 8:36\nNo protože budete mít ten OS někde v těžebním stroji na asteroidu vzdáleném miliony kilometrů od Země a životnost toho stroje bude několik desítek let, vzhledem k nutné údržbě bude neúnosné mít v provozu mnoho verzí operačních systémů na strojích různých generací.\nTo samé třeba v autonomních automobilech zde na Zemi. Bude neúnosné spravovat sw automobilů na dálku s tím, že budou v provozu modely za 20 let s různými verzemi OS. A předpisy se pro ně budou měnit co půl roku, jak známe byrokracii.\n23. 5. 2016 8:48\nNevím jestli vzdálenost hraje roli na úspěch aktualizace systému, teda krom výpadku, ale to ani systemd nevyřeší. Ale jinak to vypadá s tím Marsem poutavěji.\nA když se vám systemd mění pod rukama tak za 20 let to bude únosné? A když se změní 2 požadavky byrokracie jak píšete, tak bude lepší updavovat blob systemd, nebo kdyby byl napsán modulárně, tak jenom modul nebo 2 a ty sestémy, které by tyto části ani nepotřebovali->neměly, by riziko aktualizace ani nepostihlo?\n23. 5. 2016 9:06\nBudete mít možnost volby, zda bezbolestně změnit os a systemd s tím, že pro aplikace se nic jakoby nezmění, a nebo vyměnit aplikace.\nPodívejte se třeba na vývoj Androidu, začal s celoobrazovkovými aktivitami, aby nyní dospěl k oknům.\n23. 5. 2016 9:18\nPro aplikace se nic nemění, pokud je spouštíte stejným příkazem a dáváte jim stejné parametry, případně za běhu. Odkud to leze je jedno. Pokud se to rozbije v systemd, tak je to stejné jako by se to rozbilo v jiném init. BUď služba dostane co potřebuje a nebo ne.\nAndroid nedospěl ani tak k oknům, jako k fragmentům. Ovšem na Androidu mohou běžet aplikace s Fragmenty nebo jen s Aktivitami. Na distribuci se systemd už některé appky neběží bez kompatibility se systemd, tedy stejně, jako se zavedením fragment už by nešly spustit některé aplikace jen s aktivitami\n23. 5. 2016 9:37\nAha. To jako za dvacet let bude v OS porad uplne stejny format binarek a urcite i uplne stejne verze knihoven, aby se to nemuselo rekompilovat. Nebo budeme vsichni mit pocitace narvane jadry a RAM do takove miry, ze to vse pojede v interpretovanem jazyce nebo s nejakym just in time kompilatorem?\n23. 5. 2016 9:33\nTo chci videt. OS v novych autech bude desetkrat tak velky, nez ten v tech 20 let starych. A nebude tam ani pamet na ulozeni novych predpisu. Ono se staci podivat, jak do rok stareho telefonu uz nejde narvat novejsi verzi OS a poku jde, tak jen pokud ma clovek obzvlaste pevne nervy, aby vydrzel nekolikaminutovou odezvu, protoze tomu "staremu" telefonu schazi 8 jader a 64 GB RAM, aby to utahl.\n23. 5. 2016 9:00\nMyslim, ze byste se mel vice informovat a do te doby, nez budete opravdu danemu tematu rozumet, spise klast zvidave otazky a ne psat vybusne a zbytecne vyhrocene vety. To nikomu nedela radost cist takovou diskuzi.\n24. 5. 2016 23:52\nProč by měl jakýsi nedefinovaný "zbytek" polykat systemd? Ten spolkne jen to, co umožní spuštění vyžádaných a nezbytných systémových aplikací. Zásadní otázkou je udržet objem těch systémově nezbytných v omezení nedovolující b(l)obtnání. V archu si mohu nastavit vše, co chci a považuji to za rozumné i s ohledem na systém.\n23. 5. 2016 8:21\nKontrolní otázka: kolik vám doma běží různých operačních systémů? Nápověda: jeden v TV, další v každém monitoru, mobilu, tabletu, počítači, routeru ... Takže už dnes je to desítky různých OS a jejich verzí. Dnes prakticky je nikdo nespravuje, ale to se s IOT bude muset změnit, bude to mnohem dynamičtější infrastruktura.\n23. 5. 2016 8:24\nJá nemám nic proti tomu, aby se init standardizoval a taky netvrdím že to nechtělo opravit. Ale ne takhle. Přebobtnává to a místo jedněch problémů lezou jiné . . .\n23. 5. 2016 8:39\nOpravdu nevim, proc by nekdo zacal vydavat updaty jen proto, ze mame IoT. Updatuje se prece koupi nove televize nebo mixeru a nez se koupi updatuje, bude lednicka v botnetu A, zachodove splachovadlo v botnetu B a mycka na nadobi v A a C. Nejhorsi bude pracka, protoze ta bude napadena malware, ktery pri programu na prani vlny a pri prani pri nizkych teplotach nastavi 90°C. Vyrobcum to bude jedno, protoze podpora konci mesic po zaruce.\n23. 5. 2016 8:54\nNo nevím k čemu by komu bylo více než 640 kB paměti :-) IOT se nebuduje jako informační síť konzumentů, ale producentů.\nBudou vznikat problémy jako to, že ve skladech nebude dost kávy, protože kávovary špatně odhadly budoucí spotřebu kvůli chybě OS, nebo co by bylo daleko horší, že se kávy vypěstuje více, než se prodá a cena kávy klesne a dojde k velkým finančním ztrátám.\nBudoucí kávovary budou vytvářet specifické chutě kávy (frakční destilací polosyntetické, nebo geneticky upravené kávy, přimícháním horkého vzduchu do páry), které budou přesně odpovídat chuti majitele kávovaru, aniž by si to on uvědomoval. Kávovar na základě evolučního algoritmu sám zjistí, jaká káva jeho uživateli chutná, což pozná podle četnosti vaření kávy :-)))\n23. 5. 2016 9:02\nA jak to souvisí se systemd? Jako u Iot je problém hlavně v přizpůsobení se hardwaru a tím je dost vytvořena ta diverzita systémů, ne initem\n23. 5. 2016 9:22\nNo on už to není jen init, ale i řízení služeb, tedy skutečně systemd přebírá funkci os, plánování zpracování úloh. Je tedy šance vytvořit jednotné rozhraní pro správu úloh nezávislou na os a verzi. Bude možné na základě toho efektivně a dynamicky řídit zpracování ve vzniklém distribuovaném systému, což může být na základě vlastní zkušenosti daného zařízení a nebo díky signálům přicházejícím po síti, tak aby v daném okamžiku běžely jen potřebné služby. Celý distribuovaný systém bude žít vlastním životem, jako nějaký komplexní organismus. Nebude v něm místo pro adminy. Řízení výkonu a jeho optimalizace půjde automatizovat.\nPříklad: serverovna se sama přizpůsobí aktuálnímu výkonu, bez toho, že by nějací admini naskriptovali chování jednotlivých serverů. Což povede k úsporám energie, zvýšení výkonu, zvýšení odolnosti proti útokům, serverovna se bude moci sama učit, jak se přizpůsobit požadovanému výkonu. Admini maximálně budou psát šablony strategií chování pro zvláštní situace.\n23. 5. 2016 9:32\nAle proti tomu já nic nemám, naopak. To je podle mě správný systémový přístup. Jde ale o to, že dnes už nějaký systém je a ta Vámi popisovaná vrstva, která má přinášet tu abstrakci (systemd) je abstraktní jenom pro ty systémy, které místo abstrakce mají na systemd závislost. Jinými slovy, na jádru být abstraktní musí nebo jdou do háje a na softwaru nad už jen vytvářejí závislost. Jak bych to napsal? Tam není abstrakce (zjednodušeně) jádro + init (nějaký) + software, nýbrž jádro+ systemd + software na systemd závislý. A co pak je ta feature? Že můžu vyměnit i jádro? To můžu i dnes. Systemd nevyměním. tak v čem je ta možnost změny?\n23. 5. 2016 9:43\nTak, a už jsem se v tom ztratil, kdo komu co psal ....\n23. 5. 2016 9:35\nMůžu se zeptat, kdy ti naposledy doktor kontroloval dávkování prášků?\nInit nespoučtí tasky, nepřiděluje systémový čas, nic. Ten se stará o to, že když proces A potřebuje využívat službu B, služba B poběží a bude správně konfigurovaná. To, jestli daemon alokuje 100kB nebo 100MB dat, jestli běží interně v jedno nebo 128 vláknech, to ani nepotřebuje, ani nesmí, vědět. A je zodpovědný za to, že pokud chce uživatel nějakou kombinaci modulů (web server + Wayland + Gnome), pozapíná včechno, co je k této konfiguraci potřeba.\n23. 5. 2016 10:01\nNo a pokud uživatel nepoužívá web server + Wayland + Gnome v době od 3:00 - 5:00 v noci často, měl by to systém sám poznat a službu vypnout. Tedy jakási funkce inteligentního OS, správa prostředků na vyšší úrovni. A takového budoucího chování je systemd předobrazem a nebo ho v budoucnosti alespoň umožní. Svými funkcemi se tak bude blížit OS. Bude spravovat systém z hlediska vnějších požadavků, základní OS pak z hlediska možností přidělování zdrojů.\nZ logiky věci plyne, že tyto funkce je vhodné rozdělit. Ostatně v hlavě to máte taky tak, základní OS - podvědomí řídí činnost vašeho organismu, přiděluje například kyslík jednotlivým orgánům, a vědomí (systemd) určuje, co s tím organismem podniknete :-)))\nOstatně v hlavě to máte taky tak, základní OS - podvědomí řídí činnost vašeho organismu, přiděluje například kyslík jednotlivým orgánům, a vědomí (systemd) určuje, co s tím organismem podniknete :-)))\nKdyby pridelovani kysliku ridilo podvedomi, asi bychom se prilis vysokeho veku nedozili. Pokud systemd ma byt jakymsi podvedomim OS, tak to s Linuxem vidim blede, protoze prave podvedomi je zodpovedne za hafo problemu, kterymi lidmi trpi.\n23. 5. 2016 10:16\n". Ostatně v hlavě to máte taky tak, základní OS - podvědomí řídí činnost vašeho organismu, přiděluje například kyslík jednotlivým orgánům, a vědomí (systemd) určuje, co s tím organismem podniknete :-)))"\nTak to není. Podvědomí člověka určuje všechno a už je dokonce dokázané, že rozhodnutí které zdánlivě dělá člověk, je několik (asi) milisekund před tím nadiktováno podvědomím.\n"No a pokud uživatel nepoužívá web server + Wayland + Gnome v době od 3:00 - 5:00 v noci často, měl by to systém sám poznat a službu vypnout"\n:-D Noční můra. Jen taková situace, řekněme, že by mi server startoval 2s, tak když v té noci mi tam budou chodit lidi po 10 minutách, tak každému začne odezva startem serveru?\n23. 5. 2016 10:32\nPodvědomí člověka určuje všechno a už je dokonce dokázané, že rozhodnutí které zdánlivě dělá člověk, je několik (asi) milisekund před tím nadiktováno podvědomím.\nNení to dokázané. To jsou pouze závěry lidí, kteří jsou bohužel více filozofové a humanisté než přírodovědci. To je totéž, jako kdybych za vznik události považoval dobu, kdy se informace objeví na monitoru a potom bych byl velmi překvapen, že se ještě před tím cosi děje (dekódování obrazové informace v monitoru, zápis do framebufferu na grafickou kartu, zavolání printf, potom přijde někdo nový a za vznik myšlenky označí právě to volání printf a je opět překvapen, že tomu printf něco předchází. Přitom to větvení, které v konečném důsledku vede až k tomu výpisu na monitoru mohlo dojít někdy miliony instrukcí před tím. A často ani to větvení nelze označit za vznik myšlenky.\nJe jedno video (asi na matfyzu), kde nějaký filozof vypráví o času a důsledky pro vědomí, důsledky pro současnost apod. sem tam se opírá o závěry vědy. V diskusi na konci ho přítomní kvantový a relativističtí fyzici trochu uzemní s tím, že ty koncepty, na kterých on vystavěl svou přednášku vůbec nelze vykládat takto.\nV těchto věcech je nutná spolupráce mezi mnoha obory a to, že jeden signál na eeg předchází jiný signál ještě neznamená nic o kauzalitě. Navíc se to komplikuje tím, že mozek umí události posunout do minulosti (např. známý efekt, když otočíte hlavou a podíváte se hodiny - někdy máte dojem, že první sekunda trvá o dost déle, než další - je to způsobeno tím, že mozek zpětně nahradil "rozmazaný obraz" během otáčení hlavy prvním "snímkem" hodin). Motion blur očí ve skutečnosti vůbec nevnímáme. (Ne že by to nešlo, ale je třeba se aktivně na to soustředit.)\n23. 5. 2016 10:43\nTak nevím, já to četl jako prokázané. Zdůvodňovali to tím, že mozek impuls upraví tak, jak má zafixováno podvědomě a z toho se tvoří vědomí. Jedno je jisté. Z křišťálové koule to neleze a mozek, resp. podvědomí, je tvořeno nastavením neuronů a z toho taky vylézají vědomé myšlenky, takže z čeho by to pak pocházelo než z individuálního nastavení mozku? Z nastavení krku? Nebo levé nohy?\n" V diskusi na konci ho přítomní kvantový a relativističtí fyzici trochu uzemní s tím, že ty koncepty, na kterých on vystavěl svou přednášku vůbec nelze vykládat takto."\nNo, oni se totiž hádají vědci i mezi sebou a trochu to souvisí i s kvantovou fyzikou. Zde už bych se ale pouštěl na tenčí led. Jak přesně interpretovat zákony kvantové fyziky nevím. Četl jsem, pochopil jsem ale to je tak vše.\n23. 5. 2016 11:03\nZdůvodňovali to tím, že mozek impuls upraví tak, jak má zafixováno podvědomě a z toho se tvoří vědomí. Jedno je jisté. Z křišťálové koule to neleze a mozek, resp. podvědomí, je tvořeno nastavením neuronů a z toho taky vylézají vědomé myšlenky, takže z čeho by to pak pocházelo než z individuálního nastavení mozku?\nNo to jo, ale slyšel jsem interpretace, že to znamená, že člověk nemá svobodnou vůli, protože se myšlenka tvoří ještě dřív, než si to člověk uvědomí. To je nesmysl, protože i to "uvědomování si" nutně vyžaduje aktivitu neuronů a tedy začíná ještě před tím, než si to člověk uvědomí. Na to není nic divného a překvapilo mě, jak si to někteří lidé vykládají. Prostě to, že se na eeg objeví aktivita 200ms před tím, než si něco uvědomím, to neznamená, že mi to nařídilo podvědomí a já jsem jen jeho otrokem. Je spíš otázkou, zda tyto pojmy mají vůbec nějaký smysl, případně jak je vůbec definovat.\n" protože se myšlenka tvoří ještě dřív, než si to člověk uvědomí"\nNo, já si to tak vykládám, ale spíš tak, že se\n1. aktuální rozpoložení (situace, nálada ....) +\n2. požadavek na akci (tedy cokoliv vyžadující vůli)\nzkombinují a prožene se to podvědomím tvořeným\n3. podvědomím (vypěstovaném životním prostředím a životem v něm) a taky\n4. přes dědičné podvědomí a pak z toho "vyleze" nějaké vědomí\nTakto nějak jsem to z textu pochopi\n23. 5. 2016 12:26\nx (neregistrovaný) 193.179.215.---\nrumpkernel a je obslouzen v radu milisekund http://www.skjegstad.com/blog/2015/08/17/jitsu-v02/ nebo treba http://erlangonxen.org/ (tam demo)\nV nicem z toho se pochopitelne s necim takovym obrovskym, nenazranym a komplexnim jako je systemd nebo Windows 10 IoT nepocita.\n23. 5. 2016 12:31\nZatím se nepočítá. Mobilem se dřív taky jen telefonovalo.\n23. 5. 2016 12:35\nNeděláte vy v MS? Aneb jeden blob na všechny platformy a na věčné časy ...\n23. 5. 2016 12:45\nNo v případě systemd ten blob lze vyměnit jednoduše, jen zachováte rozhraní dané jeho doménovým jazykem. V případě individuálně psaných inicializačních skriptů musíte každý systém prozkoumat, zda tam není něco dopsané a to ručně přepsat.\n23. 5. 2016 12:47\nJinak MS se svým systemd jistě časem přijde :-)))\n23. 5. 2016 12:53\nJenomže MS další blob už ani nepozná. Zde to rozděluje balíčky na systemd a nonsystemd. Jak moc a jak do budoucna, to je otázka.\n23. 5. 2016 12:51\nNe. Pokud mám dnes Debian + Gnome a odinstaluji systemd, tak můžu nainstalovat co chci a nepojede to kvůli systemd-logind. Musím mít script, který napsali v Gnome pro Ubuntu aby to jelo. Takže máme systemd, který lze vyměnit, ale není za co, aby to fungovalo,\nJiinými slovy: systemd můžete vyměnit pouze pokud zachováte rozhraní systemd. To je trošku non-sence\n23. 5. 2016 13:09\nAle to vůbec není nonsens. Vždy ho můžete implementovat lépe, nebo to posunout někam jinam. Rozhodně rozvoj linuxu v budoucnosti bude díky systemd mnohem jednodušší.\n23. 5. 2016 13:14\nAno, bude to jednoduché. Co nedá Poetering do systemd, to nebude.\nNebo nad stejným API napiš něco lepšího a Poetering bude v učebnici Linuxové historie jako "ten, kdo přišel s myšlenkou na lepší init, ale totálně zbabral implementaci."\n23. 5. 2016 13:34\nTaky už mě to napadlo, ale jak člověk dožene tým vývojářů s náskokem několik let?\n23. 5. 2016 13:49\nTo je blbě položená otázka. Já bych to sekl na čtyři:\n1) Dostanu se k jejich zdrojáku?\n2) Má právo ho měnit a za jakých podmínek?\n3) Umí jejich verzovací systém udělat fork?\n4) Dokážu dát kolem sebe tým lidí podobnýho smýšlení, kteří s tím pomůžou?\n23. 5. 2016 14:01\nJo, to jsou dobré otázky. Ale fakt nad tím uvažuju už asi měsíc, protože hned jak se k tomu dostanu, budu přecházet na Gentoo hlavně kvůli tomu, že budu muset na serverech. Uhnízdil jsem se na Debianu a teď tohle. Nejsem si ale jistý, jestli bych to forkoval, abych si zanesl závislosti ze systemd a pak je musel kroutit a dodržovat, kdyby to pak jinak nešlo, jestli by nebylo lepší začít od začátku a hezky část po částech začít od initu a pak přidávat další moduly aby to nebylo tak zadrátované a fungovaly tak nějak samostatně. Fakt nad tím přemýšlím\n23. 5. 2016 14:12\nZ Debianu systemd jeste jde vyndat. Otazka je, jak dlouho jeste a otazka je, jestli Gentoo vydrzi napor mainstreamu.\n23. 5. 2016 14:14\nJo, ale to mé Gnome už pak bez obezliček nespustím === čekat až to jednou nepůjde vůbec\n23. 5. 2016 15:23\nO to bych se nebal. Ono Gentoo uz nakou dobu dost dobre odolava "linuxovymu mainstreamu". A jestli se nepletu, vyvoj OpenRC bezel prave v Gentoo-komunite...\n23. 5. 2016 15:50\n"O to bych se nebal..." Openrc je jedna vec, patchovani vseho moznyho i nemoznyho aby to fungovalo bez systemd druha. Takze ja bych se toho celkem bal.\n23. 5. 2016 13:15\nJiste. Ja jen nechapu, proc systemd jeste nemaji v BSD a jinde. Vzdyt je to prece tak skvely init, ktery navic ma tu uzasnou vlastnost, ze si muzou napsat i vlastni verzi, pokud zachovaji API a bude to fungovat tak dlouho, dokud Poettering neprijde s modifikovanym API.\n23. 5. 2016 13:20\n"Jiinými slovy: systemd můžete vyměnit pouze pokud zachováte rozhraní systemd. To je trošku non-sence"\nFakt? Koupil jsem si nový auto. Furt má tři pedály, volant a šaltpáku. Prostě stejný driver interface pro ovládání směru a rychlosti. Přitom je od jinýho výrobce a podstatně novější. To je trošku non-sense, ne?\n"Takže máme systemd, který lze vyměnit, ale není za co, aby to fungovalo"\nTakže ono se nedá forknout systemd, seknout API a znovu to rozkouskovat? Myslel jsem, že systemd je pod nějakou formou GPL. Kdyby kritici využili energii, kterou vynakládají na kritiku systemd a na osobní ataky na Poeteringa k tvorbě lepšího initu, tak si systemd neškrtne.\n23. 5. 2016 13:27\nKoupil jsem si nový auto. Furt má tři pedály, volant a šaltpáku.\nAuto se systemd ma pedalu devet, saltpaku nema, misto volantu ma dvoje riditka, z nichz kazde ovlada jedno kolo. Radi to samo a pedaly se mackaji vzdy dva az tri najednou. To muze byt dost problem, protoze vetsina lidi ma jen dve nohy.\n23. 5. 2016 13:28\nTo jako vážně myslíš že mám čas 3 roky něco předělávat po teamu lidí, kteří na tom soustavně makají? To si zrovna do toho tvého auta můžeš odlít nový motor až se ti pokazí, takový fork.\n"Fakt? Koupil jsem si nový auto. Furt má tři pedály, volant a šaltpáku. Prostě stejný driver interface pro ovládání směru a rychlosti. Přitom je od jinýho výrobce a podstatně novější. To je trošku non-sense, ne?"\nJo? A když teď na debianu 8 odiinstaluji gnome a vrátím tam init tak to spustím? Neboli když sednu třeba za "automat" tak má stejný interface? nebo když vezmeš pedály z ferari tak ti sednou do felicie? Tady padá ten "systemd" interface\n23. 5. 2016 13:33\nKdyby kritici využili energii, kterou vynakládají na kritiku systemd a na osobní ataky na Poeteringa k tvorbě lepšího initu, tak si systemd neškrtne.\nTenhle argument slýchám už dlouho, když se vám to nelíbí, tak si napište lepší init. No, co tahle třeba zachovat možnost použít původní sysv / upstart / cokoliv? Myslím, že by spousta lidí neměla se systemd takový problém, kdyby měla možnost jej prostě nepoužívat. Nebo si jej používat tam, kde chtějí. Jak vypadala diskuse v Debianu, kdy někteří chtěli zachovat možnost volby init systému, všichni víme.\n23. 5. 2016 18:07\nip (neregistrovaný) 178.77.243.---\nNo však jo. Ti co remcali mohli klidně začít makat na podporování původního initu. Je to hromada práce kterou ovšem nikdo nechtěl dělat, vývojáři z Debianu raději chtěli věnovat úsilí lepší podpoře systemd. Stejné to bylo ve Fedoře.\nJak vypadají diskuze na devel listech distribucí často vidíme - hromady keců, ale skutek utek. Pokud se někdy někdo dal do skutečné práce, nikdo by problém neměl. Ono přeplatit si diskuzní list a poslat mail je jedna věc, ale dát se do maintainingu 350 init skriptů je věc jiná...\nNo však jo. Když už někdo dostane prostor a prasí to jako slon v porcelánu, tak všichni kývejme jak kývací panáčci. Případně abychom pokaždé, co začne někdo něco prasit, nebyli za lenochy a kecaly, tak začněmě po skupinkách prasit to samé. ale jinak, jinak se ani neozývejme. Však jsme jenom uživatelé, taková nepodstatná skupina lidí co nemá u linuxu co dělat. Ale pozor, kdo se ozve a komu se něco nelíbí, tak už aby dělal na svém řešení, jinak je nějaký lempl. Hmmmmm\n23. 5. 2016 22:04\n> Je to hromada práce kterou ovšem nikdo nechtěl dělat, vývojáři z Debianu raději chtěli věnovat úsilí lepší podpoře systemd.\nMáš pro tohle tvrzení nějaký důkaz?\nPodle mně dostupných informací totiž věc rozhodovala TC, došlo k plichtě mezi Upstartem a Systemd a pro Systemd rozhodl hlas jediného člověka - předsedy TC.\n23. 5. 2016 22:11\nA mimochodem, pro systemd hlasoval i Russ Allbery, který z TC odstoupil a v rezignačním emailu napsal, že v otázce systemd rozhodl špatně a že odstupuje proto, že práce v TC vyžaduje lepší přípravu, než jaké je schopen:\n23. 5. 2016 22:16\nNo jo, co bys od nej chtel, kdyz je to Rus. ;-)\n23. 5. 2016 22:19\nKdyž vyjdu z toho, že takové rozhodnutí ovlivní distribuci a vůbec balíčky na mnoho let, tak je celkem síla aby to leželo na jednom hlasu. Je fakt že je svobodná volba, ale když je půlka proti a rozhodne jeden hlas tak to je fakt drsné.\n23. 5. 2016 22:25\nA ted si predstav, ze jeden hlas rozhosl o tom, ze se v USA mluvi anglicky. Schazelo malo a cetl bys doc k Linuxu nemecky.\nBTW, jestlipak Allbery nasledne spachal seppuku motorovou pilou, jak by se v takovem pripadu sluselo?\n23. 5. 2016 22:33\n? Já myslel že je to proto, protože to byla převážně anglická sféra vlivu a Kanada francouzská, tak proto je tam úřední jazyk francouzština\n23. 5. 2016 22:50\nHm, asi ano. Zagoogloval jsem a vypada to, ze je to kachna, ktera vznikla nejak takto: http://www.english.illinois.edu/-people-/faculty/debaron/essays/legend.htm\n23. 5. 2016 22:52\nOMG WTF sorry, to se mi číst fakt nechce ;.)\n24. 5. 2016 3:44\nNečetl, protože to by žádné počítače nebyly. Možná ještě tak analogové. U jejich vzniku byla angličtina, která je analytickým jazykem a z jejího podhoubí ty myšlenky o automatickém zpracování jazyka vycházejí :-)))\n24. 5. 2016 7:28\nProblém je, že SystemV ve skutečnosti není init. Aspoň ne init snů.\n1. Od initu bych jako uživatel čekal, že mu řeknu "dneska chci desktop s KDE" nebo "teď přepni Gnome a web server na testování" a on se postará. Jak tohle řeší SystemV? Několik levelů, když chci na pětku, projede všechno <= 5 a tím to hasne. Otázka je, mám mít Gnome s vyšším číslem než KDE, nebo naopak? A nepopere se to o paměť a procesor, když v jednom případě poběží obojí? A proč se web server spustí vždycky, i když ho někdy vůbec nechci? Takže občůrávky v podobě změny symlinku na jiný init.d a potupný reboot jak ve widlích...\n2. Jako admin bych čekal, že spustí službu a budu mít jednotný ovládání všech služeb. Jak to dělá starý řešení? Unifikace pomocí switche ve skriptu, kde se kompatibilita dostahuje prostě tím, že se větve jmenují stejně? A tím, že část skriptu kopíruju, u části musím hluboce studovat fungování souvisejících věcí a musím fakt dobře vědět, co ten deamon potřebuje, jaký má parametry,...? Není lepší jenom deklarovat "pro db server spusť a, b, c, d. D spusť v okamžiku, kdy a, b a c už běží." a neřešit, ve skriptu pro c, že parametr x daemona a musí být 7?\n3. Jako programátor nechci zabíjet čas psaním skriptu ani rvaním furt stejných věcí (jako ověření běhu služby apod.) do kódu a opakovaným testováním. Jedna věc má být na jednom místě, ne v pěti daemonech. Ono to totiž není jenom napsat, ale i otestovat furt ty samý věci dokola. Když někdo garantuje otestovanou funkcionalitu, která pokryje třeba 10% práce na projektu za cenu pěti řádků v deklaračním souboru, tak bych byl pitomec duplikovat to a znovu testovat. Init skript to nenabízí.\nNo a protože na to všichni kašlali a furt zápasili s tou parodií na init, tak uspěl jeho náhradou první, kdo byl ochotný něco udělat a měl dost prořízlou hubu, aby to okecal a zdůvodnil. No a protože jeho řešení je lepší než žádný řešení a s alternativou se nikdo nezdržoval, ... Takže asi tak.\n24. 5. 2016 8:18\n1. Od initu bych jako uživatel čekal\nOtázkou je, zda je init tou správnou vrstvou, na které by se to mělo řešit. Máme virtuálky, máme kontejnery, ty si zapněte a vypněte, kdy potřebujete. Případně nevidím problém se relognout z gnome do kde a v terminálu si pustit service httpd start.\n2. Není lepší jenom deklarovat "pro db server spusť a, b, c, d. D spusť v okamžiku, kdy a, b a c už běží." a neřešit, ve skriptu pro c, že parametr x daemona a musí být 7?\nTak především žádné takové složité závislosti nejsou v praxi potřeba. DB server si můžete pustit jako uživatel klidně příkazem pg_ctl start -D /data a máte to. Hromada démonů (a s nástupem systemd se to nemění), má ovládátko typu daemon_ctl.\nV tomto případě je systemd v nevýhodě, protože zatímto do původního init skriptu byla možnost si vedle standardních start, stop, status apod. přidat třeba configtest. Takže admin příkazem service httpd configtest zkontroloval nastavení a příkazem service httpd reload jej potom nechal zavést. U systemd o tuto možnost přicházíte a je nutné pro kontrolu volat apachectl -t -D cosi ... (což je samozřejmně správné řešení).\n3. Jako programátor nechci zabíjet čas psaním skriptu\nTohle čtu pořád dokola. Opravdu je taková zátěž, pro někoho, kdo napíše tisíce řádků kódu pro jeho skvělý program, pozměnit nějaký template? Stejně se s těmi rc skripty nic jiného nedělalo. Napsat akce pro start, stop, hotovo. Stejně se to píše i do systemd unity. Tak jaký je rozdíl. Za život jsem napsal mnoho rc skriptů, stejně tak několik unit pro vlastní potřebu, rozdíl v tom fakt nevidím. Ano, zápis unit souborů je přehlednější.\n24. 5. 2016 8:45\nHromada démonů (a s nástupem systemd se to nemění), má ovládátko typu daemon_ctl.\nCož vypovídá o kvalitě dříve používaných správců služeb. Kdyby poskytovaly potřebné služby, málokdo by měl potřebu psát si vlastní ovladač služby. To, že se to zatím nemění, je přirozené – nikdo nemůže čekat, že s vydáním první verze systemd na něj přejdou všechny projekty a veškerý legacy kód zahodí. Ostatně, stačí se porozhlédnout tady v diskusi, co se děje, když vývojáři Gnome prohlásí, že nehodlají udržovat kód, který s DE nesouvisí, a začnou využívat logind.\nkdo napíše tisíce řádků kódu pro jeho skvělý program\nDotyčný je asi dobrý v psaní toho svého programu, ale v psaní shell skriptů bude spíš průměrný nebo podprůměrný. Proč by měl svůj čas ztrácet tím, že bude bastlit nějaký skript, proč by měl svůj skvělý program kazit tím, že pro něj napíše špatný init skript? Jistěže to nakonec nějak splácá, ale má to smysl? Nemohl by ten čas využít lépe?\npozměnit nějaký template? Stejně se s těmi rc skripty nic jiného nedělalo\nPak je ale nesmysl, aby těch pár hodnot bylo schovaných v nějakém skriptu, prakticky se to nedá kontrolovat a testovat, snadno tam omylem uděláte něco jiného, než chcete. Všude, kde to jde, je snaha nepsat jak se má něco dělat, ale napsat jenom co se má udělat a to jak nechat na univerzálním otestovaném programu.\n24. 5. 2016 8:59\nCož vypovídá o kvalitě dříve používaných správců služeb. Kdyby poskytovaly potřebné služby, málokdo by měl potřebu psát si vlastní ovladač služby.\nTaky to vypovida o komplexite tech demonu. U databazi je to celkem bezne, ze mate vlastni "konzoli" na startovani. Kdyz startujete databazi "z ruky" tak mate k dispozici ruzne parametery a nektere veci ani jinak nez z konzole nejdou. Doted platilo, ze kdyz jste Oracle nastartovali "z ruky" tak jste zaroven overili ze mate vsechny parametry OS v poradku. A startup "script" byl vlastne jen wrapper okolo te konzole.\nTo ted - se systemd - konci. A bude zajimavy videt jak to dopadne za par let, treba se kazda verze RHEL 7.x bude chovat trochu jinak. Protoze s kazdou verzi ubude nejaka "unixova" vlastnost.\nPS: predchozi verze systemd mazala odhlasenym uzivatelum shared-memory segmenty, nova jim dokonce zabiji procesy.\n24. 5. 2016 9:00\nTipuju, ze dalsi to LP rozbije bude cron a at.\n24. 5. 2016 9:10\nMícháte dohromady dvě věci. Jedna věc je konfigurace. Ta opravdu může být komplexní a budete ji raději nastavovat přes nějakou management konzoli. Ale není důvod, aby se tahle konzole starala o správu procesu – stačí, když správci procesů předá informaci, co a s jakou konfigurací se má spustit. Díky architektuře systemd pak může mít pořád informace o příslušném procesu a může ho ovládat.\nTo nevadí, že jste si ani nepřečetl release notes. K nadávání na systemd úplně stačí znát polopravdy vyčtené z diskusí…\n24. 5. 2016 12:17\nPane Jirsák, říkal jsem si, že nebudu zbytečně trollit, ale na ten váš systemd fanatismus se nedá nereagovat. Myšlenka systemd není z principu úplně špatná, ale provedení je taková katastrofa, že bych zodpovědným jedincům do smrti zakázal práci s výpočetní technikou, včetně chytrých telefonů, televizí, kávovarů a nevím, čeho ještě. Nevím, jaké jsou vaše zkušenosti z opravdového nasazení, moje jsou takové, že poslední dobou systemd může za většinu problémů (pardon, jak by řekl LP, nejde o problémy, ale o vylepšení). Vaše argumenty, jak to usnadní práci, jsou pro většinu programátorů jen žvást. Spousta OSS SW běhá na mnoha platformách, od Win, přes Linux, *BSD, někdy až po opravdové UNIXy (kterých už moc nezbylo). Takže programátor má několik možností - zakouká se slepě do systemd a všechny ostatní platformy odepíše (nebo bude doufat, že se najde někdo, kdo mu bude zpětně systemd věci vykuchávat a upravovat to pro jiné platformy), nebo bude řešit variantu se systemd a bez a nebo se prostě na systemd vykašle a místo zápasu s API, který se mu mění pod rukama raději (jako už 1000x předtím) upraví/vytvoří skript. Mluvit o tom, že například několikrát zmiňované databáze opravdu není možné testovat jen podle běžícího procesu, ale stejně k sobě budou mít vždy vlastní monitoring, to asi nemá ani cenu.\n24. 5. 2016 12:57\nTo, že jiné platformy nemají rozumného správce procesů, znamená, že ho nesmí mít ani linux?\nJinak mně je systemd celkem jedno, mně vadí akorát to, když někdo kritizuje věci, které nejsou pravda. Když bude někdo kritizovat SysVinit proto, že někde v diskusi četl, že žere psi, budu mu oponovat úplně stejně.\nMluvit o tom, že například několikrát zmiňované databáze opravdu není možné testovat jen podle běžícího procesu, ale stejně k sobě budou mít vždy vlastní monitoring, to asi nemá ani cenu.\nCenu to nemá. Nevšiml jsem si, že by tu někdo něco takového psal, ale četl jsem jenom pár komentářů.\n24. 5. 2016 13:14\nTak já si dovolím tvrdit, že kritizuji pouze to, co je pravda a s čím mám osobní zkušenosti - systemd je stále se měnící nedodělek s nepředvídatelným chováním a nemá v produkci co dělat.\nHlavně nemůžu pochopit, jak mohly velké distribuce na ten krám tak rychle přejít... Jinak jsem celkem v klidu, dokud je SLES 11 podporovanej, dávame ten, až bude nutné přejít na 12, tak se ukáže, jak umí SuSE podporovat zákazníky :D\nCož vypovídá o kvalitě dříve používaných správců služeb.\nProgramy *_ctl nejsou jen o akcích start a stop. Jsou to dálková ovládání master procesu daného démona a řeší mnoho dalších věcí. Bylo by dost divné, kdyby do sebe systemd absorboval dálkové ovládání každého jednotlivého démona.\nbastlit nějaký skript, proč by měl svůj skvělý program kazit tím, že pro něj napíše špatný init skript?\nAle no tak... Co je těžkého na tom vzít template rc skriptu a dopsat jeden řádek do start a druhý řádek do stop? Které budou úplně stejné, jako v systemd unitě.\nVšude, kde to jde, je snaha nepsat jak se má něco dělat, ale napsat jenom co se má udělat a to jak nechat na univerzálním otestovaném programu.\nNo to je sice hezké, ale jak u systemd unity, tak u rc skriptu stejně skončíte u toho, že musíte napsat jak se má daný program spustit a ukončit. Ani systemd nemá křištálovou kouli a nevyvěští si, jak má udělat akci (tedy to "co") "prosím zapni mi můj program". Stejně mu tam do ExecStart musíte napsat příkaz na spuštění toho programu.\n24. 5. 2016 10:08\nBylo by dost divné, kdyby do sebe systemd absorboval dálkové ovládání každého jednotlivého démona.\nDivného na tom není nic. Systemd nepřevezme konkrétní ovládání, jenom umožní komunikaci mezi ovladačem a službou. Tím pádem nebude potřeba proprietární apachectl, ale budete moci službu ovládat libovolným nástrojem, který to bude umět. Třeba univerzální konzolí, která bude umět ovládat různé služby (a nebude to dělat nebezpečným voláním konzolových nástrojů na pozadí doprovázeným modlitbami, aby nedošlo k chybnému souběhu).\nCo je těžkého na tom vzít template rc skriptu a dopsat jeden řádek do start a druhý řádek do stop?\nCo je výhodného na tom psát to do nějakého skriptu, když to mohou být dva řádky v konfiguračním souboru? Navíc u normální aplikace stačí jeden řádek… A hlavně, že je to tak jednoduché a stačí napsat dva řádky na správné místo, to víte vy. Ale autor toho programu to nejdřív musí zjistit – a přesvědčit se o tom, že opravdu kvůli těm dvěma řádkům musí existovat celý ten skript.\nstejně skončíte u toho, že musíte napsat jak se má daný program spustit a ukončit\nNormální program se spouští tak, že se napíše jméno spouštěné binárky a případně seznam parametrů. Ukončuje se tak, že se mu pošle příslušný signál.\nStejně mu tam do ExecStart musíte napsat příkaz na spuštění toho programu.\nTedy mu akorát řeknu, co má spustit. A nemusím se zabývat hloupostmi, jako jak a kam si poznamenat PID procesu, jak zjistit, jestli proces stále běží, jak ho ukončit…\n24. 5. 2016 10:33\nSystemd nepřevezme konkrétní ovládání, jenom umožní komunikaci mezi ovladačem a službou.\nJak? To by ta služba musela implementovat nějaké komunikační rozhraní systemd a stala by se tak na něm závislá. To snad nikdo soudný nemůže chtít (bez ohledu na oblíbenost toho kterého systému, byl bych proti i u nejlepšího init systému na světě - bez ohledu na to, že nic takového ani existovat nemůže, protože na každou situaci se hodí něco jiného).\nTřeba univerzální konzolí, která bude umět ovládat různé služby (a nebude to dělat nebezpečným voláním konzolových nástrojů na pozadí doprovázeným modlitbami, aby nedošlo k chybnému souběhu).\nTo univerzální rozhraní už mám dneska. Říká se tomu shell. V této konzoli můžu ovládat veškeré prvky OS. (Závorku jsem četl, jestli se nějaký admin u práce s OS musí modlit, tak by měl pravděpodobně změnit zaměstnání.)\nTo nemusíte ani u rc skriptu, protože to už v tom template vyřešené je.\n24. 5. 2016 10:46\nTo univerzální rozhraní už mám dneska. Říká se tomu shell.\nPod pojmem univerzální rozhraní si představuju něco, k čemu můžu připojit, co mne napadne – shell, GUI konzoli, webové rozhraní nebo třeba vzdálený management.\nZávorku jsem četl, jestli se nějaký admin u práce s OS musí modlit, tak by měl pravděpodobně změnit zaměstnání.\nJak tedy v shellu řešíte to, že zjistíte stav, po té dáte pokyn ke změně – jenže mezi tím se stav mohl změnit?\nK čemu je tedy celý ten rc skript dobrý, když je to jenom neustále se opakující šablona, ve které se jen změní dva řádky kódu? Není lepší ten opakující se kód někam vytknout a v konfiguraci služby nechat jenom ty dva řádky? Přičemž pořád nevím, proč jsou dva, normální procesy se ukončují zasláním signálu.\n24. 5. 2016 11:03\nJak se mohl změnit? Sám od sebe se nezmění. Služba, která běží, mohla náhodou spadnout, ale já nepoužívám služby, které jen tak padají (uptime 3 roky u mě znamená, že démoni, kteří nastartovaly při bootu běží 3 roky, nic menšího neakceptuji). I kdyby se vypnula, tak co? Pokud dám příkaz start, tak se znova zapne. Pokud dám stop, tak se neprovede nic. Pokud dám restart po změně konfigurace, tak se znova nahodí. V praxi navíc stav služeb nezjišťuji, takže se nedostanu do situace, že se mezitím změnil. Udělám rovnou tu akci, kterou chci. Ano, teoreticky lze vymyslet hromadu race, které jsou ale jen teoretické, protože v běžné praxi nenastanou, protože se ten systém používá určitým způsobem.\nNení lepší ten opakující se kód někam vytknout a v konfiguraci služby nechat jenom ty dva řádky?\nAno, hromada rc systému přesně takhle vypadá. Ani nepoznáte, že píšete v bashi, protože vše společné je v základu.\nPřičemž pořád nevím, proč jsou dva, normální procesy se ukončují zasláním signálu.\nNo tak si tam tu stop akci nedávejte a nechte jen volat sigterm. Jsou některé procesy, které (ačkoliv samozřejmě reagují na sigterm) tak mohou před samotným ukončením potřebovat ještě nějaké činnosti. Pokud je nepotřebují, ExecStop nechte prázdný.\n24. 5. 2016 11:29\nJak se mohl změnit? Sám od sebe se nezmění.\nSám od sebe se nezmění, ale může ho změnit nějaká událost nebo někdo jiný. Například zkontrolujete konfiguraci služby, je OK, tak necháte službu znovu konfiguraci načíst – jenže mezi tím došlo ke změně konfigurace. Třeba to způsobí nějaký automat jako utilita pro Let's Encrypt. Nebo nějaká úloha z cronu, třeba něco jako logrotate. Možná s tou konfigurací bude takový nástroj dokonce pracovat „bezpečně“, takže odstraní původní soubor a pak tam nahraje nový. A zrovna v tom okamžiku, kdy tam soubor nebude, se ho pokusí služba načíst. A možná dokonce bude chytrá, a když zjistí, že konfigurační soubor neexistuje, vytvoří nový defaultní. Pak se dostane ke slovu ta utilita, která tam chtěla nakopírovat tu změněnou konfiguraci, a spadne, protože nepředpokládala, že tam ten soubor bude.\nAno, je to nepravděpodobné. Ale rozhraní, které je postavené na tom, že špatně funguje jenom občas, není dobré.\nAno, teoreticky lze vymyslet hromadu race, které jsou ale jen teoretické, protože v běžné praxi nenastanou, protože se ten systém používá určitým způsobem.\nTenhle způsob uvažování stojí za všemi problémy se souběhem akcí.\nJsou některé procesy, které (ačkoliv samozřejmě reagují na sigterm) tak mohou před samotným ukončením potřebovat ještě nějaké činnosti.\nPak to mají dělat v reakci ne ten signál. Jinak opět může dojít k tomu, že necháte provést akce před ukončením, ale k samotnému ukončení pak už nedojde.\n24. 5. 2016 11:54\nObávám se, že v systému, kde se budou služby chovat takto, tedy že si vytvoří default conf, že si odněkud vytáhnou starý conf pokud se jim ten nový nelíbí apod. těch races budete mít daleko víc a fakt by mě zajímalo, jak by třeba systemd řešil služby, které si, dle vašeho popisu, doslova dělají co chtějí. Takto se ty systémy neprovozují. Můžeme si vymyslet spoustu absurdních situací, kde to či ono nebude fungovat, ale v reálu se ty služby takto nechovají. Takový systém by se nedal používat.\n24. 5. 2016 12:51\nJak to tedy řešíte vy, aby služba nastartovala s vámi určenou a validovanou konfigurací, bez ohledu na to, co se děje okolo? Nebo to neřešíte a spoléháte na to, že jste jediný, kdo na tom systému reálně může provést nějaké změny, které službu ovlivní? Pokud je to ten druhý případ, jak dobře to vaše řešení škáluje?\nA co třeba cron nebo sudo – takové služby nepoužíváte, když si nevystačí se shellem, ale mají proprietární nástroj pro konfiguraci?\n24. 5. 2016 14:06\ncron má proprietární nástroj pro konfiguraci? Od kdy? crontab -e volá $EDITOR na kopii cron souboru z poolu. Klidně si vem jiný editor, změň soubor přímo v tom poolu a restartni crond.\nsudo totéž v bledě modrém.\nPokud je to ten druhý případ, jak dobře to vaše řešení škáluje?\nŠkáluje co? Jako že 30 lidí bude současně nastavovat jednu službu? To teda moc dobře neškáluje, protože tam často ani není 30 věcí k nastavení ;-).\nJak to tedy řešíte vy, aby služba nastartovala s vámi určenou a validovanou konfigurací, bez ohledu na to, co se děje okolo?\nNo kupodivu tak, že po instalaci služby a jejím nastavení udělám service sluzba start a ona, světe div se, běží. Pokud ji chci spouštět při bootu, tak chkconfig sluzba on. Dokonce úplně stejně po instalaci na systémem se systemd po instalaci služby a jejích nastavení udělám systemctl start sluzba, systemctl enable sluzba (a takové věci jako hraní si s mask / unmask raději nebudu komentovat - viz diskuse o tom, jak v systemd skutečně zabránit tomu, aby se nějaký služba spustila).\n24. 5. 2016 14:50\ncrontab -e i sudo jsou proprietární nástroje pro konfiguraci. Když budete přímo editovat příslušný soubor, může to dopadnout dobře, ale také nemusí. Postup, který jste popsal, je popis konkrétní implementace těch proprietárních nástrojů. Takže vám nestačí znát standardní unixové nástroje, musíte znát ještě postup pro tu kterou konkrétní aplikaci.\nProblém se souběhem může nastavit i v případě dvou konkurenčních přístupů, nemusí jich být dvacet.\nTvrdíte, že pořádná služba nepadá z ničeho nic a tedy nepotřebujete automatický restart procesů. Ale při správě služeb vám vůbec nevadí, že spoléháte na to, že to snad dobře dopadne – a kdyby se náhodou projevil nějaký problém způsobený souběhem, nevadí, prostě to zkusíte ještě jednou. Neměla by správa služeb být stejně spolehlivá, jako to vyžadujete od služeb?\n24. 5. 2016 15:06\njsou proprietární nástroje pro konfiguraci\nCo je na tom proprietálního? Oba nástroje jen zavolají editor (který dokonce ani nevláčejí sebou, prostě použijí ten který je uveden v proměnné prostředí, případně defaultní), předají mu soubor k editaci a po zavření editoru jen zkontrolují správnost a upozorní démona (v případě cronu). Nic proprietálního na tom nevidím, naopak je to krásná ukázka použití již existujícího. Ale dokonce ani tyto nástroje nemusíte použít. Můžete klidně editovat sudoers nebo crony ručně.\nTvrdíte, že pořádná služba nepadá z ničeho nic a tedy nepotřebujete automatický restart procesů.\nAle při správě služeb vám vůbec nevadí, že spoléháte na to, že to snad dobře dopadne – a kdyby se náhodou projevil nějaký problém způsobený souběhem, nevadí, prostě to zkusíte ještě jednou.\nJá jsem někde tvrdil, že to snad dobře dopadne a náhodou a že to zkusím ještě jednou? Prosím o citaci. Ne, já svůj systém znám. To, že se konfigurace a restart služby podaří, není náhoda. Možná pro někoho jo, ale takového člověka bych neoznačil slovem administrátor.\n24. 5. 2016 15:42\nProprietární je ten správný postup. Ručně to editovat můžu, ale není zaručeno, že to bude fungovat. Není to krásná ukázka použití existujícího, je to ukázka hacku, jak s omezenými nástroji docílit bezpečné změny konfigurace.\nKdyby to nebyly proprietární nástroje, nepotřebujete crontab -e a visudo, když oba dva dělají to samé.\nJá jsem někde tvrdil, že to snad dobře dopadne a náhodou a že to zkusím ještě jednou?\nTvrdil jste, že souběhy teoreticky nastat mohou, ale vy je neřešíte, protože to používáte určitým způsobem.\nNe, já svůj systém znám. To, že se konfigurace a restart služby podaří, není náhoda.\nOK, máte svůj malý systém, ve kterém znáte všechny vazby, konkurenční přístup řešíte tak, že si pohlídáte, abyste žádné konflikty nezpůsobil. Já mám raději, když problém konkurenčního přístupu vůbec nemůže vzniknout. A v komplexních systémech je to nutnost, protože tam nikdo nemůže znát celý systém a posoudit, jestli někde náhodou nevzniknou nechtěné interakce.\n24. 5. 2016 16:13\nCož ale vůbec neimplikuje to, že se to náhodou podaří a když ne, tak to zkusím ještě jednou. Pokud si z celého stavového prostoru vyberu jen ty stavy, ve kterých nastat konflikty nemohou a mezi těmito stavy se pohybuji, tak se mě ty konfliktní stavy netýkají.\nSamozřejmě. Malý systém. Když dojdou argumenty ... Mě by spíš zajímalo, jak se v produkční praxi stane, že nějakou službu budou konfigurovat dva a více adminů současně. Služba se typicky jednou nainstaluje a potom běží až do odstavení systému. Pokud nějaká služba potřebuje změnu konfigurace (což se mimochodem dá dosáhnout i tak, že se vedle nainstaluje služba s novou konfigurací a jen se zmigrují data), tak se pověří jeden konkrétní admin a ten rekonfiguraci provede. K žádnému souběhu nedojde.\nJestli je je vaší praxi běžné, že různí admini nastavují jen tak z plezíru různé služby do různých stavů a restartují je kolegům pod rukama, tak tomu se běžně říká sabotáž a s takovým "adminem" vyrazím první dveře a poženu ho třeba až na úřad práce (což teda v mém případě je jen do vedlejší budovy).\nA hlavně nevím, jak by jakýkoliv systém na světě mohl zabránit tomu, že nějaký admin nastaví službu do stavu A a druhý admin tutéž službu paralelně do stavu B. Výsledkem stejně bude nakonec buď A nebo B. Možná se to náhodně 50:50 trefí do zamýšleného stavu, ale za dobrý výsledek to nepovažuju.\nProstě ten souběh se musí řešit na úplně jiné vrstvě.\n24. 5. 2016 17:10\nPokud si z celého stavového prostoru vyberu jen ty stavy, ve kterých nastat konflikty nemohou a mezi těmito stavy se pohybuji, tak se mě ty konfliktní stavy netýkají.\nNejde tenhle princip rozšířit na celý software? Prostě si nadefinujete, že ho používáte jenom způsobem, ve kterých funguje správně, a chyby se vás tím pádem netýkají. Akorát nevím, jestli bude software to vaše rozhodnutí respektovat.\nMě by spíš zajímalo, jak se v produkční praxi stane, že nějakou službu budou konfigurovat dva a více adminů současně.\nJak? No třeba administrátor databáze potřebuje přidat úlohu do cronu, a administrátor poštovního souboru potřebuje přidat svou úlohu do cronu. A ejhle, oba konfigurují stejnou službu.\nBuďte rád, že stejný názor nemají třeba autoři bankovních aplikací. Že by prohlásili, že když vám mají přijít na účet dvě platby, přičte se vám buď jedna, nebo druhá, a neexistuje způsob, jak takovému konfliktu zabránit. Naštěstí ty způsoby existují, dva nejjednodušší jsou zamykání (před začátkem změny získám výhradní přístup, provedu změnu, a zámek vrátím), nebo verzování – načtu údaje s verzí, provedu změny, uložím verzi se zvýšenou verzí, pokud aktuální verze je nižší než nově ukládaná verze.\n24. 5. 2016 17:35\nA ejhle, oba konfigurují stejnou službu.\nAno, ale za dva různé uživatele, takže každy z nich si zavolá crontab -e nebo každý z nich bude editovat svůj vlastní soubor. Potom ale nebude mít typicky právo zrestartovat tu službu, takže pokud nebude mít inotify (což momentálně nevím, zda crond nad poolem má), tak se jeho změny neprojeví.\nBuďte rád, že stejný názor nemají třeba autoři bankovních aplikací.\nPředpokládám, že ze sebe vzájemně nemusíme dělat blbce. Pokud ano, tak polopatě: stavy A a B jsou vzájemně protichůdné a nedají se sloučit. Zatímco bankovní transakce jsou samostatné. Pokud dva různí admini budou nastavovat jeden systém, tak ten s 50% pravděpodobností skončí nastavený špatně.\nProto říkám, že tento problém je nutno řešit na jiné vrstvě a nezadávat adminům protichůdné požadavky na jednu službu.\n24. 5. 2016 17:44\nA co když ty dva požadavky A a B nejsou protichůdné a dají se sloučit? Třeba ta výše uvedená konfigurace cronu, pokud obě dvě úlohy mají běžet pod rootem (což je u správcovských úloh docela běžné).\nOtázka je, zda si ten zadavatel v danou chvíli uvědomí, že administrátor databáze i administrátor poštovního serveru asi budou požadavky řešit pomocí cronu. Dokonce ani zadavatel těch úkolů nemusí být jedna a táž osoba.\n24. 5. 2016 17:59\nTomu se potom říká, že levá ruka neví co dělá pravá. Opět to není asi to nejvhodnější prostředí pro provoz serverů.\nJinak k tomu prvnímu odstavci, k čemu směřuješ? Je to tak, že služba, která nemá rozhranní pro administraci, které by umožnovalo přidávat jednotlivé záznamy a hlídalo by si stav, tak stejně funguje tak, že se v nějakém editoru otevře soubor a po jeho zavření se zkontroluje a aplikuje. Pokud toto udělají dva různí admini ve stejný čas, tak vyhraje konfigurace toho, kdo ten soubor uloží jako druhý. No a ten první admin si toho buď všimne, nebo ne. Každopádně služba nebude v očekávaném stavu.\nNejsem si jistý, jestli by pomohlo, aby každá služba měla vlastní nastavátko, které transkakčně vyřeší konfiguraci paralelními adminy. Evidentně to v praxi není takový problém, aby se to muselo řešit. A pokud to někdo potřebuje řešit, třeba přidávat položky do konfigurace tak často, že hrozí souběh, tak na to jsou už roky hotová řešení, nepřistupuje se ke konfiguračnímu souboru přímo, ale konfigurace se provádí prostřednictvím jiné služby, která řeší mimo jiné i souběh. Kdo chce použít, může, kdo nechce, nemusí.\n24. 5. 2016 21:57\nJde o to, že to dokonalé konfigurační rozhraní „textový soubor editovatelný libovolným editorem“ má také svoje mouchy. A ta výhoda, že existuje spousta unixových nástrojů pro práci s textovými soubory, je také víceméně teoretická, protože málokdy použijete něco jiného, než textový editor. Nemluvě o tom, že rozhraní „textový soubor“ ani nedokáže službu informovat o změně, to je potřeba provést jiným způsobem – dotazováním, restartem služby, signálem, inotify…\nTakže tu sice máme univerzální konfigurační rozhraní postavené na textových souborech, ale to není dokonalé, takže je logické hledat lepší řešení. Nemusí to být zrovna systemd, a i kdyby bylo, přijde po něm zase něco dalšího.\n24. 5. 2016 22:15\nMate pravdu. Kurva, uz aby konecne do Linuxu integrovali registry a regedit (vyhradne s grafickym rozhranim). Co dela ten flakac Poettering?\nAz budou registry, nikdo se nebude v nicem hrabat a admina bude moci delat kazdy debil.\n25. 5. 2016 8:24\nJde o to, že to dokonalé konfigurační rozhraní „textový soubor editovatelný libovolným editorem“ má také svoje mouchy.\nTak jistě že má.\nA ta výhoda, že existuje spousta unixových nástrojů pro práci s textovými soubory, je také víceméně teoretická, protože málokdy použijete něco jiného, než textový editor.\nNo na konfiguraci, kde chci něco upravit, použiji typicky textový editor (krom takových onlinerů jako echo "neco" >> soubor.conf, které osobně nemám příliš rád). Ale ty ostatní textové nástroje jako grep apod používám jinak denně a častěji, než editor samotný (ale zase ne příliš často na konfiguráky).\nale to není dokonalé\nNic není dokonalé. Ani to lepší řešení nad konfiguráky by také nebylo dokonalé. Dokonce by přineslo své vlastní problémy, které před tím neexistovaly. Jak říká Murphy, vše se pokazí a pokazí se to v nejnevhodnější situaci.\nNevybavuji si jediné jednotné řešení konfigurace, které by někdy neselhalo (naposledy jsem se pokoušel konfigurovat NetworkManager čistě dle návodu a výhradně pomocí nástrojů k tomu určených - nevím proč, ale po třetí přidané statické routě to přestalo fungovat - takový nástroj je naprosto k ničemu). A potom je ten průser mnohem větší, než když se nějaký admin překlepne v jednom konfiguráku. Totéž je s tím systemd. Když se v initrc pokazí jeden skript, tak se v podstatě nic neděje a navíc každý admin má schopnost jej opravit nebo alespoň obejít. Když se pokazí něco v systemd, tak je admin většinou v prd...\n25. 5. 2016 8:38\nJako náhrada za nedokonalé řešení není potřeba dokonalé, stačí pouze lepší.\nKdyž se pokazí něco v systemd, tak je admin většinou v prd...\nMyslíte přímo v programu systemd, tedy v PID 1? Kdy jste se setkal s tím, že se tam něco pokazilo?\n25. 5. 2016 8:49\nNe, myslím v balíku systemd jako celek. Tak třeba se pravidelné kazí journald logy. LP sice tvrdí, že dělají maximum proto, aby to přečetlo i vadné logy a ale pravidelně se stává, že se rozbije (mimo jiné) index bootů a nelze se vrátit zpět před vadný log. (Jako ono to nějak obejít jde, lze si vypsat seznam uid všech bootů nalezených v logu a potom si zobrazit každý jednotlivý log, ale to asi není zamýšlené použití nástroje journalctl.)\nKdyž si spustím journalctl --verify, tak jsem zatím nenašel stroj, kde by nějaký log nebyl failed. Jsou to všechno zdravé stroje, které běží roky spolehlivě, fs je v pořádku atd. Prostě si to samo ničí vlastní soubory.\nNebýt možnosti forward to syslog, tak je admin bez logů.\n25. 5. 2016 9:20\nLogy sou prece zbytecny, podivej se do widli .. logu jak sracek, ale nic se z nich stejne nedovis, protoze se loguje kazda hovadina, ale to podstatny ne. Neznam taky widle, ktery by nemely v logu hromady chyb. Takze to ber tak, ze mas systemd-wintux.\nTím se ale systemd neliší od řešení bez systemd – tam jsou v jednotlivých komponentách také chyby.\nTy chyby s journald jsou nahlášené, má ty samé problémy také někdo jiný?\n25. 5. 2016 9:30\nTo si děláš srandu, nebo máš klapky na očích? Jistě že jsou nahlášené a hlásí se už roky. Některé bugy journald skončily označené jako notabug (z toho lze vyvodit, že vadné logy jsou vlastnost), některé smazané apod, k některým napsal povídání i LP apod.\n25. 5. 2016 9:43\nMne nezajímají hlášené nějaké chyby. Vy jste psal o své vlastní zkušenosti, tak by mne zajímalo, jestli ty vaše konkrétní chyby jsou nahlášené.\nNěkteré bugy journald skončily označené jako notabug (z toho lze vyvodit, že vadné logy jsou vlastnost),\nNe, to z toho vyvodit nelze.\nněkteré smazané apod, k některým napsal povídání i LP apod.\nNic z toho ale nevypovídá o reálných chybách journald.\nPokud k tomu chcete přistupovat způsobem, že všechno, co je nahlášené jako chyba journald, je automaticky chyba journald, protože systemd, nemáme se o čem bavit. I v této diskusi je vidět, že někteří lidé prostě hodně nemají rádi systemd a svedou na něj cokoliv, s největší radostí pak na systemd svedou to, že mají obě ruce levé. Nemyslím si, že by se tihle lidé bugzille vyhýbali. Proto se ptám konkrétně na ty vaše chyby, protože u těch se asi můžu spolehnout na to, že je to opravdu vlastní zkušenost a ne „někde na internetu jsem četl“, a na to, že popis chyby bude plus mínus odpovídat realitě a popisovat skutečný problém. Kdybych si chtěl číst pohádky o tom, jak je všechno špatně, protože všichni jsou debilové, přečetl bych si nějaký komentář od j.\n25. 5. 2016 10:03\nProsím? Takže bugy na vadné logy journald nejsou o chybách journald? Takových hlášení jsou v bugzilách desítky. Nebudu tu chybu hlásit ještě jednou sám za sebe (snad stačí nahlásit chybu jednou, není potřeba hlásit tutéž chybu (chybu stejné třídy) v každé jednotlivé instanci), jen proto, aby to skončilo jako duplicate nějakého jiného bugreportu označeného jako notwantfix, notabug apod.\nTo za prvné. Za druhé, a tady opět očekávám nějakou jízlivou reakci. Proč bych měl psát bug na něco, co se projevuje ve 100% případů? To autoři nebo testeři neodhalili? Nebudu ani psát bugreport na ten NetworkManager. Pokud nikdo z autorů nevyzkoušel přidat více statických rout, tak už jen toto je pro mě signálem ten soft prostě nepoužívat, protože při takovém způsobu vývoje a (ne)testování bych pravděpodobně hned po té narazil na další "vlastnost", kterou se autor neobtěžoval vyzkoušet. Toto je pro mě při výběru softu mimořádně důležité. Naopak si vážím projektů, které na férovku zruší z plánovaného release ohlášenou vlastnost, protože sami nejsou spokojeni s tím, jak ten kód vypadá. Ten projekt je dlouhodobě stabilní a je to právě důsledkem tohoto způsobu myšlení autorů.\nv této diskusi je vidět, že někteří lidé prostě hodně nemají rádi systemd\nUž jsem tu někde psal, že zrovna journalctl považuji za to lepší ze systemd a dokonce jsem oponoval lidem, kteří se obávali toho binárního formátu. V různých db mám hromadu TB dat a není nejmenší důvod, aby se ta data kazila jen proto, že jsou ve formátu té konrétní db. Proč se kazí logy journald neví, nevyčuměl jsem to z ničeho, vše ostatní v pohodě běží. Byl bych rád, kdyby nástroj jako journald fungoval správně.\n25. 5. 2016 10:35\nTakže bugy na vadné logy journald nejsou o chybách journald?\nNe, hlášení chyby o vadném logu journald nemusí znamenat chybu v journald. Už jsem viděl asi tak milion hlášení, kdy někdo hlásí chybu v nějakém programu, a chyba je přitom v jiném programu, mezi židlí a klávesnicí, nebo o chybu vůbec nejde.\nNebudu tu chybu hlásit ještě jednou sám za sebe\nTak se pak nedivte, že ta „chyba“ není opravená.\nbugreportu označeného jako notwantfix, notabug\nK takovému označení mohou vést různé důvody. Vývojář si nemyslí, že jde o chybu, a oznamovatel ho o tom nedokáže přesvědčit. Vývojář nedokáže chybu reprodukovat a oznamovatel už nijak nereaguje. A nebo také to, že vývojář je hlupák a zjevnou chybu zazdí. S tím posledním opravdu nic neuděláte, ty první dva případy může pomoci vyřešit někdo, u koho se také chyba projevuje, a kdo to dokáže popsat lépe nebo bude schopen spolupracovat na opravě té chyby.\nProč bych měl psát bug na něco, co se projevuje ve 100% případů?\nReakce bude jízlivá, protože tohle si nic jiného nezaslouží. Stačilo by uvědomit si, že nejste pupek světa, a že to, že se vám chyba projevuje ve 100 % případů, neznamená, že se projevuje všem. Klidně je možné, že jste jediný, komu se projevuje.\nTen projekt je dlouhodobě stabilní a je to právě důsledkem tohoto způsobu myšlení autorů.\nJako příklady uvádíte systemd a NetworkManager. Oba jsou to komplexní systémy, které vstupují do oblasti, kde panuje pěkný nepořádek, a snaží se ten nepořádek nějak uklidit a postupně proměnit v nové čisté řešení. Nebo-li se musí poprat se spoustou podivuhodných hacků a zároveň se snažit nespadnou do stejné pasti. To není věc, kterou je možné obecně testovat, protože vždy přijde někdo s nějakou novou kombinací hacků, kterou nikdo neotestoval. To nemůžete srovnávat s „jednoduchými“ aplikacemi typu databáze nebo souborový systém (přičemž zde „jednoduchý“ a „komplexní“ nijak nesouvisí s tím, jaké jsou nároky na autory – je to prostě jiný typ problému).\nProč se kazí logy journald neví, nevyčuměl jsem to z ničeho, vše ostatní v pohodě běží. Byl bych rád, kdyby nástroj jako journald fungoval správně.\nTo by nepochybně byli rádi i autoři journald. To, že nedokážete zjistit, v čem je problém, je pochopitelné a nevytýkám vám to. Ovšem je trochu zvláštní to samé pak vytýkat jiným (autorům journald), ale dá se to pochopit, oni jsou „majitelé“ journald, ne vy. Ale když tu chybu nenahlásíte, nemůžete se divit, že ji nikdo neopraví. To, že se ta chyba projevuje vám, opravdu neznamená, že se musí projevovat i někde jinde. Proto je důležité, aby chybu nahlásil někdo, kdo je ochoten spolupracovat na jejím odstranění – v první řadě je potřeba v spolupráci s autorem přijít na to, co je ve vašem prostředí specifické. Když už se podaří dojít do stavu, kdy vývojář dokáže chybu reprodukovat, bývá oprava většinou triviální.\n25. 5. 2016 10:56\nNe, hlášení chyby o vadném logu journald nemusí znamenat chybu v journald.\nSamozřejmě, že nemusí. Ale pokud jsou nahlášeny s tím, že všechno kolem je zdravé a jediný problém je s logy journald, tak ano, stále to nemusí být problém journald, ale je to nejlogičtější začátek hledání příčiny. Jenže z té bugzilly není často cítit ani žádná snaha to začít řešit.\nStačilo by uvědomit si, že nejste pupek světa\nUvědomuju. Proto taky takový software nepoužívám. Pokud mám tu možnost. Problém se systemd patrně časem vyřeším tak, že postupně přejdu na FreeBSD. Potenciální bariera je mnohem menší, než jsem čekal (prakticky nulová), některé služby (u kterých to bylo výhodné) už jsem tam popřehazoval a takovou pohodu s prací s OS jsem dlouho nezažil. Pokud se časem někdo zblázní i ve FreeBSD, stále bude mnoho projektů, kam dál.\nTo není věc, kterou je možné obecně testovat, protože vždy přijde někdo s nějakou novou kombinací hacků, kterou nikdo neotestoval.\nNevyčítám NetworkManageru, že nepracuje správně na nějakém hraničním routeru s milionem portů v nějakém složitém stavu. Vzal jsem čistou minimální instalaci enterprise distra, vzal jsem do ruky manual a jel jsem podle manualu. První věc, kterou u síťového stroje chcete udělat je nastavit síť. Nepovedlo se. Na kompletně čisté instalaci, která je ve stavu, který je plně v režii autorů distribuce. Možná je chyba v dokumentaci, nevím, je mi to jedno. Network Manager používat nemusím a nebudu. Se systemd je to poněkud horší.\nTo by nepochybně byli rádi i autoři journald.\nZ těch bugreportů bohužel nic takového cítit není.\nTohle opět krásně vystihl Michal Kubeček (který, tuším, přímo pracuje v jedné enterprise distribuci):\n25. 5. 2016 11:36\n@Heron: Ja ta obdivujem. Venovat tolko usilia a snazit sa logicky vysvetlit nieco cloveku, co ma evidentne casu jak invalidny dochodca (a neustale vo svojich "prispevkoch" ignoruje vsetky logicke argumenty a snazi sa svoje subjektivne postoje vydavat za univerzalne pravdy)...\nJa na to nikdy nemam nervy, vzdy po par odpovediach usudim, ze ti co su schopni pochopit, uz moje stanovisko davno pochopili - no a ti ostatni to pravdepodobne nepochopia nikdy (alebo im o pochopenie vobec nejde).\n25. 5. 2016 12:12\nProblém se systemd patrně časem vyřeším tak, že postupně přejdu na FreeBSD.\nJo, to muzete. Potiz ale je, ze spousta softu v BSD pochazi z Linuxu a v Linuxu se mnozi soft, ktery je na systemd zavisly. Portace pak znamena, ze ta zavislost z toho musi byt nejak vykuchana, coz muze byt stale slozitejsi.\nA pro spoustu uzivatelu prechod na BSD neni zrovna jednoduchy. Maloktere BSD distro ma instalator tak snadny, jako ma dnes Linux. A pokud ho ma, tak vyvojari bohuzel obvykle prestali podporovat 32 bity, kterych okolo lezi porad jeste hodne.\nPotiz ale je, ze spousta softu v BSD pochazi z Linuxu a v Linuxu se mnozi soft, ktery je na systemd zavisly.\nToho jsem si vědom, ale nevím, jak danou situaci řešit. A nejsem sám. Víceméně doufám, že dlouhodobě rozumné projekty, které používám, budou rozumné i v budoucnu. Zaručené to nemám, jako nic na světě.\n25. 5. 2016 12:08\nOno je uplne jedno, ci je to chyba. Dulezite je, ze poskozeni zurnalu nejspise zpusobi jeho necitelnost a takovyhle system by se hlavne nemel spolehat na to, ze bude vzdy slunecne pocasi a vysoky rosny bod. Cilem by mela byt alespon jakasi citelnost logu i v pripade, ze dojde k problemu. A to zajisti textovy format mnohem spolehliveji, nez jakysi podivny format binarni. Textovy format pak zajisti i to, ze ty logy muzu zkusit ciste kdecim a nejen pomoci nejakeho bazmeku, ktery dodavaji se systemd.\nTohle vůbec nezávisí na tom, zda jde o textový nebo binární formát. I textový i binární formát může být udělaný tak, že se bude z chyby velmi špatně zotavovat, ale i tak, že chybu správně detekuje a co nejdřív se z ní zotaví. Naopak u čistě textového formátu (ne žádné XML apod.) se snadno může stát, že chybu vůbec nepoznáte.\njournalctl umí logy textově zobrazit i exportovat, takže to „kde co“ můžete použít na ten vyexportovaný soubor.\nAno, journald by měl zajistit, že i v různých podivných situacích budou logy dostupné. Jenže tady je to plné komentářů, jak s tím všichni mají špatné osobní zkušenosti, jak je na to spousta bugreportů, ale odkaz na bugreport nikde, detailnější popis chyby nikde. Mně je to podezřelé. Já když se potýkám s takovouhle protivnou chybou, znám odkaz na bugreport, a/nebo popíšu detaily, v jaké to nastává situaci, jak se to projevuje… Kdybych chybu popsal způsobem „nic nefunguje, nikomu to nefunguje, nikoho to nezajímá a je zbytečné to hlásit“, připadal bych si, že mi vůbec nejde o řešení té chyby, a že jsem si prostě jenom přišel zanadávat.\n25. 5. 2016 13:47\nhttps://www.google.cz/search?q=journald+corruption - cca 115 milionů výsledků... to bude nějaká blbost u pár uživatelů, ne? Momentálně mám po ruce jediný stroj se systemd a světe div se, journalctl --verify tvrdí, že má nějaké soubory poškozené. Se strojem jinak žádné problémy nejsou, v podstatě na něm nic neběží, jen se na něm testoval upgrade na SLES 12.1. Jinak szstemd má momentálně otevřených 312 issues, nejstarší starý skoro rok, nikomu se to nechce řešit... Tomu říkám kousek softwaru ;)\nTady uz je jen jedine mozne reseni. Konecne vymyslet stroj casu a zapichnout Poetteringa Widlemi jeste v kolebce.\nI textový i binární formát může být udělaný tak, že se bude z chyby velmi špatně zotavovat, ale i tak, že chybu správně detekuje a co nejdřív se z ní zotaví.\nAha. Tak tady bych uvital priklad txtoveho formatu, ktery se z vhyby spatne zotavi tak, ze uz nepujde precist a opravit ani hexaeditorem.\nExport logu journactl jsou mi na dve veci, kdyz jsou poskozene a nejdou exportovat.\n25. 5. 2016 15:01\nČíst a vylepšovat to hexaeditorem samozřejmě můžete, ale pochybuju, že dokážete říct, kolik tam před poškozením bylo platných položek – zda žádná, jedna, dvě nebo tři.\n25. 5. 2016 15:11\nJo, ale tohle se mi leda tak rozhodi, neco mozna neprezije, ale v podstate z toho muzu porad neco vycist. Co vyctu z binarniho blobu? Nehlede na to, ze textak, jako mate v tom vasem pripkladu, se na logy v Linuxu asi moc nepouziva. Mozna, ze to tak nejaka apklikace dela, ale typicke to neni.\n25. 5. 2016 15:50\nZ binárního formátu přečtete úplně to samé, jako přečtete z textového. Akorát tomu binárnímu formátu musíte rozumět, stejně jako rozumíte tomu textovému. Kdyby ten textový soubor nebyl v ASCII ale nějaké obskurní znakové sadě (třeba ROT13(ASCII)), bude to pro vás také binární blob.\n25. 5. 2016 15:52\nKdyby žily ryby v p*deli, nebyly by rybníky.\n25. 5. 2016 16:07\nZ binárního formátu přečtete úplně to samé, jako přečtete z textového. Akorát tomu binárnímu formátu musíte rozumět, stejně jako rozumíte tomu textovému.\nAha. Akorat, ze binarnimu formatu nikdo nerozumi tak jako textovemu. Takze kdyz mam textovy format, tak to v necem otevru a ctu. Kdyz mam format binarni, tak stravim pul dne hledanim dokumentace a jejim studiem a dalsiho pul dne pokusy o desifrovani poskozeneho logu dle nastudovaneho materialu. Pricemz si muzu byt jisty, ze to vse do priste zapomenu a budu moci zacit znovu, coz se mi u textaku tezko stane. A pokud v tech logach je zapnuta komprese, tak to muzu rovnou zabalit, protoze zmena jedineho bitu ma dalekosahle dusledky, coz u textaku nemuze nastat.\nOpravdy me presvedceni o vyhodach binarniho formatu sili s kazdym vasim prispevkem.\n25. 5. 2016 16:14\nTakže rozdíl není v tom formátu, ale ve vašich schopnostech. Na tom se shodneme.\n25. 5. 2016 16:32\nTak jiste, az ty logy budou obsahovat nahodna cisla, bude rozdil v tom,ze je diky nedostatku jasnozrivosti nedokazu interpretovat.\nNavrhuji, aby skolni ucebnice nadale byly tisteny v binarnim formatu, aby pristi generace byly na systemd lepe pripraveny, nez ja, stara struktura, co se ucila cist akorat normalni text.\n25. 5. 2016 17:38\nJinak to nejde, sice můžeme použít překladače obrazu, ale v celým systému Matrixu je moc informací, časem si zvykneš, už to ani nevnímám, vidím jenom blondýnu, brunetu, zrzku… hele a co si dát panáka?\n25. 5. 2016 17:33\nTohle už se fakt nedá říct jinak, slušnost stranou, Jirsák, ty jsi normální kokot. Jestli věříš jen polovině toho co píšeš, tak patříš do ústavu. To je jako říct, že přečíst zašifrovanou zprávu bez klíče je jen o schopnostech a v podstatě by to měl každej umět, nebo je debil. Ale primární účel logu je, aby BYL ČITELNÝ! Raději uvidím v 1000 řádkovým logu 10 řádků nesmyslů, než abych kvůli těm 10ti rozdrbaným řádkům neviděl vůbec nic. Takže řeknu ti to znova. systemd je někde mezi alfou a betou, v produkci nemá co dělat, LP je arogantní fracek a jestli to takhle půjde dál, Linux půjde do prdele a každej, kdo potřebuje stabilní OS minimálně na servery, tak uteče k nějakýmu BSD. Mimochodem, instalace OpenBSD je sice v CLI, ale jinak je tak jednoduchá, že by to zvládla i moje malá dcera, kdyby jí někdo přečetl a přeložil co to píše a co to chce.\n25. 5. 2016 17:41\nNeučí se rozdíl mezi kódováním a šifrováním v 1. semestru všech IT škol?\n25. 5. 2016 17:59\nA do které kategorie se dá zařadit kódování bez rozumné dokumentace? Buď je to dementní kódování, nebo je to šifrování ve stylu "security through obscurity"? Substituční šifra je ve své podstatě taky jen kódování. Nic to nemění na tom, že když se něco pokazí, jsem prostě v tu chvíli v zadeli. Mimochodem, systemd po nějaké aktualizaci dokonce nedokázalo přečíst svoje vlastní logy z minulé verze. Tak to má vypadat? Ne, děkuji. Takhle by to opravdu nešlo. Prostě jsi pro mě kretén, kterej se zamotal do své vlastní blbosti a teď jsi se dostal do stavu, že za žádnou cenu nechceš vypadat jako debil, což si o tobě každej normální člověk myslí víc a víc s každým tvým dalším příspěvkem.\n26. 5. 2016 10:34\nBinární formát pro logování je výhodnější v úspoře paměti a rychlejším zápisu, takže se sníží možnost ztráty dat. Ono zapsat "03:25:38.22" nebo 0x03253822 je 11B vs. 4B.\nZtráta dat se v bináru řeší líp, padne potřeba ASCII/UTF8, která tě hodně omezuje např. v samoopravným kódu, crc, odlišení hlavičky atd.\nNečitelnost v texťáku nevadí, pokud máš možnost tu binárku vytáhnout ze stroje ven a prohnat převodníkem. Taky to tak dělávám, XML s popisem chyb + binárka, kterou přechroupe prográmek.\nKdyž máš na logování vyčleněno 1kB zálohované RAM v embedded systému, jinou možnost, než binárka a přechroupávač na PC nemáš (událost + modul + datum + čas + závažnost události dají klidně jenom 20B).\n26. 5. 2016 17:55\nKdyž máš na logování vyčleněno 1kB zálohované RAM v embedded systému, jinou možnost, než binárka a přechroupávač na PC nemáš.\nTak vetsina lidi tady pri diskusi o logovani asi nema na mysli embeded systemy, ale vetsi stroje, tak od netbooku vyse. Pokud mate embeded system, tak si nejsem jisty, jestli zrovna systemd je ta idealni volba. Porad to bobtna a vtahuje to do sebe stale dalsi funkce, ktere predtim delalo neco jineho. Pokud chcete logovat binarne, asi by bylo lepsi si to resit nejakym vlastnim bazmekem, pokud takova vec uz nekde mimo systemd neexistuje.\n26. 5. 2016 18:52\nViky (neregistrovaný) ---.ipv4.broadband.iol.cz\nJo, to jsou taková typická zařízení, na kterých obvykle běží Linux - s 1 KB RAM.\n26. 5. 2016 16:41\n"Z binárního formátu přečtete úplně to samé, jako přečtete z textového."\nAk je kompresovany (co je u binarneho formatu nutne), tak celkom urcite nie :)\n26. 5. 2016 17:36\nTo by me jirsak zajimalo, jak si prectes soubory ze zipu, kterej je nakopnutej ... napriklad ... fakt jo ... aha, nejde co? Protoze abys moh cist, potrebujes tu cast, ktera precist nejde, takze si neprectes ani tu, co fyzicky cist de.\nTos ale zapomel, ze systemd ma patentovenej stav C, ve kterym je cast z A a cast z B, takze se budou dit veci, ktery nebude chapat ani admin a, b dokonce ani c.\n24. 5. 2016 17:43\nNezapomněl. systemd používám, vím co dokáže. ;-) Momentálně se snažím pochopit poslední changelog a to, co lennart boys vyvedli s odstřelením procesů po odhlášení uživatele a jaké je podle nich tedy správné řešení (tedy kromě toho nastavit si logind, protože se změnil default - bůh ví jak dlouho tam tam možnost bude). Prostě rozbili desítky let funkční nohup a screen / tmux. Přečetl jsem 5 man stránek a nechápu, jak se to má the systemd way nahradit. To, že taková nuance systemd-boys od nikdy nezajímala vím, ale někdy bych chtěl pro ukojení vlastní perverze zjistit, jaká je podle nich ta správná cesta.\n24. 5. 2016 19:36\nSpravna cesta je jednoducha, co je to screen? To nikdo nepouziva. Konec diskuse, not a bug.\n24. 5. 2016 19:49\n# apt install libpam-systemd\n$ cat ~/.config/systemd/user/tmux.service:\na nastavit spouštění po loginu:\n$ systemctl --user enable tmux\nFunguje. Ať si každý sám za sebe rozhodne, jestli je to pro něj ok.\nJak to spustím interaktivně pouze když chci ne přímo po startu?\nSystemd věci rozbíjí a nedává možnost náhrady svou cestou. Diktuje často jednu cestu, když admini jsou zvyklí na univezálnost a možnost udělat to jinak v případě potřeby. Unifikace vede k "Tesco kvalitě"\n25. 5. 2016 11:25\nTam je problém v tom, že tmux sice můžete spustit kdy chcete, jenže ve chvíli, kdy se z daného stroje kompletně odlásíte (všechny vaše session - což je typicky jen jedna session, právě ta, ve které chcete nechat spuštěný ten tmux / screen i po odhlášení ze ssh), tak systemd všechny vaše procesy zabije. Takže i ten tmux / screen. Dá se to vyřešit nějakým nastavením logind a použitím systemd-run. Nezkoušel jsem, nepátral jsem. Chci mít tmux nastartovaný trvale (v tomto případě tedy od prvního přihlášení).\n24. 5. 2016 17:13\nJirsak, ty demente, crantab -e nedela nic jinyho, nez ze spusti textovej editor nad konfigurakem ... A jak bylo receno, libovolnej editor deklarovanej systemem, ne nejakej zaintegrovanej svuj.\n24. 5. 2016 11:00\nJasne ze by to slo. Staci prepsat vsechen SW aby konzole komunikovala se serverem pres d-bus :). A je to. Ne samozrejme si delam, pr*el.\nV pripade toho Oracle to dnes funguje tak, ze spustite sqlplus a ten spusti process oracle jako syna. Tomu synovi preda nejake parametry pres environment, a pak s nim komunikuje pres presmerovany stdin/stdout. Pekne "unixove". Ta databaze bezi takovem single-user mode, kdy je mozne menit nektere parametry anebo spustit jeji restore. Pokud pak zadate urcity prikaz tak ze syn odforkuje a stane se samostatnym demonem.\nTo ze by nekdo tohle prekopal kvuli tomu, aby mohl byt systemd (dbus) prostrednikem, mezi konzoli a demonem, to je totalni sci-fi. Hadam, ze ani ostatni databaze na tohle nebudou chtit pristoupit.\n24. 5. 2016 11:07\nStaci prepsat vsechen SW aby konzole komunikovala se serverem pres d-bus\nTohleto nevyslovujte ani ze srandy. Už dneska se najdou magoři, kteří tohle vzali vážně (naštěstí se lze jejich výtvorům vyhnout), čím méně jich bude, tím lépe.\n24. 5. 2016 12:07\nJo, tovizejo jirsak, mokrym snem kazdyho admina je, aby se mu do databaze sralo systemd ...\nNormalni init na STOP sluzbu ZASTAVI.\n24. 5. 2016 10:11\nV objektových systémech se to řeší tak, že rozhraní zajišťující tyto akce jsou metody bez parametrů, objekt si konkrétní parametry načte z db, či konfiguračního souboru, který se určí při vytvoření objektu. Nepotřebujete pak žádné skripty, které říkají, jak se co se má dělat, ale jen konfigurační soubory, které říkají, s čím se má pracovat. Logika chování pak existuje jen v jediné kopii a aplikace je přenositelná mezi všemi systémy, které implementují toto rozhraní.\nV dobách kdy vznikala filosofie Unixu, takové paradigma ale neplatilo, bylo stále ovlivněno zpracováním programů na štítcích, kdy jste vzal jednu krabici štítků a tu strčil do třídičky a výslednou sadu štítků strčil do sčítačky. (roura :-)))\nKulturní vzorce chování se jen tak nemění.\n24. 5. 2016 12:49\nHerone, asi takhle. Když jsem po devíti letech profi vývoje SW s koncem WinXP přešel na Linux začal si tam oťukávat programování, tak co mě odradilo od démonů bylo právě googlení, jak napsat init script, co kde změnit a co a proč tam je to, co tam je. Naprosto zbytečný.\nNavíc pokud pro init.d existuje šablona skriptu a měníš v ní jenom parametry, co by se stalo, kdyby ta šablona prostě byla program, který si ty parametry vycucne z jednoho nebo dvou řádků v konfiguráku a udělá to stejný?\nA problém je, že každý napsaný řádek zvyšuje riziko chyby. Ať je to skript, nebo kus programu. A i přiohnutý modul podle šablony se musí otestovat, takže unit testy nebo práce tesťáka navíc...\n24. 5. 2016 13:13\nKdyby obsahoval jenom tohle, tak bych ani nepípl.\n24. 5. 2016 13:23\n> Ať je to skript, nebo kus programu. A i přiohnutý modul podle šablony se musí otestovat, takže unit testy nebo práce tesťáka navíc...\nTím chceš říct, že když máš start/stop dělaný za pomoci systemd, tak tu funkcionalitu netestuješ???\n24. 5. 2016 14:09\nco by se stalo, kdyby ta šablona prostě byla program, který si ty parametry vycucne z jednoho nebo dvou řádků v konfiguráku a udělá to stejný?\nNestalo by se nic. Viděl jsem implementace, které fungovaly přesně takto. V rc skriptu byl jen nutný obal (v podstatě je source jiného skriptu) a ty dva řádky se tam napsali v podstatě jako argument nějaké funkce obalené nějakými dalšími drobnostmi (v podstatě definice fce, která se snaží tak nevypadat).\nStart a stop akce tvého programu předpokládám testuješ vždy. V čem je rozdíl, když se ta start akce zavolá pomocí systemd a nebo pomocí skriptu v bashi?\n25. 5. 2016 9:29\nmartin.k (neregistrovaný) ---.redhat.com\ntak se mrkni, jak vypadaji init skipty v bsd:\n# REQUIRE: DAEMON LOGIN FILESYSTEMS\n... a je to furt shell. to, ze v nekterych distibucich bylo zvykem prasit superdlouhy init skripty se spoustou boilerplate kodu neni problem initu, ale tech distribuci.\n25. 5. 2016 15:20\n.... strasnej problem ... a narozdil od toho srace to vazne nastartuje nebo zastavi presne podle ocekavani.\n27. 5. 2016 11:32\nDotyčný je asi dobrý v psaní toho svého programu, ale v psaní shell skriptů bude spíš průměrný nebo podprůměrný.\nProgramátor, který umí jen jeden konkrétní jazyk, je kodér a ne programátor. Je řada kvalitních jazyků, které jsou užitečné v konkrétních kontextech. Arduino si nadatluju v C, pro ovládací aplikaci vezmu třeba Qt/C++, pro přenositelnou vokýnkovou aplikaci vezmu Javu, jednoduché webovky k tomu udělám v PHP a spouštěcí skripty v BASHi. Jazyky jsou si v principech podobné, stačí se učit "dialekt", něco ze syntaxe a sémantiky.\nProč by měl svůj čas ztrácet tím, že bude bastlit nějaký skript\nProtože shellové skripty jsou běžně používaný standard, stejně to potřebuje při práci v konzoli, a hlavně jsou univerzální. Kvůli nějakým startovacím skriptům se nemusím učit sémantiku a syntaxi dalšího jazyka, který nikde jinde k ničemu nevyužiju. Použiju to, co je spolehlivé, odzkoušené a standardní. Není potřeba psát žádný speciální parser, nemusím se učit syntaxi a semantiku něčeho, co nikde jinde nevyužiju.\nNemohl by ten čas využít lépe?\nAno mohl, místo učení se jednorázově použitelného jazyka nějakých "jednotek" se naučím lépe psát v shellu, který je univerzální.\n27. 5. 2016 14:35\nJá jsem psal, že dotyčný programátor bude průměrný nebo podprůměrný v psaní shell skriptů – a vy jste k tomu doplnil, že bude také průměrný nebo podprůměrný v C, Qt/C++, Javě a PHP. Já dodávám, že pokud to dobře dopadne, bude nadprůměrný v tom, v čem píše ten svůj program – ani ne celý jazyk plus platformu, ale tu část platformy, kterou pro svůj program používá.\nMezi „být dobrý programátor“ a „umět jazyk“ je rozdíl třeba jako mezi „znát pravidla šachů“ a „být dobrý šachista“.\nstejně to potřebuje při práci v konzoli\nJá při práci v konzoli rozhodně bash znát nepotřebuju. A naopak neznám init systém, který by jako shell používal zsh.\nKvůli nějakým startovacím skriptům se nemusím učit sémantiku a syntaxi dalšího jazyka, který nikde jinde k ničemu nevyužiju.\nSyntaxe je to nejmenší. Sémantiku se učit musí, protože init skripty nejsou jen tak nějaké skripty nezávislé na prostředí. Init skripty jsou komponenty daného init systému, obecně nepřenosné mezi init systémy – a pouze shodou okolností mají stejnou syntaxi, jako nějaký shell.\n24. 5. 2016 8:29\nTo je problém Unixu, který má zakódovaný v DNA, je to bashismus, tedy řešení všeho pomocí pár atomických funkcí s hojným používání copy and paste, čímž přirozeně vzniká velká redundance kódu a systém se stává nemodifikovatelný. Udržuje se ale dobře, jako každý spagetti kód, protože všechny potřebné změny lze udělat v blízkém okolí místa, které jste identifikoval jako relevantní. Souvislosti vás zajímat v danou chvíli nemusí, protože ty se projeví samy a ty pak následně zalátáte jinde. Nemusíte hledat to jedno místo, kde se nachází definice, mezi mnoha jinými definicemi (nevýhoda malé redundance kódu)\n28. 7. 2018 9:27\nO (neregistrovaný) ---.starnet.cz\nKdyž jsem začínal s Linuxem, prohlížel jsem si web, LibreOffice a trochu programování. No to byl SysV nebo upstart (už nevím) a později jsem trochu použil ten upstart ale nic jsem s ním jiného nedělal než vypnul nějakou službu bránící v restartu (nebo co dělala to už také nevím). Až poté jsem využil systemd a to už byl všude.\n23. 5. 2016 10:17\nProč by to uspávání měl řešit systém nebo init? Je na aplikaci, aby si řekla, co (ne) potřebuje, ne? Jenom DB server ví, kolik má zrovna požadavků, jak velký má tabulky, ... a musí si žádat o to, co potřebuje.\nS tohle logikou systém na serveru pro IZS systém vyhodnotí, že minimum požárů je v pondělí od dvou do pěti ráno a sestřelí komunikaci s hasičárnou. A zrovna bude bouřka a blesky zapálí pět baráků naráz...\nNa systému je, aby přiděloval čas, paměť,... Na initu je, aby ten systém naběhl a když spadne, aby ho nahodil znovu a informoval admina, že je možná problém. Věštění požadavků obecnýho .elf souboru ani uživatele nemá v popisu práce ani jeden z nich.\n23. 5. 2016 11:17\nProtože "doing one thing and doing it well".\nOno těch databází může běžet více, a z hlediska nadhledu nad celou serverovnou a konkrétního provozu může být optimální jiná strategie, kterou supervizor serverovny díky adaptivnímu algoritmu teprve objeví, například poběží více variant s kombinacemi databází, tak aby databázové servery byly rovnoměrně vytíženy, integrida dat se vyřeší automatickou replikací. Myslet si, že nějaký admin to od stolu vymyslí, je bláhové (problém obchodního cestujícího).\nV době kdy automobily budou jezdit bez řidičů, tak admini budou manuálně určovat, co kde poběží v serverovně. Absurdní představa.\nS nárůstem datových toků se stejně dojde zase k majoritní funkci, kdy daný požadavek bude zpracován současně několikrát, a za správný výsledek bude brán ten, který vyjde vícekrát, nebude pak vadit, že část serverů třeba nebude v dané chvíli fungovat.\nKaždý komplexní organismus je založen na toleranci chyb, nikdy se nepředpokládá, že všechny části fungují bezchybně.\nProto se nebude hledat konkrétní chyba na serveru, ale server se automaticky, na základě majoritní funkce přepíše obsahem serveru se "správným" výsledkem, restartuje a zařadí do poolu funkčních serverů, odkud byl po chybě vyňat. Když správně poběží 80% serverů, bude to stačit. Logy nebudou potřeba, systém se takto sám opraví. Jen občas se do sytému uměle zavedou kmenové servery, u kterých je zaručena správnost z vnějšku systému, aby nedocházelo k degeneraci systému.\nBudoucí adaptivní algoritmy jistě využijí analogických strategií, jako je třeba apoptóza buněk, třeba právě ve spojitosti s majoritní funkcí navázanou na řešené úlohy a jejich výsledky.\nA aby toto bylo možné, stejně dospějete k nějakému "systemd" na úrovni serveru, a supervizoru na úrovni celého organismu serverovny, který klidně může být distribuovaný.\n23. 5. 2016 11:36\nNo a. Když bude určitý počet požárů najednou, tak hasičů bude málo i tak. Prostě zaručit, že něco nevyhoří nelze. V případě hasičů jde o daňový podvod státu, který aby vylákal peníze, tvrdí, že to lze, že je schopen zajistit nějakou 100% jistotu. 100% jistota je vždy podvod.\nJinak, ale hasičárna se má periodicky dotazovat, mám zasáhnout, tím bude udržovat servery v činnosti. Zásahové oblasti hasičáren se mají překrývat, tím se dosáhne větší robustnosti systému a nebude závislý na jediném serveru. Dotazovaných ústředen by mělo být více, aby se vyloučila i jejich porucha.\nAnalogicky funguje apoptóza buněk, která řídí dostupné zdroje v organizmu.\n23. 5. 2016 11:43\nAno, aneb vytlučeme klín klínem\n23. 5. 2016 9:49\nTo mi pripomina PR kydy o zarne budoucnosti od byrokratu z EU.\nPříklad: serverovna se sama přizpůsobí aktuálnímu výkonu, bez toho, že by nějací admini naskriptovali chování jednotlivých serverů.\nAno, soudruh Poettering pry jiz pracuje na implementaci interfejsu pro kristalovou kouli, ktera bude instalovana v kazde serverovne a zaruci, ze vykon bude nasazovan vzdy presne v souladu s pozadavky dane serverovny. Admini nebudou v serverovne vubec potreba, bude tam akorat technik, ktery z racku a hlavne z kristalove koule bude luxovat pavuciny.\n23. 5. 2016 10:21\nNo procesor už dnes přiděluje prostředky úlohám i bez admina, na základě adaptivního algoritmu, což dříve dělal operátor pomocí štítků, které vkládal na začátek každého jobu s příkazy jazyka příznačně nazvaného JCL :-)))\nNení důvod, proč by takto nešlo řídit celou serverovnu, brání tomu jen nešikovný init popsaný ad hoc skripty.\n23. 5. 2016 10:28\nNo procesor už dnes přiděluje prostředky úlohám i bez admina, na základě adaptivního algoritmu, ...\nAha. Takze dneska je procesor jaksi chytrejsi, nez OS a umi se rozhodnout, kolik strojoveho casu da databazi, kolik webserveru nebo kolik Openoffice a kolik piskvorkam?\n23. 5. 2016 11:49\nNo mělo být OS, místo procesor. Ale ono se nám to rozdělilo, dnes už i procesor autonomně rozhoduje, které instrukce budou zpracovány, takže optimalizace probíhají paralelně a ani OS nad tím nemá plnou kontrolu. Záleží i na tom, co je v cache procesoru, řekl bych. Ale nějak důsledně jsem toto nepromýšlel.\n23. 5. 2016 15:53\nJo, tovizejo ... a proto ma kazda databaze primo v konfiguraci moznost si locknout pro sebe libovolny mnoztvi RAM, CPU a nektery maji i vlastni FS na discich ... protoze jejich tvurci moc dobre vedi, jak ty automaticky pridelovaci algoritmy stojej za kulovy uplne vsechny.\n23. 5. 2016 16:40\nTo, ze DB obsadi nejakou cast RAM predem, tomu bych jeste veril. Ale, ze si DB uzamkne procesory, tak to bych chtel videt, kolik z bezne dostupnych mainstream DB tohle umi. A ohledne toho FS, to dela snad jen Oracle.\n23. 5. 2016 20:41\nTeď tady do mne stouchl kolega že Sybase taky.\n23. 5. 2016 23:27\n2MP: ... uplne kazda pouzitelna ... ono se totiz v realu ani nepredpoklada, ze by na databazovym stroji melo bezet jeste neco dalsiho.\n24. 5. 2016 11:55\nUzamknout CPU pro DB != "nepredpoklada, ze na DB stroji bezi jeste neco jineho". Umi treba PostreSQL uzamknout CPU tak, ze se k nim nic jineho nedostane? Pochybuji.\n26. 5. 2016 17:42\n2MP: Ono se u databazi predpoklada, ze muze jebnout systemu... a kdyz mu jebne a zacne neco delat, tak proste muze ... ale maximalne s tim jednim nebo dvema jadrama, ktery mu databaze necha. Je totiz naprosto neakceptovatelny, aby se trebas spustila nejaka udrzba systemu, a omezila provoz databaze.\nMimochodem, umej to i widle a M$sql ... a bez toho by to nikdo nepouzival.\n26. 5. 2016 16:39\nlto (neregistrovaný) 85.248.64.---\nKazda enterprise DB to vie. Je to must have feature enterprise. Oracle,Informix, DB2, Sybase ..\n27. 5. 2016 10:32\nOracle RAC bezi jako sada procesu pod uzivatelem Oracle. Neni to az tak vyjimecky (z pohledu OS), az na to ze ma velice specificke pozadavky na OS limity a ze muze pristupovat primo na RAW devices(ASM storage). A k tomu zamozrejme potrebuje prava. Nejjednossi doted bylo sekvencni bootovani, s tim, ze database proste nabiha az posledni a pri shutdownu jde jako prvni dolu. Zatimco systemd klidne utrhne storage pod bezici databazi. Pripade RAC clusteru je to slozitejsi protoze nektere procesy navic bezi pod rootem a musi mit RT prioritu.\nInformix bezi pod uzivatelem informix a jedina jeho zvlastnost ktera me napada jsou virtualni procesory. To jsou vlakna, ktera nevykonavaji zadne blokojici syscally a jsou dedikovana pro provadeni SQL dotazu od vsech konexi. Informix si sam implementuje vlastni "scheduler" uvnitr svoji "VM". K tomu ale potrebuje aby mu do toho OS scheduler nekecal. A proto vola "sched_setscheduler", coz muze normalne udelat jen root.\n23. 5. 2016 9:45\nBudoucí kávovary budou vytvářet specifické chutě kávy (frakční destilací polosyntetické, nebo geneticky upravené kávy, ....\nJesteze kafe moc nepiju. A v dobe IoT se kafe tedy uz nedotknu ani klackem od hovna. A budu se muset zasobit zelenym cajem, nez ho nebezpecni silenci vaseho typu zkurvi take.\n23. 5. 2016 10:11\nTak Earl Grey vznikl prý v roce 1830, takže nic nového pod sluncem. Rozdíl je jen v tom, že tehdy se bylo třeba trefit do obecného vkusu, dnes do individuálního. V tom jsou ještě rezervy obchodního růstu. A růst, už i podle taoismu platí, to co přestává růst, to začíná umírat.\n23. 5. 2016 10:31\nEarl grey jsou splasky zcela v duchu vasi geneticky modifikovane, frakcne destilovane kavy.\n23. 5. 2016 11:44\nZ hlediska snobského pijáka čaje jistě, nic proti nim, ale na trhu se drží už 186 let.\n23. 5. 2016 11:51\nOno se da prodat vsechno. Pigy caj, parky z odpadku.... Earl grey byl pokus, jak ucinit levny vaj pitelnym tim, ze se bergamotem zamaskuje chut neprilis kvalitniho caje. Casem si to naslo sve amatery. A lidi, kteri piji zeleny caj, casto nepiji caj cerny, protoze jim jaksi pripada podradny (a me po nem pali zaha). Earl grey sice obcas lze najit v zelene verzi, ale neni to zadna slava.\nBTW, clovek nemusi byt prilis snobskym pijakem caje na to, aby nepil Earl grey. Ono je mozne najit slusne zelene caje, ktere nejsou moc drahe a vzhledem k tomu, ze v nich jeste neni systemd a na krabicce fotka Poetteringa, tak jsou docela dobre.\n23. 5. 2016 12:27\n"Microsoft je už v tomto popředu s automatickou aktualizací W10."\ntak toho se docela obavam - proc by mel nejaky vydavatel OS predpokladat, ze jako uzivatel si neumim sam rict, ktere aktualizace ano a ktere ne?\nproc bych si nemohl rict, kdy si chci zaktualizovat system? (v praci pouzivam Win - uplne staci, kdyz se Win rozhodne, ze zacne s aktualizaci: konec prace zrovna v kritickem momentu)\n23. 5. 2016 13:03\nTak tak, Update jsou opravdu "killer feature" windows. Zabijí nejenom software, ale zvládnou zneškodnit i hardware a otrávit uživatele tak, že z toho blouzní, jak by to v Redmondu na oplátku pozabíjel taky :D Pomalu a bolestivě...\nJinak co se zbytku toho Ivanova výblitku týká, počítač je sluha. Individuální. Pokud by to mělo fungovat tak, jak on si představuje, tak stačí jedno PC na celý město (který bude vědět, co lidi ve městě potřebují), TV vysílač místo monitoru,...\nUž dávno PC není individuální, 90% informací v něm máte z cloudu, tedy z internetu. Nyní po PC individualizaci přichází další evoluční optimalizační fáze, propojování a vznik mnohobuněčných informačních organismů :-))) Už i Eclipse je ve verzi pro cloud. Stále více software bude sloužit strojům a ne lidem.\nVezměte si takovou navigaci do automobilu, dnes slouží řidiči, aby našel cestu, za pár let bude sloužit automobilu, aby dojel na místo, které mu určíte. S PC si ještě dnes rád pohrajete, ale pokud byste měl administrovat sw nejen PC, ale i TV, kávovaru, auta, sekačky na trávu, tak by vás to brzy přestalo bavit.\n23. 5. 2016 15:06\n"Už dávno PC není individuální, 90% informací v něm máte z cloudu"\njak kdo - ja cloud nepouzivam (ne vedome, primo, umyslne - bohuzel treba takovy mail je nekde venku na serverech mimo muj dosah)\n"Vezměte si takovou navigaci do automobilu, dnes slouží řidiči, aby našel cestu, za pár let bude sloužit automobilu, aby dojel na místo, které mu určíte" - zduraznuji to "které mu určíte"\nano - chci urcovat, co ma muj stroj delat, kdy to ma delat. rad bych i to jak - ale lidske reflexy a schoppnosti oproti sikovnym algoritmum nemaji sanci.\na zas je duraz na tom slovicku "sikovnym": dnes bohuzel vetsina algoritmu (kere za nas maji neco resit) jsou spis stupidni hricky sfetovanych magoru, co nikdy nic praktickeho nedelali azbastlili to pod drtivym psychologickym tlakem svych managoru\nnejsem detinsky - lepsi to uz bylo.\nproto osobne mam radsi hromadu malych programku, kreabicek, ktere proste vymenim, kdyz se mi nezda, jak funguje\n(ano s mobilem telefonuju a smskuju, na cteni pouzivam ctecku, tv koukam na tv, pouzivam navigaci, programuji a pisu na PC - a nepouzivam na vsechno jednu krabicku, co mi nevleze poradne ani do kapsy)\nA az tam cokoli prestane fungovat, tak si admin rovnou hodi masli, protoze nebude mit zadnou sanci s tim cokoli udelat. Ja bych rek, ze Windows uz tu mame, tak proc delat dalsi?\n23. 5. 2016 7:09\n:-D už jsme to řešili.\nZ článku. kde to i autor přiznává a tajemství to není, takže tou malou citací bych tuto část zakončil:\n"Systemd je často vytýkána snaha pokrýt velkou část úloh, které dříve mělo na starosti více programů. "\nA ke KISS\nJako by služby potřebovaly mít další způsob definice, místo aby použili stávající. No a ke všemu ještě tím vzniká nekompatibilita:\n"Např. graphical.target pro nastartování grafického prostředí. Pro zpětnou kompatibilitu odpovídají původní očíslované běhové úrovně pojmenovaným cílům. Tedy telinit 5 má stejný efekt jako systemctl isolate graphical.target. Opačně to neplatí, některé cíle nemají číselný ekvivalent."\nA to ani neřeším to, že v podstatě ta "super cool feature" v ošetřování závislostí služeb není vyřešena "novým" způsobem volání služeb ale stejně pomocí "After, ..., ...."\nCo mě hlava nebere pokud deklaruju závislost\nproč to mám psát ještě jednou v After, pokud moje služba závisí na jiných je logické, že se má pustit až po nich\n23. 5. 2016 7:25\nAsi se mohou lišit. Třeba když na něčem sice závisí, ale spouštět se má až ..... po?\n23. 5. 2016 8:16\nLebo ja sa iba začínam kamarátiť so systemd a ukazuje sa mi\n1. Wants - keď spustím službu musia sa počas bootu spustiť aj wants\n2. After - služba sa spustí, až keď bežia všetky After služby.\nTeda ak by nebolo After tak by sa to fungovalo asi ako spúšťanie inštrukcií v poradí a ukončovanie mimo poradia. A to môže vadiť.\nA navyše Wants hovorí, že ak sa niečo Z nich nepustí tak to oznám A pokračuj V štarte úlohy. Requires stanovuje, že sa musí služba vypnúť ak sa nepodarí niečo z Requires spustiť\n23. 5. 2016 8:29\nSystemd je často vytýkána snaha pokrýt velkou část úloh, které dříve mělo na starosti více programů.\nJenže ono to i dnes má na starosti více programů, jenom se vyvíjejí pod jednou střechou a pod jedním názvem projektu.\nJako by služby potřebovaly mít další způsob definice, místo aby použili stávající.\nKterý z mnoha stávajících způsobů myslíte?\nTo není žádná super cool feature. Jde jenom o to, že původní SysVinit závislosti vůbec neřešil, služby se startovaly postupně za sebou v pořadí podle názvů. Naproti tomu systemd (a spousta jiných initů) explicitně definuje závislosti mezi službami, což dává například možnost startovat služby paralelně, a zjednodušuje to konfiguraci pro případ „nastartuj jenom služby, které jsou potřeba“.\n23. 5. 2016 8:41\nNegramot jirsak opet v akci ...\nNe, nezajistuje to vic programu, zajistuje to jeden binarni blob, kterej nejde nicim nahradit, protoze nema zadny API a to co ma, je navic naprosto nepouzitelny. Nehlede na to, ze "nezbytne" potrebuje spoustu nestabilnich sracek, ktery v systemu nemaji co pohledavat, natoz startovat.\nParalelni start je neco, co 99,99999 adminu nanic nepotrebuje, je to naopak naprosto zavadnej postup.\n23. 5. 2016 9:28\nCílem je adminů se zbavit, stroj by se sám měl naučit, co kdy spouštět. To je budoucnost.\n23. 5. 2016 10:19\nCílem je adminů se zbavit, stroj by se sám měl naučit, co kdy spouštět.\nAha, takze systemd se jednou stane umelou inteligenci. Uz se tesim, jak mam v notebooku 128 jader a 128 TB RAM na to, aby ta umela inteligence mela na cem bezet. BTW, co az ta umela inteligence usoudi, ze lidi jsou vlastne k nicemu a tak necha ten reaktor v elektrarne vyletet do luftu?\nJinak tedy ocekavam, ze objem kodu systemd brzy prekroci objem kodu jadra a vsech knihoven a aplikaci, ktere pro Linux existuji. Budouci distribuce Linuxu budou obsahovat systemd, jadro, par knihoven a textovy instalator. Vic se na tech 10 BlueRay disku nevejde.\nNo ono nemusí jít hned o AI, stačí přejít ze statického manuálního řízení na dynamické a adaptivní.\n23. 5. 2016 13:17\nAle adaptivní řízení řeší nastavení parametrů podle požadovaných kritérií a neřeší věci, jako třeba že server za mě bude vědět sám, co kdy má jet a kdy se uspat.\nDynamickým řízením je myšleno co? Zpětnovazební řízení?\n23. 5. 2016 20:55\nUž tu byla snaha zbavit se I programátorů... No a I po takovém debilnim startupovem java/webovém/apkovem patlalovi je dnes shanka. Máte poměrně zkreslené představy co takový admin dela. A jaké různé nasazení je od strojů požadováno.\nDovedu si vaše myšlenky představit, ale s úplně jinou více unifikovanou a odladenou technologií. A hlavně pro specifická uziti.\n23. 5. 2016 8:44\n1) Jenže ono to i dnes má na starosti více programů, jenom se vyvíjejí pod .......\nAno, už minule jsem Vám dokázal, že třeba logind bez systemd neběží a vytváří tím závislost závislost na systemd. A takových bude víc a přibývají. To jde vidět z toho, že místo kooperace pohlcuje a až pak "kooperuje"\n2) Slovo další indikuje mnoho, nebo už začíná obvyklé podsouvání slov?\n3) Neřešil. Ovšem systemd neřeší jenom to co píšete, ale spolkl i spoustu jiných věcí a pohřbívá kompatibilitu.\n23. 5. 2016 9:01\nAno, už minule jsem Vám dokázal, že třeba logind bez systemd neběží a vytváří tím závislost závislost na systemd.\nTakhle funguje princip „dělej jednu věc a dělej ji pořádně“. Když program potřebuje udělat něco, co není jeho doménou, použije k tomu jiný program, který právě tohle dělá.\nSlovo další indikuje mnoho, nebo už začíná obvyklé podsouvání slov?\nNerozumím, na co se ptáte. Dnes existuje mnoho způsobů definic služeb, každý init systém používá vlastní, a často se to i u jednoho systému liší napříč distribucemi. Proto jsem se ptal, který z těch mnoha stávajících způsobů měl použít systemd.\nOvšem systemd neřeší jenom to co píšete, ale spolkl i spoustu jiných věcí a pohřbívá kompatibilitu.\nTo klidně může být pravda, ale nijak to nedokazuje vaše původní tvrzení, že ošetření závislostí služeb měla být nějaká „super cool feature“ systemd.\n23. 5. 2016 9:12\n" Když program potřebuje udělat něco, co není jeho doménou, použije k tomu jiný program, který právě tohle dělá."\nAle systemd to nedělá. Nepoužije k tomu jiný program, zde by to byl samostatný logind, ale použije vnitřní část blobu. A co není v blobu, tak se tam přidá.\nMinule jsem Vám to prokázal, nyní několikrát připomenul, tím pádem už se k tomu nebudu vyjadřovat a marnit tím čas. Těmi zaobalenými řečmi okolo to neopravíte.\n"Nerozumím, na co se ptáte. Dnes existuje mnoho způsobů definic služeb,"\nJá měl na mysli volání služeb v konfiguráku, ale asi je to jen forma zápisu. I když se mi to nelíbí, tak zde uznávám že na tom buď tak nesejde, nebo by to mohlo být i celkem jedno.\n"To klidně může být pravda, ale nijak to nedokazuje vaše původní tvrzení, že ošetření závislostí služeb měla být nějaká „super cool feature“ systemd."\n:-D Vždyť to ošetření závislostí služeb je to hlavní, čím se systemd ohání že řeší.\n23. 5. 2016 10:14\nTvrdil jste, že logind závisí na systemd. Což by bylo v souladu s unixovou filozofií – logind dělá pouze to, co je jeho účel, na správu služeb používá funkce systemd. Podobné řešení najdete u spousty dalších unixových programů – třeba qmail nebo Postfix, porovnejte si je se Sendmailem.\nVždyť to ošetření závislostí služeb je to hlavní, čím se systemd ohání že řeší.\nNikoli. Nic takového není napsané na webu systemd, v článku, na Wikipedii, na wiki Debianu, na wiki Archu… Netuším, kde jste to sebral.\n" logind dělá pouze to, co je jeho účel, na správu služeb používá funkce systemd"\nTo je v pořádku až do té chvíle, kdy je na pevno součástí systemd. Ano, filozofická úvaha. Ne všechno je modulární jenom proto, že část má jiné jméno. Zkuste logind spustit bez systemd. A tím, že se to snažíte pořád vyvrátit fabulováním, tak už jste to "Systemd je často vytýkána snaha pokrýt velkou část úloh, které dříve mělo na starosti více programů." co jsem napsal málem obrátil. Ale smůla.\n"Vždyť to ošetření závislostí služeb je to hlavní, čím se systemd ohání že řeší.\nNikoli. Nic takového není napsané na webu systemd, v článku, na Wikipedii, na wiki Debianu, na wiki Archu… Netuším, kde jste to sebral."\nsystemd is a system and service manager for Linux\nWikipedie - druhý odstavec\n" Démon systemd spravuje ostatní démony. Všechny démony, včetně systemd, běží jako procesy na pozadí. Během zavádění systému je systemd spuštěn jako první démon a během vypínání systému ukončen jako poslední."\n" vývojáři systemd, chtěli v mnohém překonat schopnosti init démonu. Chtěli zlepšit framework pro řešení závislostí, aby bylo možno během bootování vykonat více úloh současně a redukovat režii"\nDál nepokračuji, jen plýtváte mým časem a nic z toho, jenom neustálé převracení a odvracení od příspěvku.\n23. 5. 2016 11:00\n„Systemd je správce služeb“ je úplně jiné tvrzení, než vaše „nejdůležitější funkcí systemd je řešení závislostí služeb“.\n23. 5. 2016 11:08\nA copak asi proboha dělá ten správce služeb. Přiděluje barvičky a mění každé třetí písmenko, že? Každopádně to byl hlavní argument, že řeší závislosti, ostatně se o tom píše i v článku hned v prvním dílu\n23. 5. 2016 12:57\nSysVinit je také správce služeb a závislosti neřeší.\nKaždopádně to byl hlavní argument, že řeší závislosti, ostatně se o tom píše i v článku hned v prvním dílu\nAno, je to váš hlavní argument. Jenom netuším, jak jste na něco takového přišel. V článku je to uvedené na začátku třetího odstavce vlastností systemd, navíc hlavně v souvislosti s řešením cyklů. Hlavní vlastnost by byla uvedená na začátku prvního odstavce, nemyslíte?\n23. 5. 2016 13:22\nNo jasně, systemd je evidentně na prd, jak přijde slovo na závislosti tak se to hroutí, pak se ukazuje že stejně ani dobře nefunguje, tak co uděláme? Začneme tvrdit, že hlavní úlohou správce úloh není správa úloh a jejich závislostí a kde že je to napsané a jak moc je to hlavní feature když je to v článku až v třetím odstavci.\nDobře, tak ať se pobavíme: Tak co je hlavní úkol systemd když ne správa procesů a jejich závislostí?\nVážený trolle, nepodsouvejte mi věci, které jsem nikdy netvrdil. To, že musíte postupně upravovat svá vlastní tvrzení, to je váš problém.\nZačal jste tím, že řešení závislostí má být údajně vlastnost systemd, která je pro systemd klíčová a odlišuje jej od ostatních správců služeb. Teď najednou tvrdíte, že správa závislostí je hlavní úlohou každého správce služeb. To je pravý opak toho původního tvrzení. Popíráte sám sebe, a ještě to zkoušíte svést na mne.\nHlavním úkolem SysVinitu, OpenRC, daemontools i systemd je správa úloh. Některé z jmenovaných správců k tomu používají správu závislostí, některé ji nepoužívají – z čehož je patrné, že správa závislostí nemůže být jejich hlavním úkolem.\n23. 5. 2016 14:11\nNic takového jsem nenapsal Trolle. Napsal jsem:\n"A to ani neřeším to, že v podstatě ta "super cool feature" v ošetřování závislostí služeb není vyřešena "novým" způsobem volání služeb ale stejně pomocí "After, ..., ...." [ 1 ]\na kde je tam teda:\n" která je pro systemd klíčová a odlišuje jej od ostatních správců služeb." [ 2 ]\nA napsal jsem, že o systemd se pořád tvrdí že to má konečně pořádně vyřešit služby a závislosti v jednom. A to je furt dokola a i v článku je to hned v prvním díle, hned první příklad užití.\nUž minule jsem Vás prokoukl. Prostě si něco vyberete, lehce to ohnete a pak na to začnete odpovídat dalšíma otázkama na tu ohnutou věc. Stejně jako to nyní v [ 2 ]. Ale to na mě pane Jirsáku neplatí\n23. 5. 2016 14:22\nTakže podle vás „super cool feature“ znamená „nezajímavá vlastnost, kterou už má každý“. Dobře.\nA napsal jsem, že o systemd se pořád tvrdí že to má konečně pořádně vyřešit služby a závislosti v jednom.\nAno, to jste si vymyslel a napsal, a vůbec se nenecháte rozházet tím, že vás opakovaně upozorňuju, že je to pouze vaše tvrzení a nikde jinde to napsáno není.\ni v článku je to hned v prvním díle, hned první příklad užití.\nNetuším, na co se odkazuje „první díl v článku“. Já jsem odkazoval na článek, pod kterým diskutujeme, a v něm to jako „super cool feature“ označené není.\nUž minule jsem Vás prokoukl. Prostě si něco vyberete, lehce to ohnete a pak na to začnete odpovídat dalšíma otázkama na tu ohnutou věc.\nProkoukl jste dobře, ale sebe. To vy jste začal u „ošetřování závislostí a služeb je super cool feature“, skončil jste „správa procesů a jejich závislostí“, a tváříte se, že je to pořád to samé. Ano, na ty vámi ohnuté věci se ptám, protože se snažím zjistit, proč jste je ohnul.\n23. 5. 2016 14:40\nPokud v textu "super cool feature" čtete něco jako nezajímavá nebo je to v překladu „nezajímavá vlastnost, kterou už má každý“ nebo vlastnost kterou nikdo nemá, tak doporučuji očního lékaře a nebo psychologa.\nHlavní výhody a nevýhody oproti sysvinit\nJeště se v kostce podíváme na hlavní výhody a nevýhody. Konkrétně si je přiblížíme v následujících článcích:\nkonfigurační soubory – odpadá nutnost psaní redundantního kódu démonů\nautomatické řešení závislostí\nAni nemusím chodit dál než do článku, ke kterému tady diskutujete, pokud to nevíte\n... Na zbytek těch volovin nemám čas ....\n23. 5. 2016 15:03\nNikoli, já to čtu jako jako „vlastnost, která je pro systemd klíčová a odlišuje jej od ostatních správců služeb“. Ale to už jste napsal, že takový význam to nemá. Zajímalo by mne, co jste tím tedy chtěl říct.\nAha, takže do sbírky synonym k „ošetřování závislostí služeb“, „správa úloh a jejich závislostí“ a „konečně pořádně vyřešit služby a závislosti v jednom“ můžeme přidat „automatické řešení závislostí“. Vy byste se asi nudil, kdybyste pro jednu věc používal jeden termín, že?\n23. 5. 2016 16:20\n>> A napsal jsem, že o systemd se pořád tvrdí že to má konečně pořádně vyřešit služby a závislosti v jednom.\n> Ano, to jste si vymyslel a napsal, a vůbec se nenecháte rozházet tím, že vás opakovaně upozorňuju, že je to pouze vaše tvrzení a nikde jinde to napsáno není.\nTo si vymyslel nejaky Lennart Poettering.\n23. 5. 2016 15:57\n2janek: to je dement jirsak, negramotnej, IQ zaporny ... dohadovat se snim nema smysl. Ten jeste vzivote nevlat precist ani jednu jedinou vetu, a ty po nem chces souveti ...\n23. 5. 2016 16:16\n23. 5. 2016 10:38\nTvrdil jste, že logind závisí na systemd. Což by bylo v souladu s unixovou filozofií – logind dělá pouze to, co je jeho účel, na správu služeb používá funkce systemd.\nProblem neni v tom, ze logind zavisi na systemd, ale v tom, ze logind zavisi vyhradne na systemd. Take v tom, ze se systemd nemuzu pouzit loginbflmd. A kdybych mohl, otazka je, zdali by Gnome skousl fakt, ze misto logind ma k dispozici loginbflmd.\nJinak co nechapete na tom, ze je uchylne, kdyz kvuli Gnome musim mit logind, kvuli kteremu musim mit systemd? Proc tedy neintegrovat Gnome do systemd rovnou? Stejne uz tam je Tetris a ovladac dveri od garaze.\n24. 5. 2016 10:15\nA co je systemd-logind, kdyz ne samostatny program? Jinak\n$ rpm -ql systemd |grep 'bin/' |wc -l\nA dalsich 43 binarek v /usr/lib/systemd Tak kde mate ten blob?\n24. 5. 2016 10:23\n" For one, in the last stages of GNOME 3.8.0 as release team we specifically approved some patches to allow Canonical to run logind without systemd"\n23. 5. 2016 9:15\nZnovu, muzete poslat zmeny, ktere kompatibilitu zlepsi.\nNa jadro si ale taky nestezujete, ze dela IPC totalne jinak nez ostatni otevrene operacni systemy te doby. Viz diskuze edge vs level triggered a Bryan Cantrill (http://www.bsdnow.tv/episodes/2015_11_23-the_cantrill_strikes_back). Nakonec i systemd s sd-event kolem teto problematiky pracuje a v podstate dava za pravdu Bryanovi (http://0pointer.net/blog/introducing-sd-event.html).\nParalelizace neni spatna vec a i kdyz musi clovek vic premyslet, tak dlouhodobe urcite prinos viditelny je. Napr. pri nasazovani virtualnich stroju. Predstavte si, ze provozujete desetitisice virtualnich stroju jako kdejaky provider/ hoster dnes. To potom rozdil v rychlosti spusteni muze mit vyrazne financni dusledky a rozdil ve spokojenosti zakazniku.\n23. 5. 2016 9:52\n1) Logind bude integrovan do systemd. Pri loginu bude zobrazovat fotografii sklebiciho se Poetteringa, coz system ochrani pred neautorizovanym pristupem, protoze se kazdy utocnik desne lekne.\n23. 5. 2016 8:15\n"Asi tím, že si každý k modulu prostě napíše, že pokud má být spuštěný, musí běžet to a tohle a tamto. Nemusí na to psát kus programu, který ověří, jestli něco běží, a pak to spustí, ještě než se spustí ten modul."\nIMHO: No a to je právě to, že místo aby napsali kód, který akorát kontroluje závislosti, tak tu máme nový 1/2 desktop, nekompatibilní s ostatními a inity se do služeb stejně vypsat musí tak i tak ....\n23. 5. 2016 8:45\nJenze pokud potrebujes aby neco bezelo, tak si to stejne musis overit sam, systemd nic overit neumi. Pokud potrebujes aby bezela databaze, tak je ti systemd nahovno, protoze si musis pustit neco, co si do ty databaze hrabne, abys zjistil, ze vazne bezi. Databaze muze sama o sobne startovat klidne desiky minut\nOvsem pri systemd ti nenastartuje projistotu vubec ... ona bude startovat, az na ni hrabes ... takze misto 10-20 minut, klidne hodinu - to nez se dostanes k tomu na ni hrabnout.\nMozna byste se mel podivat na nasledujici clanek: https://www.linuxvoice.com/interview-lennart-poettering/\nMyslim, ze v jistem ohledu ma pravdu. Ti nejvetsi kritici casto maji o kritizovanych systemech mensi povedomi nez by bylo nutne pro informovanou kritiku. Ja v posledni dobe zacal koketovat s FreeBSD/ PC-BSD a mam v planu vyzkouset OpenIndiana (OpenSolaris) a OpenBSD.\nA komu se neco ze svobodneho softwaru nelibi, muze nakonec vyuzit ty casti, ktere se mu libi nebo podporit penezi/ cesem/ vyvojem/ vyuzivanim jiny projekt.\nNikdo neni bez chyby. I Linuxove jadro je za nekolik veci kritizovano (IPC, chybejici opravdovou alternativu DTrace apod.) ale to bych zminoval zase jen veci, o kterych sam vim malo. Slo mi o znazorneni pripadu. Proste se snazme porozumet a vybrat si ze softwaru to nejlepsi a casem se sjednotit na nejakem kvalitnim reseni pro vetsinu a potom nekolik napr. plug-inu nebo alternativnich mensich reseni pro specializovane uzivatele. Systemd tomu nebrani, tak mi uprimne prijdou ruzne nekonstruktivni dodatky mimo misu. Let the code speak! PRs/ patches are welcome!\n"Systemd tomu nebrani, tak mi uprimne prijdou ruzne nekonstruktivni dodatky mimo misu. Let the code speak! PRs/ patches are welco"\nBrání, samozřejmě nevím o všech "špecích", ale díky systemd už bez systemd-logind není možnost spustit Gnome - tedy, byla napsána obezlička. Jak dlouho to vydřží - tak kdo ví a jak dlouho to bude platit jenom pro Gnome - kdo ví. Tím padá to Vaše každý si může vybrat. A bude padat dál, protože se to ubírá dál stejným směrem\n23. 5. 2016 9:48\nn (neregistrovaný) 80.95.102.---\n"už bez systemd-logind není možnost spustit Gnome "\nto ze nejde spustit Gnome bez systemd-logind neni chyba autoru systemd, ale rozhodnuti vyvojaru Gnome ze se rohodli pouzit systemd a zjednodusit si zivot\n23. 5. 2016 9:50\nGnome potřebuje logind, který má IMHO zprostředkovávat události z jádra a místo aby byl vedle systemd a kompatibilní, tak je v systemd zadrátovaný.\nTak to ale v open source funguje. Proč GNOME de facto závisí na systemd-logind? Protože to je to, co drtivá většina přispěvatelů a uživatelů používá. Nikdo v GNOME neříká, že tam nemůže být podpora pro nic jiného. Jen se tam prostě nenajde dobrovolník, který místo nekonečného diskutování na Internetu, jde a tu podporu pro to, co používá, napíše a bude udržovat. Ostatně GNOME pořád běží na na BSD, akorát z komunity o stovkách přispěvatelů na tom má zájem dělat jenom jeden člověk, takže když potřebné věci neudělá on, tak nikdo.\nPřispěvatelé do open-source projektu přispívají často kvůli tomu, že tím řeší nějaký vlastní problém. Každý si drbe svoje vlastní záda. Takový projekt nemá povinnost podporovat kdejaký obskurní systém nebo třeba distribuce obskurní architekturu jenom proto, že se najde někdo, kdo by ten projekt na nich chtěl provozovat. Rozhodují ti, kteří dělají, a to jsou v GNOME v drtivé většině lidi, kteří jedou na Linuxu se systemd.\n23. 5. 2016 15:30\n> Rozhodují ti, kteří dělají, a to jsou v GNOME v drtivé většině lidi, kteří jedou na Linuxu se systemd.\nTo je pochopitelne a vcelku legitimni. Ale nijak to nemuze popirat, ze myslet na jine lidi muze nekdo vnimat jako ctnost a jeho absenci prozivat jako zklamani. Zvlast pokud se porad mluvi o "komunite" a "spolupraci".\nPokud by se jeho vyvojari rozhodli, ze GNOME pojede jenom na Ubuntu s MIRem, protoze to je to, co oni pouzivaji, muzou z toho porad byt uzivatele jinych dister s jinym displayserverem *zklamani* a rozcarovani. A dokonce to muzou celkem legitimne vnimat jako hodne podobny vendor lockin, jako zazili na Windows. Nutit nekoho psat nejaky kod ale samozrejme nemuzou. ...a ani nemusi, protoze alternativ je habadej. Vcetne Mate nebo Lumina*.\n* on totiz nutne clovek nemusi prispivat do GNOME. Muze taky dojit k nazoru, ze nema smysl psat narovnavak na ohybak a lepsi je rovnou napsat neco rovneho.\n23. 5. 2016 16:36\nVíceméně se shodneme. Že z toho můžou být uživatelé zklamaní, nepopírám. Nicméně pokud člověk chápe, jak open-source projekty fungují, nemusí se mu to líbit, ale pochopí to. Každý projekt má nedostatek zdrojů a ty se nevynakládají efektivně tak, že se bude podporovat všechno, co se líbí kdekomu z uživatelské základy. A není o tom, že by člověk byl vůči alternativám nepřátelský. Typický FLOSS vývojář totiž nevypadá tak, že má moře času a neví, do čeho by píchnul. Většinou musí těžce prioritizovat.\nPokud drtivá většina přispěvatelů a uživatelů GNOME pojede na Ubuntu a Miru a nenajde se nikdo, kdo bude udržovat podporu pro X nebo Wayland, může se stát, že GNOME pojede jenom na tom a bude to pochopitelné. Vendor lockin v tom nevidím. Na rozdíl od Windows totiž může kdokoliv dojít a tu podporu pro svůj systém si tam dodělat. Pokud by se tomu projekt vehementně bránil, to by byla jiná. Že se někomu nechce přispívat do projektu a raději odejde k takovému, který jeho systém už podporuje, je taky zcela legitimní rozhodnutí.\n23. 5. 2016 16:48\n> Každý projekt má nedostatek zdrojů a ty se nevynakládají efektivně tak, že se bude podporovat všechno\n"Lokálně" (z pohledu jednoho projektu) to tak může být. "Globálně" to tak být nemusí, pokud se jeden projekt rozhodne být úžejiprofilový a vedle něj tímpádem musí vzniknout v podstatě to samé znovu.\n> Vendor lockin v tom nevidím. Na rozdíl od Windows totiž může kdokoliv dojít a tu podporu pro svůj systém si tam dodělat.\nNe všechno, co je formálně pravda, je pravda i prakticky. Sice si formálně můžu vzít jádro FreeBSD a přepsat ho na mikrojádro, ale prakticky to dělat nebudu, protože to je enormní množství práce. A podobně enormní množství práce může být ohnout GNOME aby pracoval jinde než na Linuxu se systemd.\nOno to teď linuxákům přijde jako strašně čupr a logické, protože Linux má "majoritu v minoritě". Ale pokud by svého času stejný postup volilo GNU a ostatní OSS projekty (píšeme Firefox pro Hurd, protože to je to, co používáme), žádný Linux v dnešní podobě by nevznikl. Byl by jenom nedokončený Hurd a kdesi na jakémsi FTP serveru by leželo jádro zvané Linux, které by bez userlandu a aplikací bylo k ničemu.\nTo, co umožnilo ten obrovský rozvoj OSS byly právě vzájemné ohledy, přenositelnost, snaha o spolupráci. Jakmile se Linux rozjel, nějak na to linuxáci pozapomněli...\n...a mně to může být tak maximálně líto, protože na takové chování samozřejmě mají právo. Stejně jako má Microsoft právo užívat si svoji hegemonii na desktopu.\n23. 5. 2016 23:31\nNezbejva nez pevne doufat, ze se redhat posere (doslova) az jim zacnou chodit req na placenej support prave kvuli dojebanymu systemd. Sem zvedav, jak budou platicimu zakosovi vysvetlovat, ze rozmrdanej log je OK.\n24. 5. 2016 0:00\nMě by dost zajímal adoption rate RHELu 7, ale to bohužel nezvěřejňují. A navíc zápory systemd tam plusově vyvažuje docker...\nDocela bych teď chtěl v RH pracovat, protože jestli k nějakým peprnostem dojde, ven se to asi moc nedostane :) Nebo ne v důvěryhodné podobě.\nMně RHEL 7 nějak blbnul při startu i jenom při testování. Mít to nasazovat na servery, tak budu mít pěkně sevřený půlky ;)\n24. 5. 2016 9:05\nJa mam nahozenou jednu instanci centosu ... coz defakto rh7 je ... kvuji req jednoho z dodavatelu. A uz sem resil nekolik desitek zavad, prave kvuli systemd, protoze jeho chovani je naprosto nepredvidatelny. Nastesti je to jen v testovacim provozu, ale uz sem dodavatele informoval na to tema, ze pokud by se to hypoteticky melo nasadit naostro, tak at na tenhle system rovnou zapomene. Nehodlam totiz po kazdy aktualizaci restartovat, pripadne resit, proc nenastartovalo to, co nastartovat ma, ale zato nastartovalo to, co nema.\nOno to totiz (napriklad) odmita servis ktere dodal dodavatel restartnout. Takze je treba restartnout celej system ... uzasny. (respektive se to tvari, ze restart probeh, ale nic se nerestartuje). V logu samo absolutne nic.\n24. 5. 2016 0:11\nMohl byste se vyjadřovat slušně i pokus Vás něco zlobí. Taky místo hořekování můžete implementovat ukládání do textové podoby místo binární. Nebo máte konkrétní indicie, že by to bez přepracování celého ekosystému kolem systemd nebylo možné?\nPokud Vám systemd extrémně vadí a jste zákazníkem RedHat, měl byste konstruktivní kritiku vylíčit Vašemu kontaktu.\nChtěl bych upozornit, že systemd nijak nezávisí na firmě RedHat, jen někteří vývojáři v čele s LP a KS pro tuto firmu pracují.\nStabilita a jistota je i pro mně prioritou. Pokud můžete reprodukovat nějaké chyby, pošlete prosím bug report na odpovídající místa. Jako vždy, pafches are welcome!\n24. 5. 2016 9:09\nJo, jasne, to je videt ...https://bugs.freedesktop.org/show_bug.cgi?id=64116#c2\n24. 5. 2016 9:15\n24. 5. 2016 9:16\nJo, tam je nějaký bílý znak . . . mezi bug a .cgi\n24. 5. 2016 10:06\nNebyl jsem tenkrát u toho, ale nemyslím si, že adopce Linuxu projektem GNU byl nějaký altruismus. Byl to IMHO spíš sňatek z rozumu. GNU mělo nástroje pro userspace, ale nemělo kernel, tak skončili po Linuxu, který s nimi sdílel stejný pohled na licenční politiku. Kdyby byl v té době hotový Hurd nebo byl aspoň v nějakém nadějném stavu, tak nikdo z GNU Linux neřeší. Z jejich pohledu proč taky?\nSpolupráce a ohleduplnost v OSS je v rovině toho, že nikdo nebrání lidem, aby se přidali a udělali podporu pro to, co potřebují, ne v rovině, že někdo pracuje na něčem, pro co nemá osobní zájem a vlastně ho to nezajímá, jenom z ohleduplnosti k ostatním. Neříkám, že se to neděje vůbec, ale dle mých zkušeností minimálně.\n24. 5. 2016 10:20\nJo, tak to asi. Kdo ví.\nProblém systemd je ale v tom, že místo chytrých, jednoduchých řešení (nemyslím přímo řádky v kódu) přichází s monolitickým celkem, který místo uceleného a odolného řešení vše pohlcuje. A z toho vychází ten problém, že jak pohlcuje další a další části systému, tak s nimi pohlcuje a tím tedy zanáší i jejich další chyby. Takže se v podstatě dá říct, že buď systemd nakonec vyřeší všechny chyby a nedostatky všeho co pohltil a spasí tím komunitu linuxu a nebo bude do nekonečna trpět i těmito zanesenými chybami. Čím víc toho spolkne, tím víc jich bude.\n24. 5. 2016 12:30\nNepsal jsem nic o altruismu ani o tom, že by někdo měl něco psát pro systém, který nepoužívá. Jenom mám prostě pocit, že dřív bylo vnímáno jako super výhoda OSS, že se píše přenositelně a nehážou se lidem klacky pod nohy tam, kde to není nezbytně nutné*.\nKdyby nebyl u gcc a spol. dáván takový důraz na přenositelnost, nebyl by OSS tam, kde teď je.\nV podstatě, kdybych se na to chtěl dívat extra škarohlídsky (což nechci), mohl bych říct, že Linux vyžral z okolního světa co mohl, tím se vyšvihl, a jakmile získal suverénní postavení, začal si hrabat na svém písečku.\n* Byl to osovobozující juchů moment, vidět třeba Firefox běžet na BeOSu - po tom, co člověk strávil x let ve svěrací kazajce Windows...\nAd článek. Mě se "líbí" jak si vezme nějakou větu od kritiků systemd, vytrhne ji z kontextu (nebo prostě nepochopí její myšlenku) a začne argumentovat úplně něčím jiným (unix se distribuoval jako jeden balíček jádro + shell), přičemž kritici systemd to myslí jako dělej jednu věc a dělej ji pořádně (a systém postav z existujících kousků). (Dobře, je možné diskutovat o tom, co je to vlastně "být unixový", což vše do toho patří a co už ne, každopádně to na samotnou myšlenku nemá vliv.) Taková diskuse je o ničem. Podobně vypadají diskuse i pod některými bugy systemd.\n23. 5. 2016 10:20\nkritici systemd to myslí jako dělej jednu věc a dělej ji pořádně (a systém postav z existujících kousků)\nPřesně takhle systemd funguje, tedy až na tu závorku, kterou jste si tam přidal vy. Autoři systemd zjevně používají jiný přístup, než ten v závorce, a to „když žádný vhodný existující kousek neexistuje, napiš nový“. Mně ten přístup připadá dlouhodobě lepší, než „použij za každou cenu existující kousky, a když nevyhovují, tak k nim přidělej narovnák na vohejbák“.\nTu jsem si tam nepřidal já, ale to je celkem jedno.\nTo je otázka na jakých principech chceme mít ten systém postaven. Mě vůbec nevadí a naopak mi vyhovuje, když otevřu skript (v shellu, ten tam stejně musí být) a uvidím tam kombinaci základních nástrojů* (find, sed, grep, apod.). Všechno tohle v tom systému musí být, admin s tím umí pracovat a je podle mě v pořádku, pokud se z těchto základních kamenů postaví něco většího.\nProč. Pokud mám systém, kde je vše soubor (nebo alespoň podstatná většina, abychom si zase nehráli na slovíčka), tak mi stačí základní nástroje na práci se soubory a je to. Každý admin si oblíbí své nástroje pro práci se soubory a je s nimi efektivní.\nPokud mám například i logy jako textové soubory (čitelné člověkem a zpracovatelné počítačem), tak mi postačí existující známé nástroje na to, aby mimo všech ostatních souborů v systému mohl pracovat i s logy. Jakékoliv zlepšení základních nástrojů automaticky znamená zlepšení práce v mnoha oblastech.\nKdežto pokud mám na každou druhou věc speciální rozhraní, tak jednak nemůžu použít existující nástroje ale musejí být speciální na danou věc, ale také zlepšení nějakých základních nástrojů se této věci vůbec nedotkne, protože ji nepoužívá.\nPochopitelně v některých oblastech mají speciální nástroje a speciální rozhraní svůj smysl.\n*) A ani netrvám na tom, že ta sada programů musí být zrovna tato. Pokud někdo přijde s jinou minimální sadou atomů na které se dá postavit větší celek, jsem pro. Systemd to není.\nPokud je součástí definice té minimální sady nástrojů to, že to není systemd, pak to systemd opravdu splnit nemůže, a není co řešit.\nProblém s rozhraním postaveným na souborech je ten, že se krkolomně řeší notifikace (typické řešení je, že se proces každou chvíli dotazuje, jestli se něco nezměnilo, místo aby spal a čekal, až ho jádro se změnou probudí), jsou tam problémy se souběhem (proces má zpracovat nějaký stav, který se změní dřív, než proces proběhne), a neřeší transakčnost (došlo ke změně, reakce na změnu selhala, je tedy potřeba odvolat i původní změnu).\nMimochodem, systemd se od jiných init systémů liší právě tím, že místo „speciální rozhraní pro každou druhou věc“ zavádí jedno univerzální rozhraní. Ano, nové rozhraní vyžaduje nové nástroje, ale to je normální pokrok. Rozhraní „vše je soubor“ zde také nebylo od stvoření světa, také bylo ve své době nové a znamenalo, že nástroje pro předchozí rozhraní s tím novým rozhraním nefungovaly.\n23. 5. 2016 13:53\nMyslím, že z uvedené řady některých nástrojů je asi jasné, o jakou sadu by se mělo jednat. find je univerzální nástroj na nalezení souborů dle kritérií a je mu úplně jedno, jaké soubory to jsou. grep je univerzální nástroj na filtraci textu. Nic takového systemd nenabízí. Snad ze sebe nemusíme dělat idioty.\n(typické řešení je, že se proces každou chvíli dotazuje, jestli se něco nezměnilo, místo aby spal a čekal, až ho jádro se změnou probudí)\nNo typické řešení není nutné optimální. Pokud ten program skutečně pracuje nad měnící se sadou souborů, tak se dá použít inotify, případně lze ten program upozornit na změnu třeba přes signály.\n23. 5. 2016 14:13\nAno, dá se použít inotify nebo signály, přičemž třeba ten find neumí ani jedno. A světe div se, systemd nabízí právě to univerzální rozhraní. Kdyby se začínalo na zelené louce, místo souborů by se použil třeba dbus a i grep a find by spolu komunikovaly přes něj, místo přes rouru. Jenže na zelené louce se nezačíná, proto je potřeba nějaké lepidlo, které všechny ty legacy způsoby komunikace (soubory, roury, inotify, signály, sokety) umožní integrovat do jednoho univerzálního rozhraní. Mimochodem, drtivá většina všech chyb a problémů se systemd je právě ve zpřístupňování té legacy funkcionality – prostě se ty rovnáky na vohejbáky nepodaří vždy integrovat tak, aby to nikdo nepoznal. Což je podle mne příznak toho, že ty rovnáky na vohejbáky byly špatně a je dobře, že se nahrazují něčím čistším. Jistě, než se podaří tyhle slepence rozplést a nahradit čistým řešením, bude to chvilku bolet. Ale pořád lepší, než to nechat hnít dál.