Distribuce Devuan vyšla v první betaverzi, která je forkem Debianu 8 Jessie. Devuan se od Debianu liší v podstatě jen tím, že namísto nového startovacího programu systemd používá starší initd. A samozřejmě se snaží o to, aby s ním byly kompatibilní aplikace atd. K dispozici jsou klasické 32bitové a 64bitové verze a k tomu i několik variant pro různé ARM desky, např. Raspberry Pi 2 nebo Banana Pi.
(Zdroj: The Register)
Myslím že se po podařilo úspěšně zbavit systemd a tím i problému s nespolehlivým bootováním dvou počítačů jen pouhým
aptitude install sysvinit-core systemd-shim
Nebo jsem něco spletl?
Zdroj informací:
http://www.itwire.com/business-it-news/open-source/65684-debian-leader-says-users-can-continue-with-sysvinit
http://forum.odorik.cz/viewtopic.php?f=12&t=2774
To je potřeba hlásit. Podle situace na Debian nebo na upstream. Momentálně nevím o ničem, co by nešlo v NM kompilovat tak, aby fungoval se systemd i bez systemd. Před časem jsem posílal patche na spojení podpory logind a consolekit do jednoho modulu, který použije to, co je k dispozici.
Devuan to ma jako jasnou prioritu, Debian jako zalozni minoritu s nejistou budoucnosti...
btw: https://devuan.org/os/#packages
No určitě nechci vyvolat nějaký flame, spíš mě zajímá mě jen fundovaná odpověď. To je ten systemd taková hrůza? A když jo, tak proč na něj přešlo tolik dister a podporují to i vydavatelé balíčků? Mě se na tom moc nelíbilo, že se to nedrží zásady "dělám jednu věc a dělám ji dobře" ale zase účel světí prostředky .... Mám Debian 8 už rok na posledním stroji a neměl jsem se systemd jediný problém a je fakt, že ty hlášky ze splashscreenu konečně zmizely.
Tak jak to tedy je?
No, já si s nima vždycky poradím celkem lehce, akorát je trošku trapné, v 21. stol., když dokončíš novou instalaci systému a hned po restartu už tam máš nekonzistentnosti, nehledě na to, že pak musíš průběžně vychytávat errůrky po instalacích balíčků. Uvedl jsem to ale i proto, protože vyčištění startu systému od hovadin byla jedna z často zmiňovaných dobrých vlastností systemd.
Takže chlapci, vyndat hlavy z ...
Víš " já si s nima vždycky poradím celkem lehce" znamená, že si zjistím co se děje, a problém odstraním. V těchto případech to bývá často v nastaveních GRUBU a nebo chybějící konfigurace daemonů dotčených programů.
Nevím jestli jsi si akorát nevzal ráno prášek, nebo jseš jen takové pako, ale nesmíš brát ostatní podle sebe, že když se řekne vyřešit tak někdo něco kamufluje a skrývá.
Zkus to na živě.cz, tam si z tebe možná ti přidrzlí školáčci sednou na zadek ...
Ne, systemd řeší načítání služeb a řeší jejich závislosti a chytá errory. To se v Init nedělo a proto errory vyskakovaly až na splash screen. Třeba chybějící konfigurace k síťovkám. To bylo po instalaci syst. velmi častá chyba
Ale debatu ukončíme. Evidentně o tom víš prd a akorát se snažíš vymaxovat nějakou blbost kterou jsem v textu nevyvrátil. Opravdu mě nebaví, pokaždé vymezovat všechny termíny a skutečnosti, aby mě nějaké zakomplexované děcko nechytalo za slovo. Nejsi zakomplexované děcko? Tak proč vypisuješ takové hovadiny?
a chytá errory. To se v Init nedělo a proto errory vyskakovaly až na splash screen
Aha, Takže jsem měl stoprocentní pravdu. Tebe ty chyby vůbec nezajímaj, tebe zajímá, jak je schovat. Ty errory "vyskovaly až na splash screen", protože - ty tupče - ty errory jsou ta nejdůležitější informace!!! Ne tvůj splashscreen s Lennartovou fotkou. Ty errory potřebuješ vidět, abys mohl zjistit problém a opravit ho. Ne schovat, ty lemple!!!
Aneb frikulín mlamoj programuje init. Abys moh něco vůbec logovat, tam musíš mít kam. Když nemáš připojenej disk, tak můžeš logovat tak leda do Lennartovy řiti. A vůbec nejlepší je ty informace před uživatelem schovat úplně, aby nedejbože neviděl, co za blba mu ten systém instalovalo, že mu nanastavil síť, a aby se případný problém po telefonu vůbec nedal řešit. Vždyť uživatel přece může půl dne čumět na Lennartovu fotku, aby nebyl znepokojen errory.
Jo, takže hláška o chybějící konfiguraci síťovky na obrazovce přišla asi z věštící koule, protože init tahá služby z /etc/ z nepřipojených disků, takže proto ani nemá pojem o /var/log/ ani RAMce, ale zato zobrazit uživateli hlášku přes půl obrazovky na 10 vteřin je ten skvělý recept. No ty jsi teda čaroděj
PS: Nevím co to máš pořád s Lennartovou fotkou, ale tvůj obvoďák ti rád poskytne odbornou pomoc.
Śirší technické vysvětlování je úplně zbytečné, myslím, že všichni s mozkem a ti, co aspoň jednou řešili fatálně rozesraný systém pochopili, jakou situaci jsem popisoval. A ano, hláška na sekund, že janek při instalaci nenastavil síť, je nepochybně skvělý recept na vyřešení problému. Asi milionkrát lepší, než uživatel volající "pomooooc, mě půl hodiny nabíhají Xka a když kliknu na ploše na Seznam, tak mi nejde ten internet."
Koneckonců, i každý svéprávný programátor GUI aplikace se snaží o to, aby při vážném problému aplikace zobrazila chybu tak, aby ji uživatel mohl zachytit. Ne, aby to prostě spadlo. Ale to zoufalec pochvalující si to skvělé zlepšení, že uživatele na splashscreenu nevyrušují žádné chyby, stejně nikdy nepochopí.
Tak čau, mlamoji.
Co to meleš?
Pokaždé jsem prošel normálním instalátorem a pokaždé mi instalátor nějak nedokončil nastavení sítě a pokaždé mi to při startu vypisovalo hlášky při pokusu nastavit síť. Laskavě UTFG, tohle se stává spoustě lidem.
Kdyby jsi se nesoustředil jen na to, jak někomu něco trapně podsouvat mezi řádky (to bych do příspěvku musel opsat celou dokumentaci, aby na mě tobě podobný blbeček neměl co vykonstruovat) a přečetl jsi co jsem psal, tak by ti došlo, že jsem se ptal, jestli je lepší systemd nebo init?
Zbytek už jsou jenom tvoje debilní výplody o splashcreenu, maskování errorů, čtení konfigurace služeb z nepřipojených disků, nadávek a podobných <|> jako ty choré bláboly o Lennartových fotkách a ani už nevím co všechno jsi tam splácal dohromady a nyní, ještě vytáhneš nějaké lidi z nějakých diskuzí a oháníš se tím jako bych něco takového napsal.
K tématu systemd vs init jsi nenapsal absolutně nic, akorát pořád nadáváš, meleš něco o Lennartově fotce a nějaké podobné bludy, oháníš se nějakýma konfiguracema které máš jako za sebou, ale nedokázal jsi dát dohromady jedinou normální odpověď jako spousta ostatních, jenom pořád něco smýšlíš a pak dál podsouváš.
Připadáš si v pořádku?
Pokaždé jsem prošel normálním instalátorem a pokaždé mi instalátor nějak nedokončil nastavení sítě a pokaždé mi to při startu vypisovalo hlášky při pokusu nastavit síť.
A řešením je nevypisovat hlášky při pokusu nastavit síť. Vivat Lennart! Juchůůůůůůůů! To nevadí, že to nefunguje, chyba není vidět!!! Vyřešeno, hurááááááááááá! Chyby zásadně nezobrazoval a nikam nevypisovat, schovat je před uživatelem do logu je jediné správné a moderní řešení!!!
Připadáš si v pořádku?
Já ano, zato jedinec jásající nad tím, že teď je vše konečně správně, protože už mu konečně chyby neprobublávají na obrazovku a jsou výtečně skryty, zjevně příliš inteligence nepobral.
No, krom toho, že mi pořád podsouváš Lennarta, kterého, mít už mnohokrát po ruce, tak ho kvůli Alse zadupu do země a mám ho rád asi jako osinu v zadku, ze systemd nejsem nijak odvázaný, tak ok. Konečně už umíme zbytečně nenadávat a nevymýšlet hovadiny.
Hlášky na bootu jsou k ničemu (krom těch, kvůli kterým opravdu systém ani nenaběhne). Proběhnou rychle, i když si to stopneš, nejdou zkopírovat, stejně nevíš co bylo předtím a potom, stejně lezeš do logu. Dobře, uznávám že něco se objevit může, ale stejně nakonec končíš v logu a pokud nejsou fatální, tak se stejně hov. děje, systém naběhne a lezeš do logu. Ať tak nebo tak, v initu, pokud vím ještě, to byly printy do kozole, pokud se nepletu a ne nějaký promyšlený systém upozornění uživatele. Klidně se pak dal použít a zkontrolovat syslog. Aby sis nemyslel, já naopak všechny hlášky miluji a řeším je, proto jsem i řešil každou tu blbost na bootu s initem. Strašně nerad před errory strkám hlavu do písku.
"Já ano, zato jedinec jásající nad tím, že teď je vše konečně správně, protože už mu konečně chyby neprobublávají na obrazovku "
Probublávání není o tom, vypsat něco na obrazovku, ale odchytit a zaznamenat vyjímku tam, kde se má na její význam reagovat a rozhodnout o dalším toku programu. Promiň, prostě si myslím, že v moderním OS jako je i Debian, je volovina vypisovat uživateli něco čemu stejně nerozumí přes půl obrazovky, akorát ho to plaší, ale má se po naběhnutí systému zobrazit případný výčet a možnost logy normálně použít pro řešení. Ale tak jako beru i ostatní názory. Třeba se pletu. Jen nemám rád nadávky a když mi někdo tvrdí, že jsem řekl něco, o čem vím že e hovadina a nevypustil bych to z úst.
Hlášky na bootu jsou k ničemu (krom těch, kvůli kterým opravdu systém ani nenaběhne).
Ale hovno, prave barevne odlisene chybove hlasky pri bootu si clovek vsimne spis, nez neceho v logu. Zejmena pokud se cloveku ze systemu podari vykopat vselijake dementni Plymouthy, skryvani hlasek a kde co, co se snazi textovy boot nahradit nejakym nesmyslem. Krome toho ne vsechny hlasky z pbrazovky maji odpovidajici polozku v nejakem logu. I kdyz s Poetteringovym blobem by udajne mely byt odchyceny i hlasky, ktere vznikly pred namontovanim disku RW, tak je otazka, jestli se k nim clovek dostane. Je tu nekdo, kdo se uz poklousel cist Poetteringovy binarni logy? BTW, bootovaci obrazovku vidim pri kazdem bootu, existuje sance, ze si hlsky vsimnu. Ale do logu po kazdem bootu nelezu.
Promiň, prostě si myslím, že v moderním OS jako je i Debian, je volovina vypisovat uživateli něco čemu stejně nerozumí přes půl obrazovky, akorát ho to plaší, ale má se po naběhnutí systému zobrazit případný výčet a možnost logy normálně použít pro řešení.
Tak blby uzivatel si muze nainstalovat Plymouth, nastavit tak, ze se mu tam budou ukazovat akorat nejake nic nerikajici ikonky nebo progress bar nebo co to ted frci a ma hlasky skryte a i bez Poetteringa. Uzivatel, ktery si nezaklada na podobnych picovinach, si necha po obrazovce rolovat hlasky, aby se o systemu dozvedel vic, nez pri bootu Widli, ktere leda tak vytuhnou s hlaskou, ze se *neco* posralo.
Lennart je mi někde ... psal jsem to v příspěvku někde nahoře, taky hlavně jsem se ptal, že nevím jestli je systemd lepší než init, ale na co číst vlákno když se chci jenom navážet a trapně pindat, že?
Jinak na obrazovku patří hlášky jenom pokud neběží logovací služba. To už je ale zřejmě moc na pochopení. Přečti si někdy něco na téma jaké hlášky uživatele vůbec zajímají a zamysli se nad tím, že pokud mu systém nepadne a na obrazovce problikne za pár sekund při startu systému několikrát 10 řádků výpisu, je mu to bliknutí celkem k <|> a stejně poleze do logu.
Klidně si vřískej, ale to na situaci nic nemění . . .
> Jinak na obrazovku patří hlášky jenom pokud neběží logovací služba. To už je ale zřejmě moc na pochopení.
Nevím, kdo o tom rozhodl, že "nepatří". Nějaká komise? :)
Mně se třeba jednou stala taková prima věc: nabíhá Linux se systemd, splashscreen vypnutý, objevují se hlášky o startování jednotlivých služeb a v tom jedna z těch služeb nestartuje - motá se u ní takový to motadlo. Hláška samozřejmě žádná - je někde v tom slavném binárním logu. Nevím, co se děje. Mám počkat ještě pět minut? Půl hodiny? Hodinu? Není to nějaká chyba v systemd, takže to takhle sůstane viset na věky a na spuštění loginu vůbec nedojde? Zobrazí se mi po půl hodině hláška "Jejda! Něco se pokazilo"? Nebo "Došlo k chybě. Kód chyby: NO ERROR"? Objeví se okýnko "Zavolejte administrátora"?
No víte, už se v tom celkem motám. Ono to totiž co jsem psal začalo tak, a tak to i myslím, ne že by se vůbec neměly objevovat hlášky při problémech, ale přesně to jak jsem psal, to co se mi reálně stalo:
Vyskočí mi 10 řádků výpisu nějaké části co měla směřovat do logu - čas - nějaké hodnoty, věty .... a za 10 vteřin je to fuč. A co teď jako s tím?
Nebo klasika "Waiting for network confi ..... 60 sec ...." a čeká ..... A co jako s tím? Jak mi to pomohlo?
Po startu systému stačí vyhodit v liště warning s odkazy na errory a je to. Hotové.
Samozřejmě dokud nejede logovací daemon, tak chyby na obrazovku, ale to ani systém nenaběhne, stejně lezete do logu a stejně čtete logy od začátku.
Každopádně když Vám zůstane viset sys při startu tak co uděláte? Zase musíte manuálně do systému i kdyby Vám to na obrazovku vyhodilo chybu i s řešením, jenže to nezkopírujete a musíte systém vypnout, takže zase lezete do logu.
Jen musím znova dodat - neobhajuji systemd, nevím jestli je lepší než init nebo něco jiného a proto jsem se tu ptal na názory ( toto celé vzniklo z toho že se tu do mě začal trapně navážet LoL Phirae a stočilo se to až sem na nějaké logování. jen píšu názor - jinak je mi celkem u prdele jestli se to píše na obrazovku, stejně si většinou u startu sys vyzouvám boty ) a nelíbí se mi na systemd už ani to jak je nokompatibilní s ostatními
Prosím nedělejte z Nás obou blby, Kód chyby: NO ERROR je volovina, takové nicneříkající nic je k ničemu ale dají se dávat i normální error kódy
> Vyskočí mi 10 řádků výpisu nějaké části co měla směřovat do logu - čas - nějaké hodnoty, věty .... a za 10 vteřin je to fuč. A co teď jako s tím?
Ale ty hlášky přece směřují do logu - ale zároveň se vypisují do konsole. Pokud je to za 10s pryč, tak je to dobře, protože to znamená, že systém naběhl a můžu si to v logu přečíst. Horší je opačný scénář - systém nenaběhne, čili z logu si to přečíst nemůžu a na obrazovce si to nepřečtu, protože to tam "nemá být".
> Nebo klasika "Waiting for network confi ..... 60 sec ...." a čeká ..... A co jako s tím? Jak mi to pomohlo?
No velice zásadně - vím, že to nenabíhá kvůli konektivitě. Čili buď tu konektivitu umím hned napravit (např. zastrčit vytažený kabel), anebo u nejklasičtějších initů umím využít i toho, že ten skript běží na popředí - čili stačí zmáčknout klasické CTRL+C a jede se dál bez čekání. Systemd (a ostatní systémy pro paralelní spouštění) už tohle neumožňují - procesy běží kdesi na pozadí a dostat se k nim dá jenom přes nějaké spešl API - úplně přesně jako na Windows, se všemi souvisejícími nepříjemnostmi.
> Prosím nedělejte z Nás obou blby, Kód chyby: NO ERROR je volovina, takové nicneříkající nic je k ničemu ale dají se dávat i normální error kódy
To byl samozřejmě nejapný vtip: je to typická hláška z Windows. Tak daleko snad zwindowsovatění Linuxu ještě nedošlo ;)
No když jsem viděl " Kód chyby: NO ERROR " tak mě taky hned napadly Win :-D.
Šlo mi o to, že mi to většinou probliklo a stejně jsem musel lézt do logu, ale dole Trident už mi to vysvětlil proč je dobré to tak nechat, ok, beru. mě to nevadilo ani před tím, to vzniklo z toho, že mi tu TroLL Phirae začal podsouvat že maskuju errory a pak si myslím že je vše ok a takové koniny no a pak už jsem se asi nechal vtáhnout do těch konstrukcí .....
Jinak na obrazovku patří hlášky jenom pokud neběží logovací služba.
Pochopitelně. Takže např. když kopíruju nebo ukládám soubory a operace selže, tak to potichu zaloguju, aby si toho uživatel nedejbože náhodou nevšiml a nevyrušila ho taková prkotina. Software design by idiot.
Rekni mi kolik mas pod palcem masin, kolik jsi delal embedded systemu a jak jsi delal diagnostiku. At uz velkyho nebo malyho zeleza. Pokud bootujes server potrebujes vedet co se pri bootu deje pripadne ho odladit. Ten vystup na konzoli muze byt klidne nekam na seriovy port na systemovou konzoli( non-x86 velke platformy na to maji treba specialni device(ale ptaci stejne nonx86 architektury stejne temer nepodporujou), nebo to potrebujes hned videt na KVM rozhrani v managementu serveru. Ty treba nemas sanci se dostat k logu nebo neni kam logovat protoze system je tak nakopnuty. A kolikrat ani nemuzes protoze to z bezpecnostniho hlediska neni uplne mozne(logy se neukladaji)
Co budes delat pane kakademiku? Je ti jasne ze nahodit system ze site/z CD nemusi byt v mozne? J ti jasne ze cekani na pristup k logu je jak cekani na ......
Vubec co vedej vasnosti vo juniksech? Sto takoje possssiksss? Tyhle radoby linuxaci radi obracej to co bezmala 50 let funguje a funguje to dobre. Pak pride nagelovany startupovy blbitko a misto pokory a studia co je udelano jak to funguje vymysli nakou naprostou ptakovinu a misto toho aby zdokonalilo stavajici system, tak vymysli system novy ktery sice fixuje nevyhody predchoziho systemu, ale funkcni veci z predchoziho systemu neimplementuje stejne funkcne, spolehlive a jednoduse. Namisto toho si okolo toho vseho vytvori prakticky vedni obor a sektu uctivacu. Well played, Lennart o great one!
Systemd neni odpad protoze zakladni myslenka je spatna, systemd je odpad protoze implementace(impdementace - implementace dementem).
No vidiš. Tak nějaké emmbed má za sebou mám své vlastní virtuální servery a dělal jsem i se serverovým "železem" přímo ve firmě. Je fakt že jsem nikdy ale nepřišel do styku s takovými případy, z mého pohledu vyjímečnými, jak píšeš.
Hele, faln, tomu co píšeš rozumím a kdyby jsi mi to napsal bez těch zbytečných urážek a machrovinek, fakt bych si tvého názoru vážil ještě mnnoho mnoho více. Každopádně jsi 1. za dva dny, kdo mi dokázal napsat, proč se pletu s těmi hláškami na startu a ne jen sady konstrukcí "kdyby byly v řiti ryby .....". Díky. Beru, nemám s tím problém.
Celé moje provinění akorát začalo tím, že jsem chtěl vědět, jestli je lepší systemd nebo init z pohledu někoho, kdo do toho fakt vidí. I já,jako ne-super-odborník jsem si všiml, že by chtěl init vylepšit, ale z toho co jsem četl o systemd jsem nabyl dojmu, že to je tak trošku čuňárna. Tak jsem si dovolil se zeptat a už to jelo ....
Jaky machrovinky? Clovek co s unixy dela a pouziva je vsestranne a coby soucast rozsahle infrastruktury vcetne specialnich embedded systemu(nemusi byt vzdy unixy) tak v zivote ani nepomysli na kraviny co najde v systemd. Clovek ktery se zabyva castecne i kritickymi systemy a human factors by v zivote nenapsal kravinu typu "NO ERROR" a nepouzival by slozita reseni na jednoduche problemy - dbus a nepouzival by nabobtnaly monolit a staticky linkovanou glibc.
Jde o to ze linux se pouziva velice vsestranne a systemy jsou take velice vsestranne nasazovany. Vem si ze mas zakose kde je treba vycuc konzole logovan primo po siti nekam jinam na logmasinu protoze neni zadouci aby se ten log na masine ukladal. Jak odladis boot kdyz ti jeste nenaskocil log daemon? Co kdyz ti vyhnije?
Slozity problemy ktere jsem popsal byly typicky zakysy na SAN infrastrukture kdy se k logum na rozhasenem fs(na lun snapshotu) neslo dostat. Navic kdyz nemas centralni logovani na dane casti infrastruktury tak si loguj kdyz ti odchazi disk a log fakt nejde zapsat.
Pisi tady o rozsahu infrastruktury tisice fyzickych stroju - ruzna linuxova distra(predevsim RHEL),AIX,Solaris,VMS,HP-UX a par upgradovanych zvejkadel dernych stitku se zOS. Nepocitam embedded veci a letectvi - to resi tym prumyslovych ptakovin, ale obcas jim svou dusi taky projektove zaprodam abych nezdegeneroval v podnikoveho ajtaka nebo manazera.
"Co budes delat pane kakademiku?"
"Vubec co vedej vasnosti vo juniksech? Sto takoje possssiksss? "
Ale možná už jsem byl jen trochu podrážděný, protože se mi tu dostávalo nadávek, všeobecných všemouder a kdejakých konstrukcí pořád. Tak se omlouvám. Každopádně děkuji, opět jsem se něco dozvěděl.
splashscreen dela jen plymounth a neni problem se ho zbavit .....
O tom, jak není problém se plymouthu zbavit, běž vyprávět třeba soudruhům z Ubuntu.
Bug 531331 - Remove plymouth destroying system
Plymouth is not a bootsplash
To už jsme řešili nedávno pod jiným článkem/zprávičkou. V Debianu taky stačí "sudo apt-get purge plymouth plymouth-theme" a je vystraráno. U Ubuntu to sebou vezme tuším celý/většinu desktop(u) :). Vzhledem k té změně závislostí Debian vs Ubuntu to určitě není chyba, ale záměr :-). Výběr distribuce je každého jeho vlastní rozhodnutí a problém...
Distribuce byly donuceny. Aplikace ztratily funkcionalitu, kterou mely drive, protoze vyvojari systemd tuto funkci implementovali (zde je problem, ze obvykle chybove a nespolehlive) a puvodni aplikace prestaly fungovat (naposledy mam problem skutecne vypnout vestavene NTP a pouzit klasicke NTP, protoze s vestavenym do systemd mi ujizdi cas).
Druha pulka pohledu na tuto situaci je ta, ze mnohe aplikace zacaly zaviset na funkcionalite systemd bez moznosti volby (napriklad GNOME). Takze pokud chces nove GNOME, tak musis mit systemd. To zpusobuje docela problem pro ne-linuxove systemy, ktere jsou bez systemd. Napriklad *BSD. Takze FreeBSD resi, jestli neimplementovat falseny systemd kvuli vecem jako GNOME.
To, ze je aplikace moloch, ktera Ti i utre zadek je jen mala drobnost ve svetle ostatnich problemu. Restart po upgrade systemd je radost vzdy, pravidelne se mi zasekne vypinani/restart na nejake sluzbe, kterou ani nepotrebuji a podobne.
Aha, no já si to tak trošku myslel, akorát nejsem aktivní vývojář okolo nějaké distribuce, takže nemám info z první ruky a ty články o tom jsou buď hate nebo love, každý sype to svoje a prase aby se v tom vyznalo ... Mě se na tom hlavně nelíbilo, že je to takový všepohlcující blob na věčné časy a nikdy jinak ... a na to jsem velice skeptický
Není to žádný blob, je to spousta malých nástrojů, které se akorát vyvíjejí pod jednou střechou a umí spolupracovat. Není ale problém do toho zaintegrovat své vlastní nástroje, nebo ty z rodiny systemd nahradit něčím jiným. Naopak si myslím, že koncepce, na které staví systemd, v budoucnosti umožní větší variabilitu služeb, protože definuje standardní rozhraní, jakým mezi sebou mohou komunikovat závislé služby.
> Naopak si myslím, že koncepce, na které staví systemd, v budoucnosti umožní větší variabilitu služeb
No... https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ - sloupeček Reimplementable Independently...
Ono je potřeba si k tomu přečíst i ten první sloupeček. To, že systemd pracuje se soubory ve formátu Unit File, a když mu předhodíte nějaký jiný formát, nebude s ním sám od sebe umět pracovat, je logické. To je jako byste vytýkali Perlu, že si neporadí se skriptem napsaným v Pythonu.
Chtěl jsem jenom upozornit na to, že kdyby to s tím API bylo tak růžové, tak by systemd nikoho nevzrušoval. Kromě sloupečku 1 je taky spolupeček 7, kde je vidět, že komponenty, které by snad měly být reimplementovatelné, nikdo neimplementoval. Asi z nějakého důvodu.
Existence API totiž sama o sobě nic neslibuje. Důležité je hlavně, jak je to API stabilní (to se snad poslední dobou zlepšilo a existuje i nějaký slib stability aspoň něčeho) a hlavně jestli je to API obecné nebo reflektuje designované volby implementátora (takže ho sice reimplementovat můžu, ale musel bych defacto napsat ten stejný kód, což by mi nijak nepomohlo). A tady u toho druhého bodu si nejsem moc jistý. Kdyby to totiž bylo tak růžové, neměli by vývojáři *BSD a Gentoo takové vrásky na čele...
-systemd code too co-dependent on other systemd libraries/components
-can't port/recreate any low-level functionality
-horrible idea anyway
http://darknedgy.net/files/systembsd.pdf
Chtěl jsem jenom upozornit na to, že kdyby to s tím API bylo tak růžové, tak by systemd nikoho nevzrušoval.
Tohle vůbec není pravda. To, co na tom nejvíce vadí, je to, že je to nové, poukazuje to na chyby v tom starém, je moderní na to nadávat, a stojí za tím kontroverzní autor. Až na ten poslední bod je to úplně stejné, jako nadávky třeba na IPv6 nebo btrfs. No a někde v koutku vedle těchhle hlasitých odmítačů jsou pak ti, kteří tiše věcně kritizují věci, které jsou na systemd (IPv6, btrfs) opravdu nešťastně řešené, nedotažené apod.
Stabilita a obecnost API je sice hezká věc, ale hrozí, že bude nějaká komise nejprve několik let navrhovat obecné stabilní API, aby se pak ukázalo, že to v praxi nevyhovuje. API podle potřeb konkrétního projektu má tu výhodu, že jsou hned vidět výsledky a to API se dá prakticky používat.
Ona je to s tím API totiž taková výmluva. Až tu bude nějaký projekt, který to API využívá, a kvůli změně v API systemd přestane ten projekt fungovat, pak bude možné tvrdit, že je chyba v nestabilitě API systemd.
Primární problém je totiž v tom, že původní správa služeb přes SysVinit a skripty byla tak zastaralá a zatuhlá, že udělat to dnes pořádně znamená implementovat spoustu nové funkcionality. Takže kdyby chtěl někdo reálně konkurovat systemd, musel by toho také sám spoustu implementovat – a do toho se nikomu nechce.
Po té nové funkcionalitě byla evidentně velká poptávka, proto najednou na systemd závisí tolik věcí. Což není důkaz rozpínavosti systemd, jak to někteří interpretují – protože systemd nemá žádné prostředky, jak donutit programátory nebo správce distribucí, aby na něm začali záviset.
Nikomu nic nebrání vytvořit svůj software, který bude nabízet lepší služby, než systemd. Nikomu nic nebrání vytvořit stabilní a obecné API, do kterého systemd zabalí. Celý problém systemd je v tom, že nikdo nevytvořil nic lepšího. Kdyby vytvořil, vývojáři i distribuce na to s radostí přejdou, a autorům systemd nezbyde, než implementovat to stabilní a obecné API toho lepšího systému.
> To, co na tom nejvíce vadí, je to, že je to nové, [...]
Asi jak kde. V *BSD světě na tom lidem vadí, že je to by-design Linux-only a že aplikace na tom začínají záviset. Čili *BSD se dostává do situace, kdy si může vybrat buď GNOME úplně zaříznout (nikdy už na BSD nebude) nebo reimplementovat systemd. Obojí je opruz. A nejhorší na tom je, že úplně zbytečný.
> ale hrozí, že bude nějaká komise nejprve několik let navrhovat [...]
Pokud je funcionalita jednoduchá, jasná a obecná, tak nevím, co by na tom komise řešila. Co je ta bájná funkcionalita? V principu jenom nastavit nějaké parametry systému (locale, hostname apod.), spustit a monitorovat služby apod. Není na tom nic světoborného, co by potřebovalo API o stovkách položek.
> Primární problém je totiž v tom, že původní správa služeb přes SysVinit a skripty byla tak zastaralá a zatuhlá
Opakuju: mnoho let existuje OpenRC, launchd, SMF, supervisord ... těch alternativ je spoustu. Není to "hnusné initskripty" nebo systemd. To je strawman.
> Po té nové funkcionalitě byla evidentně velká poptávka
Konkrétně prosím! Po jaké funkcionalitě? Nemám systemd kdovíjak nastudované, ale ještě jsem neslyšel o ničem, co by řešil a nedalo se to udělat jinak.
> protože systemd nemá žádné prostředky, jak donutit programátory nebo správce distribucí, aby na něm začali záviset. [...] Nikomu nic nebrání vytvořit svůj software, který bude nabízet lepší služby, než systemd
Jistě. To je stejně validní argument jako "nic nenutí lidi používat Windows". Pěkně silné "nic"...
Konkrétně prosím! Po jaké funkcionalitě? Nemám systemd kdovíjak nastudované, ale ještě jsem neslyšel o ničem, co by řešil a nedalo se to udělat jinak.
No, já jsem třeba hrozně poptával nový resolver, protože tu máme akutní nedostatek DNS serverů. Výtečným nápadem byla taky implementace dostatečně debilizovaného (S)NTP klienta. Kritický nedostatek syslog démonů byl geniálně vyřešen implementací binárního blobu, která bobtná do velikostí mnoha gigabajtů a opravit ho jde pouze smazáním. Prostě tomu vůbec nerozumíš, bez Lennarta a podobných průkopníků bysme ještě lezle po stromech. :-P
> bez Lennarta a podobných průkopníků bysme ještě lezle po stromech. :-P
Mně osobně je Lennart ukradenej, jeho chování a spory s některými developery jsou pro mě jenom takové vtipné historky z natáčení - Linux používám minimálně, kde můžu, mám FreeBSD. Rozlaďuje mě spíš to, že dokud byl linuxový svět malinký pidižvýček oproti drtivě majoritním Windows, mluvilo se o spolupráci, standardizaci, otevřenosti, přenositelnosti - a teď najednou, když se Linux rozšířil všudemožně (kromě desktopu), tak najednou vlastně standardy nejsou důležité, jde o vytvoření "moderní post-unixové platformy" a ostatní unixoidní systémy ať si trhnou nohou (nebo reimplementují řešení, která si vymyslíme my).
Prostě Linux jako celek (jo, vám, že to je nekorektní) se bohužel posunuje k chování, které bylo dřív typické pro Windows - systém kompatibilní jenom sám se sebou, totálně ignorující okolí. Navíc těch podobností je čímdál víc i v technické rovině (binární formáty, automagická řešení, do kterých nikdo nevidí, neproniknutelné závislosti,... už zbývá jenom řešení problémů reinstalací :( ).
Jak byste si to představoval jinak? Máme na Linuxu solidárně dál používat nevyhovující správce služeb z minulého století, protože v *BSD nejsou schopni naimplementovat funkcionalitu, kterou moderní správce služeb potřebuje? Není lepší to implementovat alespoň pro Linux, vyzkoušet a ověřit, a až bude existovat nějaké stabilní řešení, můžou si to lidé z *BSD portovat k sobě? Ano, nevýhoda je, že po něčem, co řeší systemd, byla evidentně velká poptávka, takže se masově nasazuje už v době, kdy ještě není stabilní a portace by byla komplikovanější. No jo, ale to je problém toho, že tu poptávku neuspokojil nikdo před systemd. Přitom tu možnost měl každý.
> Jak byste si to představoval jinak? Máme na Linuxu solidárně dál používat nevyhovující správce služeb z minulého století
Prosím o konkrétní vyjmenování, v čem jsou alternativy systemd nevyhovující. Se zřetelem k launchd, SMF a klidně i init skriptům FreeBSD.
> protože v *BSD nejsou schopni naimplementovat funkcionalitu, kterou moderní správce služeb potřebuje?
Jakou funkcionalitu? Třeba cgroups? Vývojáři BSD nejsou schopní BSD udělat tak, aby bylo přesně stejné jako Linux? Vývojáři BSD jsou pitomci, protože nechtějí mít systemd jenom kvůli tomu, aby fungovalo Gnome? WTF?! OSS už není o možnosti volby, ale o tom, že kdo nepřijde systemd, ten je pitomec?!
> Není lepší to implementovat alespoň pro Linux, vyzkoušet a ověřit, a až bude existovat nějaké stabilní řešení, můžou si to lidé z *BSD portovat k sobě?
Systemd nikdy portovat nepůjde, protože je neportovatelný by design. To je ta pointa.
> po něčem, co řeší systemd, byla evidentně velká poptávka
Pořád jsem ještě neslyšel konkrétně po čem. Je to fakt tak těžké vyjmenovat?
> No jo, ale to je problém toho, že tu poptávku neuspokojil nikdo před systemd. Přitom tu možnost měl každý.
Windows se asi taky rozšířily kvůli nějaké poptávce. Nikdo jiný ji neuspokojil. Přitom tu možnost měl každý. Tak jo no...
Vývojáři BSD nejsou schopní BSD udělat tak, aby bylo přesně stejné jako Linux?
Kde jsem psal, že se to má udělat „přesně stejně“? Ať si to vývojáři *BSD udělají, jak chtějí, klidně ať upraví systemd tak, aby fungoval i bez podobné služby. Kdo by to měl udělat jiný?
Vývojáři BSD jsou pitomci, protože nechtějí mít systemd jenom kvůli tomu, aby fungovalo Gnome?
Vývojáři BSD jsou pitomci, pokud nechápou, že když nechtějí mít systemd, musí Gnome opatchovat tak, aby fungovalo i bez systemd, nebo musí služby, které Gnome poskytuje systemd, implementovat sami. Ale já si myslím, že vývojáři BSD to chápou, že to nechápou jenom někteří diskutující.
Systemd nikdy portovat nepůjde, protože je neportovatelný by design.
To je zvláštní, že se běžně portují programy z Unixů do Windows a opačně, u kterých s portací původně nikdo nepočítal, a jde to. Co je na systemd tak specifického, že je neportovatelný by design?
Pořád jsem ještě neslyšel konkrétně po čem. Je to fakt tak těžké vyjmenovat?
Já netuším, po čem všem ta poptávka je. Ale jak už jsem psal, předpokládám, že když nějaký vývojář zatáhne do svého programu závislost na systemd, má k tomu dobrý důvod. Nebo vy si myslíte, že to vývojáři dělají jen tak z rozmaru, nebo aby něčím naštvali Mirka Prýmka?
Windows se asi taky rozšířily kvůli nějaké poptávce. Nikdo jiný ji neuspokojil. Přitom tu možnost měl každý. Tak jo no...
Před nástupem Windows měl tu možnost každý.
Pořád píšete, jakoby do Gnome tu závislost na systemd nepřidali vývojáři dobrovolně, jako by je k tomu někdo ze systemd donutil. Ale ani jednou jste nenapsal, jak je k tomu donutili, jaké mají vývojáři systemd páky na vývojáře Gnome.
> To je zvláštní, že se běžně portují programy z Unixů do Windows a opačně, u kterých s portací původně nikdo nepočítal, a jde to. Co je na systemd tak specifického, že je neportovatelný by design?
To je vtip? Budeme srovnávat portovatelnost init systému, úzce provázaného s kernelem, s nějakou aplikací, která interaguje jenom s knihovnami?!
> Já netuším, po čem všem ta poptávka je.
Ok. Tak s tím přestaň operovat.
> Ale jak už jsem psal, předpokládám, že když nějaký vývojář zatáhne do svého programu závislost na systemd, má k tomu dobrý důvod.
Jasně. A ten důvod může být třeba ten, že většina dister na systemd přešlo a cokoli jiného je mu u prdele.
> Nebo vy si myslíte, že to vývojáři dělají jen tak z rozmaru, nebo aby něčím naštvali Mirka Prýmka?
Mě tím rozhodně nenaštvou. Gnome nepoužívám a kdyby na BSD nebylo, je mi to úplně jedno. Ale je mi líto, že se z linuxové komunity - s jasným zaviněním konkrétních jedinců - stávají fanoušci jednoho konkrétního systému a na spolupráci kašlou.
> Pořád píšete, jakoby do Gnome tu závislost na systemd nepřidali vývojáři dobrovolně, jako by je k tomu někdo ze systemd donutil. Ale ani jednou jste nenapsal, jak je k tomu donutili, jaké mají vývojáři systemd páky na vývojáře Gnome.
A uživatele Windows někdo "donutil" používat Windows? Stál jim za zády s bouchačkou? Ne. Windows se prostě rozšířily a staly se monopolem, protože nebyly s ničím kompatibilní a způsobily lock in. Něco velmi podobného se může stát s linuxovým světem - stačí si představit, že podobně jako Gnome by se zachovali vývojáři různého jiného serverového sw. A juchů, Linux by byl monopolní serverový systém. Protože OSS je přece o svobodě volby...
Budeme srovnávat portovatelnost init systému, úzce provázaného s kernelem, s nějakou aplikací, která interaguje jenom s knihovnami?!
Systemd není úzce svázán s kernelem, pouze vyžaduje určité služby od jádra operačního systému. Což je úplně stejné, jako ty „nějaké aplikace, které interagují jenom s knihovnami“ – některé ty knihovny totiž tvoří pouze rozhraní k jádru operačního systému. Pokud dnes systemd používá některé služby, které jsou specifické pro Linux, není problém okolo těch služeb udělat obecnou knihovnu, systemd přepojit na tu knihovnu, a třeba na *BSD tu knihovnu implementovat jiným způsobem, s prostředky příslušného jádra. Nebo je možné nepoužívat příslušnou část systemd, která je na té službě linuxového jádra závislá. A nebo třetí možnost, fňukat, že my to chcem taky, ale nikdo to za nás neudělá, což je hrozně nespravedlivé.
Tak s tím přestaň operovat.
Myslíte, že když o té poptávce nebudeme psát, tak zmizí? Pokud k tomu takhle přistupujete, že když je někde nějaká poptávka, vy se tváříte, že ji nevidíte a že tím pádem neexistuje, nesmíte se pak divit, že přijde nějaké systemd, netváří se, že tu poptávku nevidí,a zareaguje na ní.
A ten důvod může být třeba ten, že většina dister na systemd přešlo a cokoli jiného je mu u prdele.
Jo, takže vývojář si tak se dí u počítače, a říká si: „Já systemd vůbec nepotřebuju. Ale většina distribucí na něj přešla, tak já schválně do aplikace tu závislost na systemd přidám. Sice mi to nic nepřinese, budu s tím mít akorát práci, ale naštvu tím Prýmka, a top je to hlavní!“
na spolupráci kašlou
Pěkně prosím, jak byste si takovou spolupráci představoval? To jako že linuxový komunita vyčlení pár dobrovolníků, kteří budou portovat věci z Linuxu do *BSD?
Windows se prostě rozšířily
Pokud vím, bylo to trochu jinak, než že se „prostě rozšířily“.
staly se monopolem, protože nebyly s ničím kompatibilní a způsobily lock in.
Jenže ta nekompatibilita a lock in byl záměr a Microsoft se alternativám aktivně bránil. Pamatujete války o souborové formáty kancelářských balíků? Nikdo tenkrát nechtěl, aby Microsoft naprogramoval Office pro Linux – chtěli jsme jenom znát specifikace souborových formátů, abychom si kompatibilní software mohli napsat sami. A i tomu se Microsoft bránil.
Brání snad někdo zveřejnění API systemd? Nebrání, jak také, když je systemd open source. No, ale psát alternativy k systemd opravdu není úlohou vývojářů systemd, stejně jako není úlohou linuxové komunity portovat software na *BSD. Stejně jako jsme nikdy nechtěli, aby Microsoft portoval Office na Linux.
stačí si představit, že podobně jako Gnome by se zachovali vývojáři různého jiného serverového sw. A juchů, Linux by byl monopolní serverový systém.
Ale nebyla by to chyba lidí od linuxu, ale těch, kteří nenapsali alternativy, přestože jim v tom nikdo nebránil.
Protože OSS je přece o svobodě volby...
No právě. OSS je o svobodě volby. Takže když se jako vývojář rozhodnu, že mi systemd přináší nějaké výhody a vyplatí se mi udělat na něm můj program závislým, je to moje svobodná volba. A někdo jiný má zase svobodnou volbu napsat alternativu k systemd se stejným rozhraním, nebo dokonce napsat něco lepšího než systemd, co povede k tomu, že opustím závislost na systemd a přejdu na to nové. A nebo tu mou aplikaci upraví tak, aby fungovala i bez systemd, jenom nebude poskytovat ty služby, ke kterým využívá systemd. To všechno je svoboda volby.
Vaše představa je asi taková, že by vývojáři systemd měli povinně naprogramovat minimálně dvě alternativy k systemd, a to navíc i pro všechny odnože BSD. V tom já ale žádnou svobodu volby nevidím.
Systemd není úzce svázán s kernelem, pouze vyžaduje určité služby od jádra operačního systému. Což je úplně stejné, jako ty „nějaké aplikace, které interagují jenom s knihovnami“
Vidím, že ten odkaz na Lennartovo vyjádření jsi stále nenastudoval a úspěšně pokračuješ v exhibici vlastní debility.
> Systemd není úzce svázán s kernelem
Tak jo no...
> Myslíte, že když o té poptávce nebudeme psát, tak zmizí?
Ne. Myslím, že když něco neumíte konkrétně vyjmenovat, tak byste neměl šermovat s tím, že to na obecné rovině zcela určitě existuje protože a poněvadž pakliže proto.
> No, ale psát alternativy k systemd opravdu není úlohou vývojářů systemd, stejně jako není úlohou linuxové komunity portovat software na *BSD.
To jsem ani nechtěl. Nebudu to vysvětlovat znova, můžete si to přečíst znovu a pozorněji výš. Jestli něčemu na tom výš řečeném nerozumíte, zeptejte se, třeba jsem se vyjádřil nejasně. Ale opakovat se nebudu.
> A někdo jiný má zase svobodnou volbu napsat alternativu k systemd se stejným rozhraním
Problém je, že vy si to představujete jako hurvínek válku. Chápete to, že *BSD je prostě jiný kernel? Že má úplně jiné vlastnosti? Že nejde jenom tak snadno napsat nejakou mezivrstvu emulující chování Linuxu? A že je to úplně zbytečná práce, protože systemd nepřináší nic tak zásadního, aby to nešlo bez toho.
> Vaše představa je asi taková, že by vývojáři systemd měli povinně naprogramovat minimálně dvě alternativy k systemd, a to navíc i pro všechny odnože BSD.
Ne. Vývojáři systemd si můžou dělat co chtějí. Můžou si do systemd integrovat klidně i Xka (btw, provázání s Waylandem je určitě na spadnutí). Vy to můžete klidně obhajovat. Linus může klidně říct, že k tomu nemá žádný strong opinion. Dělejte si všichni co chcete, jste svobodní lidé.
Ale já si s dovolením vyhrazuji právo říct, že Linux windowsovatí a že je mi to líto. To je vše. A taky si dovolím vás poprosit, abyste mi nevkládal do úst svoje interpretace.
Ne. Myslím, že když něco neumíte konkrétně vyjmenovat, tak byste neměl šermovat s tím, že to na obecné rovině zcela určitě existuje protože a poněvadž pakliže proto.
Geniální. Tvrdíte, že existuje ČR? Dobře, tak vyjmenujte její obyvatele.
Chápete to, že *BSD je prostě jiný kernel? Že má úplně jiné vlastnosti? Že nejde jenom tak snadno napsat nejakou mezivrstvu emulující chování Linuxu?
Já to chápu. Ale nechápu, jaké vy navrhujete řešení. Linux má nějaké vlastnosti, které se hodí autorům určitého programu. Napadají mne jenom následující možnosti:
Autoři toho programu používají Linux, tak tu vlastnost použijí. Pokud bude někdo chtít použít daný program pod *BSD, bude muset příslušnou funkcionalitu implementovat s prostředky *BSD.
Nebo autoři Linuxu danou vlastnost vůbec neimplementují, protože ji nemá *BSD, a kdyby to někdo použil, byl by jeho program závislý na Linuxu.
Nebo autoři danou vlastnost implementují do Linuxu, ale zároveň ji povinně implementují i do *BSD, aby použití té vlastnosti neznamenalo závislost na Linuxu. Možná by to měli implementovat i do Windows?
Nebo autoři danou věc v Linuxu implementují, ale nikdo to nebude používat, aby nevznikla závislost na Linuxu.
Která varianta je podle vás správná?
Samozřejmě to platí i opačně, některé věci jsou implementované v některém z *BSD a nejsou v Linuxu, případně se jimi Linux dodatečně inspiruje. Nikdy jsem neslyšel, že by to *BSD někdo vytýkal.
A že je to úplně zbytečná práce, protože systemd nepřináší nic tak zásadního, aby to nešlo bez toho.
Vůbec nejlepší by bylo zůstat u děrných štítků. Terminály, klávesnice, dokonce grafická prostředí a myš nepřinášejí nic tak zásadního, aby to nešlo bez nich… Systemd evidentně něco přináší, když to lidé chtějí používat. Vaše neustálé fňukání, ať to vylepšení přestanou používat, protože když ho nemáte vy, nemá ho mít nikdo, je dětinské. Navíc, když to není tak zásadní, tak to přece půjde snadno obejít nebo implementovat jinak.
Ale já si s dovolením vyhrazuji právo říct, že Linux windowsovatí a že je mi to líto.
Takže přidání nové vlastnosti je windowsovatění. OK.
A taky si dovolím vás poprosit, abyste mi nevkládal do úst svoje interpretace.
Když ono je těžké vás pochopit, když pořád kroužíte kolem toho, že vám vadí, že Linux má nějakou vlastnost, kterou *BSD nemá, a považujete to za chybu linuxové komunity – ale přímo to napsat nechcete.
Geniální. Tvrdíte, že existuje ČR? Dobře, tak vyjmenujte její obyvatele.
Klamná indukce a klamná analogie.
Dokud nebudete konkretizovat tu poptávku po systemd, půjde jen o pouhou spekulaci s nulovou vypovídací hodnotou. Zdroje dokazující existenci ČR si laskavě najděte třeba na Wikipedii, pokud o tom pochybujete.
Kontrétně třeba GNOME používá logind:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Desktop_Migration_and_Administration_Guide/logind.html
Pokud vím, adekvátní ucelená náhrada k funkcím logind neexistuje. Myslí si to i vývojáři GNOME, a proto logind použili. Jasně, že by si to mohli implementovat sami a znovu, ale proč by to dělali? Prostě usoudili, že majorita jejich uživatelů systemd používá a nebude mít se závislostí na systemd problém. Ti, kteří systemd nechtějí, nebo nemůžou používat, si musí upravit GNOME, nebo napsat ekvivalent logind pro svůj systém. Jestli to bylo dobré nebo špatné rozhodnutí, ukáže čas. Pokud špatné, jejich uživatelé nebudou závislost na systemd akceptovat a přijdou o ně. Pokud dobré, ušetřili si práci při vývoji a můžou se soustředit na vývoj funkcí, které jejich uživatele chtějí.
> Pokud vím, adekvátní ucelená náhrada k funkcím logind neexistuje.
Jaké konkrétně Gnome získal funkce tím, že začal systemd používat? Co přesně umí teď, co předtím neuměl? A to nešlo tu funkcionalitu udělat jako volitelnou?
Netvrdím, že takové věci neexistují, ale nebaví mě šermování něčím, co asi teda možná existuje, nevím, co to je, ale určitě něco jo a proto je potřeba systemd a žádná jiná alternativa není.
Oni na to měli dřív svůj vlastní ConsoleKit: https://wiki.gnome.org/Projects/ConsoleKit
Takže v jednu chvíli byly dvě implementace, které poskytovaly podobné funkce (ConsoleKit a logind). Mohli zůstat nezávislí a paralelně s logind vyvíjet i ConsoleKit. Rozhodli se ušetřit si práci a použít logind, protože se jim zdál lepší. Jak říkám, jestli to bylo dobré nebo špatné rozhodnutí, ukáže čas.
No a jsme u jádra pudla: přenositelný ConsoleKit (Linux, BSD, Solaris) byl nahrazen Linux-only systemd.
No a jsme u jádra pudla. Já si myslím, že ta náhrada vyžadovala nějaké úsilí, a že ji tedy vývojáři provedli proto, že jim systemd oproti ConsoleKitu přinese nějaké výhody.
Od vás jsem se zatím nedozvěděl, jak měli ty samé výhody se stejným množstvím práce získat jinak.
Ochota a trpělivost některých lidí krmit trolly, kteří jsou schopni v blouznivých horečkách vypotit souvětí ala:"windows se rozšířili a staly monopolem prostě proto, že nebyly s ničím kompatibilní..." je unikátní a raritní. Prospěšnější by bylo jim doporučit teplou stravu a nápoje, placebo s vyraženým nápisem anti-lennart a pravidelné návštěvy obvodního lékaře.
Ale Lennart nestál u vývojářů s pistolí u hlavy a nedonutil je zahodit ConsoleKit a místo něj použít logind. Logind to vyhrál, protože si vývojáři GNOME myslí, že je prostě lepší. Nabízí jim více funkcí s menším úsilím. Nic víc za tím není. A že díky tomu GNOME přijde o nějaké uživatele? Možná ano, ale zase se můžou soustředit na vývoj jiných věcí, takže ve výsledku je to pro uživatele (smířené se systemd) výhra.
> ale zase se můžou soustředit na vývoj jiných věcí, takže ve výsledku je to pro uživatele (smířené se systemd) výhra.
Jasně, však to je legitimní, můžou si dělat co chtějí.
Je to stejně legitimní jako proprietární autentizace ve Windows - pro lidi, kteří mají windows a jsou s nimi smíření, je to určitě úplně bezva. A vývojáři v Microsoftu se aspoň nemusí zabývat implementací něčeho přenositelného/kompatibilního, takže pro uživatele je to jasná výhra.
Vůbec z Windows je ještě hodně čím se inspirovat. Vložit grafický subsystém do jádra, nebo aspoň do PID 1 by bylo určitě super, spoustu věcí by to zjednodušilo a zrychlilo, takže pro uživatele taky jednoznačně výhra.
Jo a taky myslím Lael říkal, že COM je daleko vyspělejší než DBUS. Možná by se na něj dalo přejít. Všichni správci linuxů se už těší na hlášky
Systém událostí modelu COM+ nemohl vytvořit instanci odběratele partition:{41E90F3E-56C1-4633-81C3-6E8BAC8BDD70}!new:{6295DF2D-35EE-11D1-8707-00C04FD93327}. CoGetObject vrátil hodnotu HRESULT 8000401A.
:)
Je tu takový drobný rozdíl. Ve Windows si tu proprietární autentizaci nijak nezměníte. V případě Gnome a systemd vám nic nebrání napsat ještě lepší implementaci a portovat na ni Gnome. Dokonce pokud bude o tolik lepší, jako byl systemd oproti předchůdcům, portují na to Gnome jeho vývojáři sami, jak se ukázalo v případě systemd.
To je hrozná demagogie, s Windows ani proprietárními produkty to vůbec nesouvisí.
Vývoj každého produktu, včetně GNOME, má za cíl uspokojit s co nejnižšími náklady co nejvíce uživatelů. Majorita uživatelů GNOME systemd používá. Nemají problém s tím, že GNOME na systemd závisí. Naopak vítají, že se vývojáři GNOME můžou soustředit na vývoj desktopu, místo reimplementace funkcí, které dělá systemd. Dostanou totiž lepší desktop. Podpora uživatelů bez systemd by stála vývojáře GNOME čas (peníze).
Kdo systemd nechce nebo nemůže používat, má volbu. Upravit si GNOME nebo implementovat funkce logind. Všechny informace k tomu má jednoduše dostupné.
Však jo, já nic z toho nezpochybňuju. Linux se klidně může úplně vykašlat třeba i na POSIX a začít fungovat úplně jinak, post-unixově. Bude to úplně nový, jiný systém, který už nebude mít s unixem nic společného. Proč ne? Pokud takový systém bude chtít někdo vyvíjet a někdo používat, je všechno naprosto v pořádku.
Jenom nevím, proč by si lidi, kteří měli Linux rádi kvůli jeho unixovosti a kompatibilitě, nemohli postesknout po starých dobrých časech. Tak nám to dopřej, ne? :)
Poptávku už jsem dávno konkretizoval. Jsou to všechny ty kritizované přidané závislosti na systemd. Závislost na systemd přidají do své aplikace vývojáři právě proto, že systemd řeší něco, co vyřešit potřebují.
Ta poptavka po systemd je tak uzasna, ze uz ted znam desitky pripadu, kdy provozovatel radsi zmenil distro nez aby pouzival systemd. A to sme furt jeste ve fazi, kdy jsou starsi verze dister bez systemd pod supportem.
A duvod je prevazne naprosto primitivni - proste mu to 10 let funguje, ma spousty custom veci, a nehodla investovat tisice hodin do predelavani neceho, jen proto, aby zjistil, ze to nefunguje prave kvuli systemd.
On totiz realne zadnej admin neni zvedavej na nejake paralelni start sluzeb (to je zlo doslova pekelny), stejne tak neni zvedavej na neco, co mu samo pod rukama bude veci startovat nebo dokonce restartovat ... Jelikoz serverovy selezo 15min+ dela jen post, tak start systemu minutu nebo dve ... nikoho nedojme. Zato kdyz zjisti, ze ma na disku TB binarni blob logu, kvuli kterymu mu doslo misto ...
A nejhorší na tom je, že úplně zbytečný.
Podle vás autoři třeba Gnome jen tak z rozmaru přepisují stávající kód, aby byl závislý na systemd? Nebude to spíš tak, že jim systemd poskytuje nějaké služby, které by jinak museli pracně implementovat, nebo na ně rezignovat – zatímco takhle jednoduše využijí systemd, a sami se mohou věnovat něčemu jinému?
Závislost na Linuxu je problém, ale asi to není problém, který by měli řešit primárně uživatelé systemd na Linuxu. A ta závislost není by-design – když bude *BSD implementovat služby, které systemd potřebuje, jistě nikdo nebude bránit portaci systemd na *BSD.
V principu jenom nastavit nějaké parametry systému (locale, hostname apod.), spustit a monitorovat služby apod.
To, co odlišuje systemd od správců služeb založených na SysVInitu a skriptech je mimo jiné schopnost průběžně reagovat na různé události. Takže nestačí jen služby spustit a monitorovat, ale také jim poskytnout prostředí, ve kterém mezi sebou mohou nějak komunikovat.
Opakuju: mnoho let existuje OpenRC, launchd, SMF, supervisord ... těch alternativ je spoustu. Není to "hnusné initskripty" nebo systemd.
Jenže ty alternativy nebyly dostatečné, pořád se snažily tvářit, že je to vlastně SysVinit + skripty (a třeba takové OpenRC pořád je SysVInit + skripty). Autoři systemd se rozhodli zahodit zpětnou kompatibilitu a udělat to znovu a tak, jak odpovídá roku 2016. Nikomu nic nebránilo udělat to před systemd, mohlo se dnes úplně stejně nadávat třeba na launchd.
ještě jsem neslyšel o ničem, co by řešil a nedalo se to udělat jinak
Systemd není žádný zázračný software s nadpozemskými schopnostmi. Vše, co dělá systemd, se samozřejmě dá udělat i jinak. Akorát to zatím nikdo jinak takhle komplexně neudělal. Samozřejmě je spousta projektů, které řeší část věcí z toho, co řeší projekt systemd. Ale zatím z nich nikdo tu alternativu systemd neposkládal.
To je stejně validní argument jako "nic nenutí lidi používat Windows". Pěkně silné "nic"...
To teda není stejně validní argument. K používání Windows nutí lidi to, že je všichni znají, je vydáván software nebo ovladače jen pro Windows. Když vám partner poskytuje data v proprietárním datovém formátu nějakého programu, který je jen pro Windows, můžete s ním buď přestat komunikovat, nebo používat Windows.
Systemd je něco úplně jiného. To, že nějaký jiný program používá systemd, vás jako programátora přece vůbec nenutí použít systemd ve svém programu. Když váš program nějak fungoval před příchodem systemd, bude úplně stejně fungovat i na systému, kde systemd běží, i když váš program bude systemd dál ignorovat. Takže autory programů opravdu vůbec nic nenutí vytvářet závislost na systemd. Když ale tu závislost dobrovolně vytvoří, musí pro ně systemd představovat nějakou výhodu. Zvlášť když každý programátor přidává nerad závislosti na cizích projektech a každý je v pokušení, že by si to napsal sám a určitě líp. A přesto programátoři tu závislost na systemd přidají.
Tvůrci distribucí jsou na tom o něco hůř. Pokud mají nějaký program, jehož autor přidal závislost na systemd, mohou tu část funkcionality odstranit, mohou začít používat systemd, nebo mohou to, co poskytuje systemd, poskytnout danému programu jinými prostředky.
Jenže odpůrci systemd na něj akorát nadávají, ale že by napsali něco lepšího, to ne. Přitom je to podle nich tak snadné. A autoři po tom rádi skočí, když sáhli o po tom „hrozném“ systemd. Takže jediné, co brání vytvoření lepší alternativy systemd, je to, že když se chtějí odpůrci systemd přepnout do programátorského editoru a začít kódovat, vždy jim to nějak ujede a najednou píšou nenávistný komentář do diskuse. A určitě za to může systemd.
> Závislost na Linuxu je problém, ale asi to není problém, který by měli řešit primárně uživatelé systemd na Linuxu. A ta závislost není by-design – když bude *BSD implementovat služby, které systemd potřebuje, jistě nikdo nebude bránit portaci systemd na *BSD.
Hm.
Závislost na Windows je problém, ale asi to není problém, který by měli řešit primárně uživatelé Windows. A ta závislost není by-design – když bude Linux implementovat služby, které Windows aplikace potřebují, jistě nikdo nebude bránit portaci aplikací na Linux.
Jinak zbytek už komentovat nebudu, jenom bych opakoval tohle: http://judecnelson.blogspot.cz/2014/09/systemd-biggest-fallacies.html
Ano, přesně takhle to při portaci Windows aplikací na Linux bylo. To opravdu neřešili uživatelé Windows, ale ti, kdo aplikaci chtěli používat na Linuxu. Museli nahradit to, co bylo specifické pro Windows, něčím, co poskytoval Linux, nebo danou část aplikace oželet, a nebo danou službu implementovat pro Linux.
Podle vás autoři třeba Gnome jen tak z rozmaru přepisují stávající kód, aby byl závislý na systemd?
Viz. Není nad to si pořádně naběhnout na vidle, co, Jirsák?
Jj. A z toho vlákna hlavně tohle (včetně těch citací shora):
https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00447.html
Kde se tam píše o tom, že tu závislost přidávají jen tak z rozmaru? Navíc pokud by byla přidána jen tak pro nic za nic, nebyl by žádný problém ji pro BSD zase odpárat. Jenže ona se ta závislost nepřidává jen tak z rozmaru, ale proto, že poskytuje nějaké služby, které Gnome skutečně využije. Takže to nejde jen tak odpárat. ale je potřeba ty služby něčím nahradit. Jenže to by tu náhradu někdo musel naprogramovat. A do toho se nikomu nechce, je snazší místo toho fňukat v diskusi, že když mi tyhle služby nemáme, neměl by je mít ani Linux, protože jinak je to od něj nekolegiální.
> Navíc pokud by byla přidána jen tak pro nic za nic, nebyl by žádný problém ji pro BSD zase odpárat.
Jistě. Protože lidi nemají nic jiného napráci než synchronizovat nekompatibilní codebase takového molochu jako je Gnome. Super nápad! :)
> A do toho se nikomu nechce, je snazší místo toho fňukat v diskusi, že když mi tyhle služby nemáme, neměl by je mít ani Linux, protože jinak je to od něj nekolegiální.
Jenže takhle to není. Věci jdou dělat se zřetelem na portabilitu a bez zřetelu na portabilitu. Někoho to prostě zajímá, někoho to nezajímá.
Podívejte se třeba na nosh - init systém, který z těch podstatných věcí dělá asi všechno co systemd. A s portabilitou nemá problém. Poettering jde ale záměrně cestou "všichni kdo nejste mainstream, polibte mi prdel."
No vidíte. Takže nad nosh triviálně uděláte API kompatibilní se systemd, a máte vystaráno.
Protože lidi nemají nic jiného napráci než synchronizovat nekompatibilní codebase takového molochu jako je Gnome
Takže podle vás mají raději plýtvat časem na tom, že budou znovu implementovat to, co už je implementováno v systemd?
"že budou znovu implementovat to, co už je implementováno v systemd?"
- a je?
Teda povim ti, ta tvá demagogie je vysloveně učebnicová.
systemd není hotové, řeší problémy, které mělo sysv, a má problémy, které sysv nemělo. Takže proč bychom jako měli kejvnout na tvůj dojem, že to, že je v systemd už něco implementováno má nějakou váhu?
Nejde o můj dojem. Jde o dojem všech těch vývojářů, kteří do svých aplikací závislost na systemd přidávají. Zatím nikdo zde v diskusi nepřišel s lepším vysvětlením, než je to pro ty vývojáře výhodné.
"Nejde o můj dojem. Jde o dojem všech těch vývojářů, kteří do svých aplikací závislost na systemd přidávají. Zatím nikdo zde v diskusi nepřišel s lepším vysvětlením, než je to pro ty vývojáře výhodné"
Tak já to zkusím.
Přece pokud děláte softwarové balíčky pro velké distribuce jako je třeba Debian a přejdou na systemd tak musí Vaše balíčky taky, nebo si uberete možnost šířit software pro uživatele. A je pak jedno, co se Vám jako vývojáři líbí, nebo ne. Stejně s Firefoxem třeba, změní API a pokud to neukončíte, tak máte jen jednu možnost, ale těžko se dá jen tak prohlásit, že se Vám nové API líbí a proto na něj přecházíte.
Disclaimer: nemám statistiku co si o systemd myslí vývojáři, třeba je to půlce i jedno ...
Ne, můj software se v takovém případě nemusí stát závislým na systemd. Nanejvýš můžu přidat unit file, to je ale pouze přidání jednoho textového souboru do distribuce, žádná závislost tím nevzniká. A i kdybych ten unit file nepřidal, správce distribučního balíčku si ho snadno vyrobí sám, takže kdybych chtěl systemd jako autor toho software úplně ignorovat, klidně to můžu udělat, a můj software stejně v Debianu zůstane.
Takže tímhle způsobem závislost aplikace na systemd určitě nevzniká. Ale oceňuji, že jste se to alespoň pokusil nějak vysvětlit.
Asi ne, protože Gnome prý závisí na službách systemd. O tom se tady celou dobu bavíme, jestli existuje nějaké lepší vysvětlení, proč autoři do kódu Gnome přidali závislost na systemd, než to, že jim to přináší nějaké výhody.
Vytvoření unit souboru závislost na systemd nevytváří. To, že systemd používá nějaký jiný projekt, také závislost nevytváří, a není to důvod, proč přidávat tu závislost do svého projektu.
"O tom se tady celou dobu bavíme, jestli existuje nějaké lepší vysvětlení, proč autoři do kódu Gnome přidali závislost na systemd, než to, že jim to přináší nějaké výhody"
No vždyť ho říkám. Protože chtěli být na systemd distrech<,/strong> což už ale jsou všechny velké distra, takže taková main line ( A nepodporovat systemd znamená asi jako na mobilech nepodporovat android). Ale aby jsme se netočili v kruhu a rozlouskli jsme to hned:
Bylo to rozhodnutí podporovat pouze systemd z toho důvodu, že je systemd tak dobrý a nic jiného nemá smysl a nebo po přechodu na systemd by vývoj pro další init systémy znamenalo v podstatě udržovat paralelní forky .... a tak se na to vysr.... ?
Myslíte, že když nechápete, co znamená v software „závislost“, že to lépe pochopíte, když budete psát tučně?
Protože chtěli být na systemd distrech
Systemd distribuce je předpokládám distribuce, která jako init systém používá ve výchozím nastavení systemd. V takové distribuci budou samozřejmě fungovat i aplikace, které na systemd žádnou závislost nemají. Třeba bash, vim, Firefox a tisíce dalších programů na systemd žádnou závislost nemají, přesto v „systemd distribucích“ fungují.
A nepodporovat systemd znamená asi jako na mobilech nepodporovat android
Ne, neznamená. Aplikace, která nepodporuje systemd, bude na systému se systemd fungovat úplně stejně, jako na systému, kde systemd není.
Ale aby jsme se netočili v kruhu a rozlouskli jsme to hned
Nejdřív musíte pochopit, že „podporovat systemd“ a „záviset na systemd“ jsou dvě různé věci, a to, že kdyžje v distribuci systemd, v žádném případě to neznamená, že v té distribuci může být jen software, který je na systemd závislý. Klidně v ní může být dál software, který o systemd vůbec nic netuší.
Ostatně ono stačí pochopit obecný význam slova „závislost“ – když budete mít v kuchyňce kafe („kafe kuchyňka“), neznamená to, že od té chvíle budou moci v kuchyňce vařit jenom ti, kteří jsou na kafi závislí. Klidně tam mohou být i lidé, kteří kafe vůbec nepijí.
Bylo to rozhodnutí podporovat pouze systemd z toho důvodu, že je systemd tak dobrý a nic jiného nemá smysl
Ne, z pohledu vývojáře je přidána závislost na systemd proto, že systemd poskytuje nějaké funkce, které může vývojář využít, a nemusí je sám programovat. To ale neznamená, že bude podporovat pouze systemd – když ty funkce nabídne někdo jiný, umožní použít i tu alternativu. Něco jiného samozřejmě smysl má, akorát to jaksi nikdo nenapsal, protože ti, kteří by k tomu teoreticky měli motivaci, mají plné ruce práce s hejtováním systemd.
nebo po přechodu na systemd by vývoj pro další init systémy znamenalo v podstatě udržovat paralelní forky
Dříve používané init systémy neposkytovaly aplikacím žádné služby. Takže aplikaci, která počítá se starými init systémy, je úplně jedno, jaký init sytém se použije, nijak ne tom nezávisí a její kód se nijak nemění. Prostě se vedle té aplikace připraví něco, co ji umí spustit – pro SysVinit shell skript, pro systemd unit file. Takže aplikace, která nechce být na systemd závislá, si může klidně dál nezměněná existovat, nepotřebuje žádné forky, prostě jenom její správce v systemd distribuci pro ni připraví unit file.
Pardon, chtel jsem zvýraznit jednu větu a nevšiml jsem si překlepu "<,/strong>". Pak pardon no. Přečíst to ale snad jde.
Prosím Vás, nemusíte psát takové dlouhé texty, jen opakujete obecné věci, ale když jsme chytli konkrétní, tak ta kompatibilita kterou proklamujete stejně jaksi neplatí.
Takže když vezmu staré Gnome tak ho spustím na distru se systemd?
Alias proč tedy vývojáři nenapsali ten unit file a tím pádem nemají podporu i u ostatních dister, které systemd nepoužívají ale rozhodli se jít do systemd? Co je teda taková výhoda, že se rozhodli být nekompatibilní s ne-systemd systémy?
Prosím Vás, nemusíte psát takové dlouhé texty, jen opakujete obecné věci
Neopakuju. Význam slova „závislost“ jsem vám vysvětloval poprvé, předtím jsem si myslel, že to slovo znáte.
ldyž jsme chytli konkrétní, tak ta kompatibilita kterou proklamujete stejně jaksi neplatí
Ale platí.
Takže když vezmu staré Gnome tak ho spustím na distru se systemd?
Myslíte Gnome, které nebylo na systemd závislé? Samozřejmě, že ho v distribuci se systemd spustíte. Stejně jako tam spustíte kterýkoli jiný program, který o systemd nic neví. Jak by asi systemd mohl spuštění toho programu zabránit?
Alias proč tedy vývojáři nenapsali ten unit file
Protože vývojáři nechtěli jen ulehčit práci těm, kteří konfigurují správce služeb. Vývojáři chtěli použít služby, které programy z rodiny systemd nabízí. Tím vzniká ta závislost.
Co je teda taková výhoda, že se rozhodli být nekompatibilní s ne-systemd systémy?
Už jsem psal, že nevím, co konkrétně to bylo u Gnome. A také jsem psal, že neznám lepší vysvětlení, než že nějaké výhody existují. A zatím nikdo s lepším vysvětlením nepřišel.
"Neopakuju. Význam slova „závislost“ jsem vám vysvětloval poprvé, předtím jsem si myslel, že to slovo znáte."
No já si samozřejmě prošel vlákno než jsem něco napsal. Ale ok, mě jste to ještě nenapsal ;-)
Dobře no, takže závěr je takový, že přesto že máte jasno, tak nevíte co k tomu vývojáře vede ale víte, že to co jsem psal to není. Nevadí, třeba se to jednou dozvíme, co se dělo, až zase někdo naštvaný kolem nějaké distribuce začne nadávat a někdo se mu ozve.
Díky
Jak už jsem psal, to vysvětlení je nejlepší mně známé, nikdo tady zatím lepší nenapsal. To vaše vysvětlení je ve zjevném rozporu s realitou.
Aha, takže tvoje vysvětlení je, že to vlastně vůbec nevíš (což ti ale - jak je u tebe zvykem - nebrání na to téma napsat desítky "zasvěcených" komentářů). No tak to se nedivím, že takovému vysvětlení se nikdo nepokouší konkurovat, to tvoje je totiž bezkonkurenčně nejlepší. :-DDD
Řekl bych, že systemd žádná hrůza není, naopak řeší spoustu dlouholetých problémů. Asi jde hlavně o to, že linux se systemd už skutečně není UNIX. Není jím, protože tak v podstatě zní zadání: odpoutat se od *nixových konvencí a tradice a vyvíjet novou, postunixovou platformu. Dle mého názoru je to cíl velice žádoucí a vítaný, ale je pochopitelné, že ten, kdo chce v Linuxu vidět implementaci *nixu a jako takový ho používat, ten bude o systemd neustále zakopávat.
K tomu slavnému "dělat jednu věc a dělat ji dobře": ono to zní hezky, ale v praxi jsou věci často jinak. Takovéhle principy dávají smysl, když programujete shellové příkazy, ale přece jenom máme rok 2016 a většina lidí si neinstaluje linux proto, aby v něm mohla dělat ls a mkdir. V moderním systému je důležitá INTEGRACE... a proto máme systemd.
Jasně, jako potřeba zásahu tu 100%pro byla, ovšem je otázka kolik a za jakou cenu. Proto jsem se právě ptal, protože v tom mám trošku guláš i kvůli tomu, že se objevují fakt protichůdné tvrzení a protože v tom nedělám, tak na to nemám tolik času abych si udělal opravdu fundovaný názor sám ....
:"tak na to nemám tolik času abych si udělal opravdu fundovaný názor sám ...."
....a skončil u nekonečného krmení trollů, od kterých jsme se místo fundovaného názoru dozvěděli, že "Windows se prostě rozšířili a staly monopolem, protože nebyly s ničím kompatibilní..."
S tím časem to zdá se nebude zase až tak zlé:-)))
Čti pozorněji, jak sám ostatním doporučuješ, a dozvíš se!
Bez pardonu pro extra trolly extra znovu: pokud autor výroku :"Windows se prostě rozšířily a staly se monopolem, protože nebyly s ničím kompatibilní..." není na drogách, tak nutně potřebuje do stínu, napít, najíst a dát si neodkladně od práce delší pauzu, dost možná po poskytnutí výše uvedeného vyhledat lékařskou pomoc.
PC´s jsem prodával a upgradoval opravdu všelijak (ne)nadaným uživatelkám, které se ptaly na opravdu zarážející věci, ale takovouhle debilitu nedokázala zplodit ani ta nejméně nadaná z nich.
Vyser se na třídenní trollení pomocí argumentů, které neprojdou ani u osmáka ze ZŠ, odlož všechny podružné úkoly okolo železa a zkontroluj základní životní funkce a pitný režim, tvým nejzákladnějším biochemickým procesům akutně hrozí panic kernel.
To by fakt úplně a opravdu stačilo, ani ses na to nemusel logovat a pouštět se do unikátního rozboru s ještě raritnějším závěrem, kterak redmondská firmička světem operačních systémů zamotala. Naneštěstí jsi rozhodl opačně.
Mimochodem "moc textu..." napsal vážně člověk, co tu tři dny blije po těžkém úpalu kvalitu typu "Windows se rozšířily až do monopolu kvůli nekompatibilitě..."???
Vážně? To je ten tvůj stav ještě mnohem horší, než jsem si myslel.
A kdybys dělal to, co doporučuješ ostatním, tj. pozorněji četl, pro začátek třeba po sobě to, co sám píšeš, mohl sis ty tři dny blitek a průjmu nesmyslů v kvalitě, kterou nezplodí ani dvacetiletá personalistka u spořiče, ušetřit. Natož to vydávat za postesknutí.
A to nemluvě o doporučení ostatních, kteří ti už 3 dny naznačují, že namísto těchto perel rootu, které by měly i s autorem viset v perexu minimálně na rok, ten čas u open source nikdo nikomu (čili ani tobě) nebrání využít k napsaní něčeho lepšího, než je systemd.
Ale chápu, po tak těžkém úpalu mezi průjmy a blitím se programuje těžko.
Zatím jsi nám v horečkách vyzradil, kterak geniálně Bill všechny ostatní pochcal od hlavy až k patě zákeřnou nekompatibilitou.
Jestli se tvůj stav nelepší a na tomto výblitku stále trváš (což je velmi varovné pro tvoji prognózu), pokračuj ve stejném duchu i další dny, co se dá dělat, kódování je opravdu pro ty, kdo jsou fyzicky v jakés takés biochemické normě.
Chci upozornit na vasi falesnou argumentaci. Davate do opozice business pozadavky "dělat jednu věc a dělat ji dobře" s "INTEGRACE" v kontextu spousteni a behu operacniho systemu.
Pominu-li siroky pojem terminu integrace, vami pouzita opozice nema zadnou souvislost.
Prvni je pozadavek na jednoduchost a potazmo kvalitu komponent.
Druhy je pozadavek na potrebu takove komponenty vhodne kombinovat (pri pouzivani/spousteni OS).
SystemD je odpoved/implementace na nevuli nebo neschopnost autoru navrhu takoveho integracniho reseni naplnit pozadavek prvni. Spravne namisto aby rekli, neumime to, nevime, reknou business requirement je spatny a proto na to kasleme a slepime si to po svem.
Máte to obráceně. Princip "dělám jednu věc..." není žádný business requirement. To je implementační doktrína která, jako všechny doktríny, má svůj velký smysl pro úzce vymezený typ zadání (a opravdu jenom pro úzce vymezený typ zadání). Systemd je snaha řešit skutečný business requirement a tím je automatizace správy služeb, vylepšení "plug and play" a usnadnění provozu uživatelských aplikací tam, kde se konfigurace systému dynamicky mění za běhu, např. na tabletu, na serveru v případě živé migrace apod.
Z toho vyplývá, že systemd - možná narozdíl od starého sysvinit - není komponenta systému, nýbrž framework. Samozřejmě, že každá jeho subkomponenta může dělat jednu věc atd... a také tomu tak do značné míry je, ale když s požadavek rozeberete, zjistíte, že aby to fungovalo, je k tomu potřeba podpora system-wide asynchronních událostí, včetně možnosti, aby takové události odchytávaly nebo i generovaly uživatelské aplikace. Je k tomu potřeba, aby si jednotlivé komponenty i aplikace mohly předávat zprávy formou strukturovaných dat. Je potřeba API, aby bylo možné takový systém a služby konfigurovat programově. Atd, atd. No a pochopitelně aby to celé mělo smysl, je nutné staré komponenty nahradit takovými, který tento framework podporují, a tím pádem je v obraze udev, dhcp, ntp, mount, logind. Proto říkám, systemd není zásahem do UNIXu, je to poslání UNIXu do důchodu a jeho nahrazení jinou platformou.
Nemusíte Lennarta a vývojáře systemd zrovna milovat, ale neschopní hlupáci to opravdu nejsou. Trvat na tom, že se takový systém musí implementovat buď čistě "unixově", tj. výhradně pomocí nekooperujících a nekoherentních programů jednosměrně si předávájích čirý text skrz roury, a nebo vůbec, protože v roce 1969 to tak u Bell Laps kdosi sbastlil a od té doby se už tím pádem nic jiného používat nesmí, to není žádný business requirement, ale holá pitomost.
Řekl bych, že systemd žádná hrůza není, naopak řeší spoustu dlouholetých problémů.
Řeší spíš neexistující problémy. S Linuxem dělám už skoro dekádu a se zaváděním systému, konfigurací sítě a spouštěním démonů (po novu služeb) žádné významné problémy nebyly, ani se "službami" které závisely na jiných jako samba nebo nfs. Stovky produkčních serverů, spousta desktopů a problémy s funkcionalitou byly úplně jinde - chybějící podpora hardware, nedostatečná podpora výměnných formátů, chybějící aplikace pro určitý okruh problémů, regrese po upgradu vč. kernelu, rychlost začleňování záplat.
Některé distribuce jako Debian nebo RH/Fedora nezvládly udržet jednoduchost a koncepčnost init skriptů, ale to není problém SysV nebo BSD initů ale konkrétních případů (ne)schopnosti a špatné organizace. V Gentoo, Slackware nebo Archu se to v žádné spaghetti skripty nezvrhlo. O OpenBSD nebo FreeBSD ani nemluvě.
Právěže řeší i některé problémy (například se správou služeb a jejich procesů), na které si mnozí linuxáci holt nějak zvykli. Viníkem jsou podle mě ti, kteří ty problémy dlouhodobě přehlíželi a zanedbávali a tím dávali prostor k takovým akcím jako je systemd. Dneska máme takový výsledek, jaký máme.
Gentoo má docela hezky dělané initskripty, ale taky to není až takový zázrak. Třeba ty psí kusy s integrací NetworkManageru s OpenRC, to je vyloženě prasárna. Kecy o jednoduchosti a bezproblémovosti SysV initskriptů mě docela baví. Neříkám, že je systemd ideální řešení, spíš je to výsledek ignorování nedostatků stávajících systémů.
> spíš je to výsledek ignorování nedostatků stávajících systémů.
Asi jde docela i o to, jakých přesně problémů jakých systémů. Existuje launchd, existuje SMF. Nejsem si úplně jistý, jestli bylo potřeba vynalézat kolo. A pokud bylo potřeba, pak nejspíš kvůli problémům, které trápí především desktop. Serverům to afaik nic moc nepřinese a spousta věcí se začne rozbíjet - z pohledu serveru úplně zbytečně. A tohle je podle mě motivace lidí za Devuanem.
SMF? Jestli tím myslíte ten krám ze solarisu, tak to bych zrovna jako vzor neuváděl. Podle mého je to dokonalý příklad Enterprise humusu, u kterého není až tak jasné, co doopravdy přináší kromě toho, že se jim konečně podařilo do toho nějak narvat XML.
O launchd si něco přečtěte a zjistíte, že si je se systemd velmi podobný - přesněji řečeno, systemd se silně podobá launchd, který je starší. Rozdíly jsou hlavně v implementaci. V launchd procesy komunikují přes Mach porty, v systemd přes dbus. Kromě toho má systemd některé linuxové fičury navíc, jako je využití cgroups (což je velmi užitečné). Pokud vás ale uklidní, že systemd je až na pár drobností kopie launchd pro linux, tak mu tak klidně říkejte a žijte blaze :)
> není až tak jasné, co doopravdy přináší
??? Přináší v principu totéž jako systemd. XML není šťastná volba, ale taky není nijak nutné - viz např. https://github.com/mheily/jobd - reimplementace launchd, místo XML používá JSON. Stejně tak by tam mohl být třeba YAML, no problem.
> O launchd si něco přečtěte a zjistíte, že si je se systemd velmi podobný
No a co jsem asi napsal? Launchd je systemd velmi podobný, čili nebylo potřeba vymýšlet další nekompatibilní kolo, mohl se vzít launchd, poupravit, vylepšit a bylo by. Mohl vzniknout portabilní init systém, který by nezpůsobil takové vlny a nevytvářel z Linuxu nekompatibilního solitéra.
"Post-unixový" Linux je možná pro někoho příjemná myšlenka, nicméně https://plus.google.com/+MiroslavPrymek/posts/VYf2W8WXrj4
> mohl se vzít launchd, poupravit, vylepšit a bylo by.
Ne, nebylo by. Launchd má licenci Apache, ne GPL, což u tak klíčové součásti linuxového prostředí je dost zásadní problém. Možná se mýlím, ale pokud vím, ač je licence Apache dost permisivní, není to BSD a přelicencovat pro potřeby linuxu celý launchd pod GPL by nešlo - nehledě na to, že i kdyby to teoreticky šlo, neumím si představit ten řev. Některým lidem se prostě nikdy nezavděčíte.
> nevytvářel z Linuxu nekompatibilního solitéra.
To je dost diskutabilní. Nekompatibilní s čím? A z jakého pohledu? OSX je dodnes jediný systém s launchd, je to teda taky nekompatibilní solitér? Asi je, ale komu to vadí? Anebo dneska, kdy v podstatě všechny velká distra používají systemd, je takovým solitérem... Devuan, který je nekompatibilní s mainstreamem právě proto, že systemd nemá? Anebo FreeBSD, které nemá systemd ani launchd, ale svůj vlastní BSD init, který taky není kompatibilní se sysv, jak ho dříve používal linux?
Chci tím říct, že to je z mého pohledu čistě subjektivní argument a že v podstatě vůči jakémukoli software na světě se dá vznést námitka, že je špatný, protože vytváří nekompatibilitu s těmi, co ho nepoužívají.
> "Post-unixový" Linux je možná pro někoho příjemná myšlenka, nicméně https://plus.google.com/+MiroslavPrymek/posts/VYf2W8WXrj4
Přiznám se, že nevím, co tím chtěl básník říci. Každý má své důvody, já jsem kupříkladu už před neuvěřitelnými 23 lety neutekl od Windows proto, že to není unix, ale proto, že to je monopolistický proprietární systém a že záviset na něm znamená vydat se na milost a nemilost jisté notoricky hostilní a podraznické firmě. Linux byl, je a vždycky bude open source, ať už se systemd nebo bez něj, takže to mě tolik nepálí. Jestli ale systemd usnadní vývoj aplikací, užívání a nasazování linuxu pro uživatele, kterým jde možnost číst bezpečně maily, sledovat videa, prohlížet si fotky a psát články, a ani ne tak si hrát na pravoslavné unixové sysadminy, tak to bude záslužný počin.
To, že by správce služeb byl pod Apache licencí, by v linuxu neznamenalo vůbec žádný problém.
Proč to tedy s launchd neuděláte? Vemte, poupravte, přidejte API kompatibilní se systemd, a máte vystaráno. Nebo vemte, poupravte, udělejte lepší než systemd a systemd převálcujte.
a proto mi gentoo jelo lepe se systemd :)
To ti neberu, i kdyz by me zajimalo z ceho vyvozujes ze "lepe".
ano .. Arch je davno systemd only
Arch presel na systemd, ale to neni v rozporu s tim ze jeho BSD-like init skripty byly prehledne a jednoduche a nepredstavovaly zadnou prekazku nebo omezeni funkcionality.
Slackware .. :) dane Patrickem a znacne omezenym setem balicku
A pointa ? Na slackbuilds.org je dalsich cca 6.000 balicku, cast z nich instaluje svoje init skripty a zadne problemy tim nezvnikaji. Sluzby se implicitne nespousti, skripty jsou navzajem ortogonalni, ve vyjimecnych pripadech je nutne specifike nastaveni systemu, ktere je popsano v instalacnim readme.
Myslím že tím chtěl říct, že v roce 2006 nebyl linuxový desktop tak vyspělý a vybavený, aby ho opravdu využívali lidi, kteří do konzole fakt nelezou, jako třeba moje přítelkyně, nebo třeba měli jsme dobrého Java vývojáře, který prostě znal v lin. konzoli jenom příkazy pro Javu, kvůli kompatibilitě s námi jako ostatními vývojáři v jednom kanclu měl Ubuntu ale jinak doma vše Win. Prostě do konzole nelezl a jednou za měsíc když bylo fakt něco potřeba, tak mu do toho na 5 min. někdo přes konzoli hrábl, servery nedělal. A takových lidí je podle mne spousta a ti nepoužívají mkdir a ls. Ale možná jsem tu jeho poznámku špatně pochopil. Znám prostě hodně lidí, co mají lin fakt jako jenom desktop a o konzoli nic neví a nepotřebují to, nebo potřebují tak často, jako běžný uživatel na Win.
Tak pro Vás to asi takový význam nemá. Pro mě asi taky ne, jsem v konzoli každý den ale jsem i na "desktopu" a on právě reagoval na to moje "dělám jednu věc a dělám ji dobře".
No já jen že asi vím jak to myslel, ale osobně si nemyslím, že ten princip musí být v rozporu, pokud jde o plynulou funkci celku. Slovo "integrace" nemám rád, protože často je zaměněno za výrobu jednoho velkého blobu. Spíš by byla potřeba určitá standardizace požadavků a očekávaných výstupů aby se dalo jednoduše dosáhnout plynulé funkčnosti. LSB, kolik toho řeším přiznám nevím, ale co jsem se zatím dočetl, tak se ne tak úplně dodržuje. Ale nejsem aktivní vývojář, jsem jen aktivní uživatel ....
Já je používám taky, ale chci tím říct, že v dnešní době většina uživatelů instaluje linux proto, že v něm náhodou funguje aplikace, kterou potřebují. Klasický *NIX nikdy nebyl "platformou" v pravém slova smyslu, původně nikdo ani nepočítal s tím, že by měl podporovat hotové aplikace třetích stran, a Linux je dnes pod tlakem se takovou plnohodnotnou platformou stát. Osobně Lennarta neznám, ani nemám akcie u Red Hat, a už vůbec netvrdím, že systemd je nejlepší možné řešení tohoto požadavku. Realita ale je, že dosud je to jediné řešení. Všechny alternativy, které jeho odpůrci prosazují (sysv, openrc atd...) jsou vedle, protože zásadně vycházejí z předpokladu zachovat stávající unixové status quo a na požadavky, kterým se systemd snaží vyjít vstříc, neodpovídají vůbec.
Požadavek 1: mít API, aby šlo systém, služby, uživatelská sezení atd. ovládat a monitorovat programově. Pokud vím, minimálně na Linuxu má API jenom systemd.
Požadavek 2: integrace mezi různými typy událostí. Příklad: chci si nastavit (jako běžný uživatel, ne root), aby ve chvíli, kdy si připojím svůj záložní USB disk, se mi automaticky zálohoval adresář s dokumenty každou hodinu. Jak toho dosáhnu v klasickém unixu? V podstatě nijak. Jako běžný uživatel nemůžu ani instaloval službu, ani zachytit událost připojení konkrétního USB zařízení. Ale i kdybych mohl, bylo by to málo platné, protože neexistuje způsob, aby program nebo událost nastartovala nebo zastavila daný cronový úkol. Nemluvně teda o tom, že v zásadě neexistuje ani spolehlivý způsob, jak z pozice běžného uživatele zjistit, zdali je připojen jeden konkrétní USB disk. V systemd tohle jde, v sysvinit absolutně ne, v openrc se přiznám, že nevím, ale nejspíš taky ne.
Požadavek 3: Možnost JEDNODUŠE omezit CPU a pamět pro danou službu. V systemd to jde díky podpoře cgroups.
Stačí, nebo jich chcete patnáct dalších? ;-)
1) /etc/init.d/apache2 start/stop/restart ... ti nestaci? Systemd zadny API nema, protoze je to asi tak stejny, jako kdyby si chtel zapisovat sektory primo na disk - na kazdym to bude jinak.
2) aha, ty zvanis a vubec netusis ... pokud ti root nastavil, ze k USB muzes, tak samozrejme muzes ...
3) systemd a cgroups nemaji nic spolecnyho ...
1) Nestaci. Navic to nefunguje.
3) systemd cgroups pouziva a diky tehle kombinaci je dost nastavovani omezeni celkem trivialni
Zapomnel jsi byt jeste sprosty ;)
Jenom jestli to neni nejaky falesny "j", ktery v tom jeste neumi chodit.
> Nestaci. Navic to nefunguje.
To, že spousta linuxových distribucí má prasácké init skripty, není argument pro nutnost systemd. Ve FreeBSD je většina funkcionality výborně vyřešená a daná do společných souborů. Takže typický init skript služby pak už připomíná spíš jenom tu deklaraci podobně jako ji má systemd - viz např. https://www.freebsd.org/doc/en/articles/rc-scripting/rcng-daemon.html - takhle málo stačí pro implementaci init scriptu, i s podporou dependencies.
Kromě toho samozřejmě existuje několik (!) init systémů, které fungují stejně jako systemd, ale nemají jeho nevýhody (např. ten zmíněný nosh).
> systemd cgroups pouziva
Na tom není nic špatného. Špatné je, pokud je nutně potřebuje a navíc ještě třeba probublají do API a následně do aplikací, které se tím stanou nejenom závislé na jednom init systému (úlet samo o sobě), ale i na jediném OS.
"To, že spousta linuxových distribucí má prasácké init skripty, není argument pro nutnost systemd."
Nevim, zda by init mel byt ve krehky ve smyslu ze nutne potrebuje bezchybne init scripty.
"Kromě toho samozřejmě existuje několik (!) init systémů, které fungují stejně jako systemd, ale nemají jeho nevýhody (např. ten zmíněný nosh)."
Ja netvrdim, ze systemd je jedine reseni (prestoze mne vyhovuje). Jenom to, ze sysv uz vazne ne. Ale samozrejme mas pravdu - tech reseni je vic.
"Špatné je, pokud je nutně potřebuje a navíc ještě třeba probublají do API a následně do aplikací, které se tím stanou nejenom závislé na jednom init systému (úlet samo o sobě), ale i na jediném OS."
Uprimne - nevim. Nikdy mne nenapadlo moc resit, ze Mail.app funguje jenom na Mac OS X, ale zase chapu, ze kdyz nekdo pouzival xBSD, tak asi bude rozcarovany, ze pro nej nekteri lide prestali delat soft.
> Nevim, zda by init mel byt ve krehky ve smyslu ze nutne potrebuje bezchybne init scripty.
Tomu nerozumím. Chyba v init skriptech způsobuje úplně stejné problémy jako chyba ve zdrojácích jakéhokoli init systému. Jaký je rozdíl?
> Nikdy mne nenapadlo moc resit, ze Mail.app funguje jenom na Mac OS X, ale zase chapu, ze kdyz nekdo pouzival xBSD, tak asi bude rozcarovany, ze pro nej nekteri lide prestali delat soft.
To je úplně jiný případ. Mail.app je proprietární aplikace a závisí na veliké proprietární knihovně.
Jde spíš o ten princip, proč ta aplikace nejde spustit jinde - jestliže je to jenom kvůli závislosti na pár funkcích init systému, které se daly udělat jinak, je to prostě škoda. Můžu jenom doufat, že většina vývojářů to za chybu bude považovat a takovou zbytečnou závislost s velkým dopadem si do softu nezavlečou - i když na to, jak říká Filip, mají právo, o tom není sporu.
Chyba v init skriptech způsobuje úplně stejné problémy jako chyba ve zdrojácích jakéhokoli init systému. Jaký je rozdíl?
Rozdíl je v tom, že administrátor neupravuje zdrojáky init systému, ale pouze jeho konfiguraci.
jestliže je to jenom kvůli závislosti na pár funkcích init systému, které se daly udělat jinak, je to prostě škoda
Co vám brání udělat to jinak?
> Rozdíl je v tom, že administrátor neupravuje zdrojáky init systému, ale pouze jeho konfiguraci.
A proč by měl admin upravovat init skripty? Když chci třeba spustit na FreeBSD nginx, tak dám do /etc/init.rc jeden řádek
nginx_enable="YES"
a pokud chci upravit nějaké parametry, tak třeba něco ve stylu
nginx_chroot="YES"
- je to principiálně úplně stejně deklarativní popis jako unitfile.
> Co vám brání udělat to jinak?
Proč bych to měl dělat jinak, když už jiná řešení existují? Už jste se podíval na to nosh?
1. Skripty nejsou API, to se na mě neráčej zlobit. Systemd API má, viz https://www.freedesktop.org/wiki/Software/systemd/dbus/. A pokud jsem si všiml, tak API pro zápis na disk náhodou máme.
2. Evidentně jsi to nepochopil. Že můžu na USB je irelevantní. Jak to udělám, abych věděl o tom, že právě byla připojena moje záložní flashka (a ne jiná)? A pokud na tohle řešení máš, jak to udělám, aby v tu chvíli začala jistá operace pravidelně probíhat každou hodinu? Doufám, že mi nechceš vážně navrhnout nějak fušovat crontab pomocí sed a awk...
3. Tak se informuj. Systemd funguje jako správce cgroups (ekvivalent cgmanager ve starších distrech) takže s ním nejen velmi úzce souvisí, ale taky takovou operaci triviálně umožňuje.
> Skripty nejsou API, to se na mě neráčej zlobit.
Api není problém vytvořit pro jakýkoliv init systém, pokud by to bylo potřeba. Viz např. API supervisord.
> Jak to udělám, abych věděl o tom, že právě byla připojena moje záložní flashka (a ne jiná)?
Matchováním tam, kam to patří - v hotplug subsystému. Root tam může dát skript, který může udělat cokoli, včetně spuštění uživatelského skriptu.
> Tak se informuj. Systemd funguje jako správce cgroups
Pointa je v tom, že cgroups se dají použít i bez systemd. Čili argument "chceme cgroups" je irelevantní pro otázku "potřebujeme systemd?"
> Api není problém vytvořit pro jakýkoliv init systém, pokud by to bylo potřeba. Viz např. API supervisord.
Takže neustále "není problém vytvořit, šlo by kdyby" atakdále. Vytvořené není, tudíž to momentálně nejde. Tečka.
> "Root tam může dát skript, který může udělat cokoli..."
Jestli Vaše odpověď na sice záměrně zvolený, ale jinak banální a legitimní scénář pro BFU je, že to sice normálně nejde, ale za to root někam může dát skript, tak jste mě rozesmál. Navíc neřešíte otázku, jak ten skript nahodí a zruší časovanou službu, když cron nemá API a init neumožňuje provozovat uživatelské služby.
> Vytvořené není, tudíž to momentálně nejde. Tečka.
Ne. Vytvořené to je, např. Upstart má dbus api. tudíž to momentálně jde už hezkých pár let. Akorát někteří lidi o tom neví.
> Jestli Vaše odpověď na sice záměrně zvolený, ale jinak banální a legitimní scénář pro BFU je, že to sice normálně nejde, ale za to root někam může dát skript,
Jak "normálně nejde"? Jde to. Tím skriptem. Na unixech se věci řeší skripty.
> Navíc neřešíte otázku, jak ten skript nahodí a zruší časovanou službu, když cron nemá API a init neumožňuje provozovat uživatelské služby.
Samozřejmě že to jde. Opět: vhodně napsaným skriptem.
Ale jinak námitku neexistence API ke cronu beru. Pokud je to problém, bylo by fajn ho řešit tím, že se API do cronu dopíše. Ne tím, že se cron včlení do initu.
> Ne. Vytvořené to je, např. Upstart má dbus api. tudíž to momentálně jde už hezkých pár let. Akorát někteří lidi o tom neví
Ano, upstart má (omezené) API, lépe řečeno měl, protože už se nepoužívá. Mimochodem všechny (pseudo)argumenty proti systemd se svého času stejně zuřivě používaly i proti upstartu, jak si možná pamatujete. Navíc hlavní hateři systemd nikdy neprosazují upstart, a vždycky sysvinit nebo openrc.
> Jak "normálně nejde"? Jde to. Tím skriptem.
Jak sám říkáte, nejde to bez zásahu roota a dost netriviálního bastlení (a to nechci ani pomyslet na race conditions a jiné možnosti katastrofy při tom skriptovém vrtání se v crontabu)
> Na unixech se věci řeší skripty.
Což je jeden z důvodů, proč si unix zasluhuje odpočinek (minimálně pokud jde o linux).
> Pokud je to problém, bylo by fajn ho řešit tím, že se API do cronu dopíše.
Tak jestli to někdy bude, tak se rád podívám. Do té doby na to máme systemd.
> Na unixech se věci řeší skripty.
Což je jeden z důvodů, proč si unix zasluhuje odpočinek (minimálně pokud jde o linux).
Ano, nebudem to řešit skripty, to je přece fuj a zastaralé. Vyřešíme to statisíci řádku ve zkompilovaném molochovi neustále bobtnajícím o nové funkce naprosto nesouvisející s init-em, se kterým v případě problémů nikdo nenadělá vůbec nic. Hlavně že to je moderní!!!! Aneb mlamoj opět zasahuje. #facepalm
Ale tady se nebavíme o něčem, co má systém umět out of the box. Bavíme se o tom, že uživatel chce po vložení nějakého zařízení udělat nějakou custom akci. Buď tu custom akci definuju pomocí skriptu, nebo nějakého jednoho řádku v uživatelově cronu, nebo pomocí vytvoření systemd služby. Každopádně musím něco vytvořit.
> Jak sám říkáte, nejde to bez zásahu roota a dost netriviálního bastlení (a to nechci ani pomyslet na race conditions a jiné možnosti katastrofy při tom skriptovém vrtání se v crontabu)
Zásah roota je nutně potřeba, to je správně. Jak jsem už řekl: bez něj by mohl uživatel komukoli nepozorovaně zkopírovat data.
O jakém "netriviálním bastlení" je řeč? Napadá mě několik způsobů, jak to udělat:
1. pod daným uživatelem je spuštěn skript, který provede zálohu a pak danou dobu čeká
2. flashka se mountuje do přesně daného umístění. V uživatelově cronu je úloha, která očekuje, jestli je přimountovaná a zálohuje. Když ne, končí.
3. konfigurace cronu je rozělena do více souborů (např. ~/.config/cron.d), při vložení flashky se konfigurační soubor přejmenuje z "bcp.conf.disabled" na "bcp.conf"
4. totéž jako 2, ale cesta k mountpointu flashky se zapíše někam do souboru
... a bambiliony jiných možností...
Nikde nevidím žádné "netriviální bastlení", všechno jsou to věci na jeden řádek.
Asi vám uniklo to hlavní: Frantu Uživatele zajímá, jestli se mu zálohují fotky. Jestli to je nebo není unixové je mu u onoho. Se systemd to jde triviálně a hned. Vaše "lepší" řešení bez toho "strašného" systemd spočívá v tom, že Franta nejdřív provede nebo nechá provést rootový zásah do OS, nastaví nový match pro udev a pak se pustí do vývoje vlastního démona, přičemž se předpokládá, že je dostatečně zkušený programátor, aby věděl, jak démona spolehlivě zabít nebo restartovat a jak se vyhnout race conditions. Případně milion jiných možností, které sice nefungují, protože unix potřebné funkce nemá, ale teoreticky by šlo je do něj implementovat.
To jako myslíte vážně?
(Na okraj: není pravda, že je na to potřeba root. USB se běžně automaticky mountuje s uid a gid namapovanými na toho, kdo je zrovna přihlášen na konzoli. Tak to bylo už před systemd a je tomu tak i teď. Vaše přístupy ostatně v tomto ohledu absolutně nic nemění)
To je jeden řádek. Jak to udělá pomocí systemd, že to je o tolik snadnější?
To je přece úplně triviální. Třeba takhle (zřejmě zastaralé) nebo takhle s použitím timers - což je znovuvynalezený cron aneb Lennart a jeho NIH syndrom.
Všimni si, že to je tak ohromně jednoduché a intiutivní, že to vyžaduje pouze několik stránek návodu.
:-DDDDDDDDDDDD
> To je přece úplně triviální. Třeba takhle (zřejmě zastaralé) nebo takhle s použitím timers - což je znovuvynalezený cron aneb Lennart a jeho NIH syndrom.
Znovuvynalezený cron, který na rozdíl od starého cronu jde ovládat skrz API, takže ho můžou používat aplikace, může záviset na jiných službách nebo událostech, služby nebo události můžou naopak záviset na něm atd. Taková drzost, co si to ten Lennart dovoluje!
A jak to zjednodušilo to zálohování na flashku, že... jak říkám, stačí nabiflovat několikastránkový návod a je to. (A až to Lennart zase rozmrdá, tak možná někdo po pártýdenním laborování napíše návod nový.) Kdepak, s takovou hnusnou zastaralou věcí jako je crontab nebo /etc/cron.d běžte k šípku, to není vůbec moderní. :-DDD
Ne problem je presne opacny. Chci pouzit funkcionalitu, ktera funguje 10 a vice let a najednou to nefunguje. Pokud shutdown script sluzby nebezi pod rootem, systemd to ignoruje a vesele utrhne disky pod bezici databazi. Soubor limits.conf uz neslouzi pro sluzby(uzivatele), ale POUZE pro sessions prihlasene pres logind. Limity pro demony se musi nastavovat jeste jinde. (celkove 2x). Pokud se uzivatel odhlasi ze serveru, systemd smaze vsechny shared-memory segmenty, bez ohledu jestli je nekdo pouziva anebo ne. Klauzule "name" v udev pravidlech uz nejde pouzit pro disky ale pouze pro sitove adaptery. Kazda verze rozbije neco jinyho a neda se na to dopredu pripravit.
PS: to ze uzivatel ma dvoji limity, jednou pro GUI session a jednou pro SERVICE jsem resil naposledy pred 15ti lety na Win 2000. Dost jsem se tehdy divil co to v tom Microsoftu kouri.
Ten cron jste se také musel naučit používat, v tom rozdíl není. Rozdíl je možná jenom v tom, že cron už umíte, ale nic nového se učit nechcete. A jinak zrovna cron také není vzorem intuitivnosti. Sice všechny crony používají zdánlivě stejný formát, ale ve skutečnosti se navzájem liší. A těch dotazů ve fórech „nefunguje mi cron“… Někde je potřeba odřádkování za poslední řádkou souboru, někdy dotyčný netrefí formát souboru, někdy má problémy s proměnnými prostředí, někdy neví, jak zacházet s výstupem…
Ten cron jste se také musel naučit používat, v tom rozdíl není.
Ano, správné vytvoření jedné řádky v crontabu je nepochybně co do potřebného času ke studiu, learning curve atd. zcela ekvivalentní nalinkované magii se systemd unity a službami, která k témuž vyžaduje několikastránkový návod. A jako bonus ten je to celé tak stabilní, že se to s jakoukoliv novou verzí Lennartova výplodu může kdykoliv rozbít.
Nemusíte ho používat. Ale když se zamyslíte, jak by takový lepší cron měl vypadat, zjistíte, že není žádný důvod, proč by se služba „pokud dojde k události X, udělej Y“ měla chovat jinak, pokud událostí „X“ je uplynutí nějakého časového okamžiku, než když tou událostí je změna souboru, připojení média, spuštění služby… No a že když už máte univerzální systém, který dokáže reagovat na události, stačí do tohohle systému zapojit budík, který bude umět poslat událost v požadovaném čase. A že tak snadno získáte systém, který toho umí daleko víc, a jen tak mimochodem implementuje i celou funkcionalitu původního cronu. Navíc to „udělej Y“ je univerzální a může úplně stejně reagovat na různé události – takže může spouštět zálohu třeba každý den, a navíc pokaždé hned, jak připojíte zálohovací médium.
Ale nic vám nebrání používat ten původní cron, když chcete. Stejně jako vám nic nebrání napsat cron, který bude mít akorát lepší API.
Ad a): Kdo a jak vás k tomu nutí?
As b): Tak ten lepší cron napište. Nevím, proč by ho pro vás měl psát někdo jiný, kdo má o lepším cronu jinou představu, než vy.
Ad a) – Ne.
Ad b) – Neodbíhám, to jenom vy nevíte, co chcete. Chcete starý cron? Můžete ho mít. Chcete nový cron s API? Můžete ho mít, napište ho. Chcete správce služeb řízený událostmi (který tím pádem může plnit i to samé, co dělal cron)? Můžete ho mít. Výběr je jenom na vás. Když si vyberete starý cron, může vám být úplně jedno, že systemd dokáže plnit tutéž funkci.
" Neodbíhám, to jenom vy nevíte, co chcete. Chcete starý cron? Můžete ho mít. Chcete nový cron s API? Můžete ho mít, napište ho."
Víte, tohle ale trošku boří možnost mít vlastní názor - taky by se klidně dalo říct - chcete systemd? Tak ho mějte ale necpěte ho všem, když znemožňuje kompatibilitu. A nevytáčejte se. Na Gnome je to dobře vidět, kam to vede. Plný přechod na systemd znemožnil jeho použití s ne-systemd distry.
Beru, že jsou balíčky, kde jde podpora "bypassnout" ale jak dlouho to vydržíí? Dokud nedodají plnou podporu?
A proto to zajímalo i mě, protože velkých distirbucí == široká podpora a tuny balíčků už bez systemd moc není ,,, Proto jsem i nahoře se ptal, co je lepší, protože "systemd na věčné časy a nikdy jinak" se mi moc nezamlouvá a jedna z věcí, která se mi na LInuxu líbila když jsem začínal byla ta možnost výběru. To padlo.
A postupem času v té nekompatibilitě a rozlezenosti systemd spíš vidím záměr než to, že by věci, které byly nedotažené nebo chtěli zlepšení, nešly udělat tak, aby nebyly konečné a absolutní.
Nikoli, nikdo vám nebrání mít vlastní názor – ale nemůžete po nikom chtít, aby se tím vaším názorem řídil. Systemd nikdo všem necpe – někdo ho napsal podle svých představ, a nabídl ho ostatním. Je teď na nich, aby se rozhodli, zda ho chtějí nebo nechtějí používat. Když vy máte jiný názor, napište svůj program a nabídněte ho ostatním – a opět bude na nich, zda ho budou používat či nebudou. To naopak vy chcete, aby se ostatní podřídili vašemu názoru, a když se vám systemd nelíbí, chtěl byste, aby vůbec nevzniklo nebo ho zakázat. To je totiž jediný způsob, jak zabránit tomu, aby ho lidé nezačali dobrovolně používat.
Přechod na systemd neznemožnil použití Gnome na zařízeních, kde se systemd nepoužívá. Odkazoval jsem třeba na návod na zprovoznění Gnome bez systemd na Gentoo.
To, že chcete používat Gnome bez systemd, je váš požadavek, takže se vy musíte postarat o jeho splnění. Není ničí povinností to pro vás zařizovat. Pohybujeme se ve světě opensource, takže je velmi pravděpodobné, že pokud bude o Gnome bez systemd zájem, vaše úpravy se integrují na hlavní větve Gnome.
„Systemd na věčné časy a nikdy jinak“ je pouze váš výmysl. Možnost výběru je tu pořád, nic nepadlo. Akorát pořád nechápete, že ty alternativy k systemd vám nezařídí autoři systemd, ale musí to udělat ti, kterým systemd vadí.
Jak může být záměr v nějaké nekompatibilitě nebo rozlezlosti ve světe opensource? Co vám brání napsat systém, který bude dotahovat a zlepšovat všechno, co dotahuje a zlepšuje systemd, a zároveň bude kompatibilní a nerozlezlý?
Bavíme se tu pořád dokola o tom, že někdo napsal systemd a dal ho k dispozici ostatním s tím, že pokud ho chtějí používat, tady je a používat ho můžete. A pár lidem se to nelíbí, a pořád dokola si stěžují, jak si může někdo dovolit napsat software, který neodpovídá jejich požadavkům, a dát ho k dispozici ostatním. Tak už se s tím smiřte, že žijete ve svobodném světě, každý si může napsat software jaký chce a může ho zveřejnit. Vy to můžete udělat také. V tom, abyste napsal software, který bude daleko lepší než systemd a převálcuje ho, vám nebrání vůbec nic z vašeho okolí – problém je čistě v tom, že to neumíte nebo nechcete. Stěžovat si na to klidně můžete, ale nečekejte, že lidé, kterým vyhovuje systemd, bude psát váš anti-systemd.
To ale není jenom "neodpovídá jejich požadavkům" a není to tak jenom "pár lidem".
Pokud vím, tak třeba v Debianu se o tom dost pohádali a bylo to těsně 50 na 50 a spousta lidí kvůli tomu odešlo. Ale čerpám jenom z toho, co jsem se dočetl.
A toto bude asi taky jenom nějaký "trouba"
Linus Torvalds said:
"I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility . and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues."
Je to neodpovídá požadavkům – bugs and compatibility jsou jenom požadavky. Na počtu lidí nezáleží – když píšete opensource software, nikdo vás nemůže nutit, abyste bral v úvahu, kolik lidí to bude používat. Já si můžu klidně napsat a zveřejnit program, který bude vyhovovat jenom mně a všichni ostatní budou tvrdit, jak je to špatný program – a přesto mi nikdo nedokáže zabránit v jeho zveřejnění. Navíc pokud je těch odpůrců systemd takové množství a systemd je špatné, tak už přece dávno někdo z nich musel napsat něco lepšího, než systemd, na co všichni uživatelé systemd rádi přešli.
Ano, ale když Vy si<ústrong> napíšete svůj program, který si můžu nebo nemůžu nainstalovat, je to něco jiného, než když někdo napíše program, pak se kvůli tomu poperou maintaneři distribucí a zadrátují to do systému. Jasné, tak jak je to svobodné rozhodnutí, asi, tak úplně stejně se mě to nemusí líbit.
To bych Vám taky mohl říct, že když se Vám nelíbí spojenci a jejich války o ropu a vliv, bez mandátu OSN, kde umírají civilisti - ženy , děti, starci, tak nežijte v Evropě. Nikdo Vás nenutí. Podporujete vražděné civilistů? Asi ne že?
Jo , je to extrém, ale princip je stejný, jen jsem vyměnil "spojenci jejich války o ropu a vliv, bez mandátu OSN, kde umírají civilisti - ženy , děti, starci" za "systemd" a "nežijte v Evropě" za "si ho neinstalujte" ...
Ano, je to něco jiného – rozdíl je v tom, zda se kvůli tomu poperou správci distribucí. Což je věc těch správců distribucí a já jako autor toho programu to řešit nemusím (ostatně oni se mohou klidně poprat z důvodu, který ani).
Ten princip není stejný. Autoři Debianu dělají distribuci pro sebe, a rozhodli se, že ji zpřístupní i ostatním. Vy jste se dobrovolně rozhodl, že tohle, co vám někdo zadarmo nabízí, budete využívat. Teď se autoři Debianu rozhodli k něčemu, co se vám nelíbí. Tím, že je to opensource, vy dokonce můžete tu distribuci jednoduše vzít, a udělat fork, který bude vyhovovat vašim potřebám – jako to udělali autoři Devuanu. Ale vy byste místo toho chtěl, aby se autoři Debianu vykašlali na to, jak to chtějí mít oni, a místo toho to udělali podle toho, jak chcete vy. Proč by to měli dělat?
"Ale vy byste místo toho chtěl, aby se autoři Debianu vykašlali na to, jak to chtějí mít oni, a místo toho to udělali podle toho, jak chcete vy. Proč by to měli dělat?"
Samozřejmě, že si o tom rozhodnou autoři Debianu, ale co jsem měl možnost se dozvědět, tak to moc jednomyslné nebylo. takže zas tak křišťálově čisté "chtěli to tak mít" to není.
Podívejte, mám několik serverů se staším Debianem, umím se v něm pohybovat a nyní potřebuji vytvořit malou síť serverů a nemůžu na produkci hodit něco, co je zadrátované v systému, mění se to, občas se po aktualizaci něco rozbije (zdroj zde diskuze). Nemůžu zvolit Devuan, protože nemám jistotou, že některý balík co tam budu mít nepřejde na plnou podporu systemd jako třeba to Gnome a já budu muset na produkčních serverech buď dělat obezličky (pokud to pujde) aby program fungoval, nebo jsem v háji a nemůžu použít Devuan ani proto, protože nevím ani jak jim ta snaha vydrží a jak na tom budou s bezp. aktualizacema atd .... Jo, ještě můžu přeinstalovat produkční server, paráda. Tak si asi vyberu Gentoo, ale tam to zase neznám, nemám zkušenost s flow, s dostupnostmi atd .... No a jelikož nedělám administraci serverů jako hlavní činnost, o to je to pro mě horší a bolestnější a bude mě to stát více času a platit si kvůli tomu profi admina je jako s kladivem na komára.
Takže to je takový můj výhled na účinek systemd v prostředí a panu Poetringovi, jehož Alsu sice taky používat nemusím ale udělal jsem tu chybu a dost jsem se s ní natrápil, můžu fakt poděkovat. Já vím, nemusím používat nic, ale tak proto to dělají? Aby to lidi mohli klidně nepoužívat?
Nezáleží na tom, jak se k tomu rozhodnutí dospělo, to výsledné rozhodnutí představuje to, co dnes Debian „chce“. Kdyby se rozhodli, že chtějí podporovat varianty se systemd i s ním, také by to znamenalo, že to Debian „chce“.
zdroj zde diskuze
Pokud se o tom, co nasadíte na server, rozhodujete podle zdejší diskuse, je to váš problém. Pokud zdejším diskutérům důvěřujete víc, než správcům Debianu, nenasazujte na servery Debian, ale distribuci zdejších diskutérů.
Takže to je takový můj výhled na účinek systemd v prostředí a panu Poetringovi […] můžu fakt poděkovat.
Za to, že se řídíte „radami“ zdejších diskutérů, opravdu pan Poetring nemůže.
Já vím, nemusím používat nic, ale tak proto to dělají? Aby to lidi mohli klidně nepoužívat?
Ne, dělají to proto, aby to lidé mohli používat – a dospěli k rozhodnutí, že se systemd to bude pro lidi použitelnější. Pokud vy si myslíte, že by to bylo použitelnější bez systemd, je na vás, abyste to prokázal. Ostatně autoři Devuanu jdou právě touhle cestou.
Nějak pořád nechápu, proč by autoři Debianu, kteří si myslí, že to bude lepší se systemd, měli prokazovat platnost vašeho názoru, že to bude lepší bez systemd.
"zdroj zde diskuze"
Ale zde lidi linkovali zajímavé zdroje a ty beru v potaz. A názor je ale taky důležitý - pokud to teda není "Ty jsi vůl a nic nevíš" - jak se tu občas objevuje. Ale nebuďte smutný, stejně vážně beru i Váš názor, protože jste schopný ho normálně napsat, akorát s ním nesouhlasím. I Vy jste tam dával linky a asi ne jen tak z bůhdarma aby "jsem se jako hlavně neřídil podle diskuze" ale jako relevantní zdroj. Diskuze, ty vážné, ne jako na živě.cz, jsou zajímavým zdrojem informací. Proto jsem kdysi zde na root začal chodit, protože v diskuzi pod článkem se člověk vždycky ještě i něco dozvěděl - minimálně nějaký názor nebo pohled na věc. Dokonce jsem zde vedl 3 denní rozpor o programovacím jazyku a nakonec jsem se dozvěděl zajímavé věci a dokonce pár konkrétních případů a zase vím o něco víc a líp .... Já sem nechodím machrovat nebo se vyřádit ....
"Za to, že se řídíte „radami“ zdejších diskutérů, opravdu pan Poetring nemůže".
Viz výše + "může" ale za to, že se mi po restartu objeví místo zvuk. karty graf. karta a když pak vytáhnu jack od repráčků, tak bez reinstalace Alsy a restartu už zvuk ani nezapnu + Podle googlu zdaleka nejsem sám. To si pak i se všemi těmi bugreporty a nepochvalami na systemd mám myslet že je to ok? Jako nevím, proč to nemohli první pořádně vychytat a ne to honem hrnout do produkce aby to už už měli rozdělené. Pardon, ale takový dojem to na mě dělá
"Nějak pořád nechápu, proč by autoři Debianu, kteří si myslí, že to bude lepší se systemd, měli prokazovat platnost vašeho názoru, že to bude lepší bez systemd."
Nemusí, já to po nich přece nechci. Naopak, platnost svého názoru prokazuji já, sám za sebe. Jestli mě, ale nejen mě. dá vývoj za pravdu, to se uvidí. Samozřejmě že nemám patent na pravdu, ale mám právo na svůj názor. A dokonce, už po několikáté píši že uznávám jejich volbu, akorát se mi nelíbí. Ale přístup, když se ti něco nelíbí, tak "si naser", neboli slušně řečeno "používej si něco jiného nebo si to napiš sám" neberu jako správný, protože to nepodporuje volnou výměnu názorů. Doby pravdy jen té správné strany už tu byly a za moc to nestálo ... A celá ta situace není o jednom sporném programu, ale o tom, jak moc je komplexní a jak až moc tím zasahuje nejen do částí systémů, ale taky tak trochu nabourává kompatibilitu balíčků a na tom, co jsem Vám psal s mými servery je to vidět, před jako volby to lidi postavilo. To není jenom o tom, jestli si naistaluju nebo nenainstaluju nějaký balíček nebo ne.
Z těch bugreportů a nepochval se ale nedozvíte, jestli je to jinde lepší nebo horší. Čekat s vydání softwaru „než se to pořádně vychytá“ je samozřejmě možné, ale při vývoji softwaru se obecně inklinuje spíš k častějšímu vydávání. Protože jinak hrozí, že si budete někde pod pokličkou psát svůj dokonalý kód, a až ho ukážete světu, ukáže se, že to takhle vlastně nikdo nechce. Navíc většina problémů „se systemd“ je způsobena tím, jak „netradičně“ se to v reálném světě používá – což nezjistíte, dokud se ten software nezačne reálně používat.
Ale přístup, když se ti něco nelíbí, tak "si naser", neboli slušně řečeno "používej si něco jiného nebo si to napiš sám" neberu jako správný, protože to nepodporuje volnou výměnu názorů.
To asi ale špatně vykládáte, co to znamená volná výměna názorů. Ta se týká skutečně jen těch názorů, ne toho, že se jimi někdo musí řídit. To, že je systemd špatný, je váš názor, a nikdo vám to nebere. Ale pokud se tím názorem chcete řídit, je to na vás – volná výměna názorů neznamená, že někoho jiného, kdo s tím názorem nesouhlasí, donutíte, aby se jím řídil.
To, že je ten balíček komplexní, je právě ta podstata sporu. Někdo si myslel, že ta původní halda různých částí, které spolu navzájem komunikují špatně a každá jinak, je špatně, a je potřeba místo toho přijít s něčím, co bude komunikovat jednotně a spolehlivě. Proto se to nedá řešit postupnými výměnami jednotlivých balíčků – protože primární problém není v těch balíčcích, ale ve vzájemných vazbách. Řešit to postupně tak, že by ty jednotlivé části uměly komunikovat postaru i ponovu, by bylo na dlouho, přičemž ten nový kód by se dlouho nevyužíval, a navíc by se s sebou pořád táhla ta zátěž chyb staré komunikace. Kdyby se s tím začalo před deseti lety, asi by to bylo přijatelné, ale dnes už není čas čekat na to, že možná za deset let budeme mít rozumný způsob správy a komunikace služeb.
Ano, někdo na to může mít jiný názor, ale pak je na něm, aby to implementoval. Jako to udělali autoři Devuanu. Třeba se časem ukáže, že měli pravdu oni, a Debian zanikne a bude pokračovat jenom Devuan, nebo se spolu zase sloučí a Debian z Devuanu převezme jako svou hlavní větev tu non-systemd.
> To, že je ten balíček komplexní, je právě ta podstata sporu. [...] a je potřeba místo toho přijít s něčím, co bude komunikovat jednotně a spolehlivě. Proto se to nedá řešit postupnými výměnami jednotlivých balíčků
Tak v tom teda vubec podstata sporu neni. Neni nic spatneho na tom, udelat novy init+svc management+cron+atd, pekne to promyslet, provazat, udelat k tomu API. Spor je o tom, jestli zrovna ta implementace systemd je dobre promyslena, jestli bude v provozu dostatecne robustni, jestli toho nahodou vic nepokazi nez spravi.
Bud to nechapete nebo nechcete chapat, ale neustale tady cupujete strawmana. Kdybyste min mluvil a vic poslouchal, tak byste si to mozna uvedomil.
Víte, je software a software. Systemd zasahuje do moc věcí a tak zásadně, že to mohlo fakt asi počkat. Mimochodem ty early relase jsou proto, aby se mohlo budovat se zájmem a zpětnou vazbou od uživatelů, ne proto, že si budu vychytávat problémy až za běhu, nehledě na to, že to není nějaký prográmek a součást systému.
Můžu Vás ujistit, že čím větší systém složený z částí, které nejsou schopny fungovat samostatně (nemyslím jen systemd ale distro jako celek) - modulárně - tím dřív se nakonec sesype, protože taková struktura musí mít nějaký hlavní regulátor a ten nakonec jednou nebude schopen uřídit všechno.
Pod pojmem systém se můžete představit cokoliv, co je nějaký celek a nějak reaguje na vnější vstupy.
Dobrým příkladem budiž EU. To je tak velký celek,který postupně méně a méně umožňuje samostatné a nezávislé fungování vnitřních součástí, že musí vydávat regulace na už vydané regulace aby mohl zavést nové regulace a bobtná a bobtná, ale to nejde udržet do nekonečna.
Ale uvidíme. Možná se dočkáme dalšího historického větvení vývoje linux distribucí.
Čekalo to patnáct let. Kdyby autoři systemd čekali dalších patnáct let, přišel by mezi tím někdo jiný, kdo by udělal klidně ještě větší zásah do systému.
Testovací verze systemd samozřejmě existovaly, jenže když to testuje pár uživatelů, neodhalí se tím všechny možné kombinace prostředí. Mimochodem, to, že po světě existují miliony různých hacků správy služeb, které je problém naroubovat na systemd, je jenom dalším důkazem toho, že ten dřívější systém je špatný.
Můžu Vás ujistit, že čím větší systém složený z částí, které nejsou schopny fungovat samostatně (nemyslím jen systemd ale distro jako celek) - modulárně - tím dřív se nakonec sesype, protože taková struktura musí mít nějaký hlavní regulátor a ten nakonec jednou nebude schopen uřídit všechno.
A tohle je právě věc, kterou systemd řeší. Před systemd máte soustavu různých skriptů, udev pravidel, cronů a bůhvíčeho ještě, co je na sebe různě navázané a závislé. Systemd právě přináší tu modularizaci, protože ty komponenty si mezi sebou povídají stejným protokolem, takže můžete jednu komponentu snadno vzít a nahradit ji jinou komponentou, můžete snadno spouštěč události změnit z času na modifikaci souboru, start služby, přihlášení uživatele nebo cokoli jiného.
"Čekalo to patnáct let. Kdyby autoři systemd čekali dalších patnáct let, přišel by mezi tím někdo jiný, kdo by udělal klidně ještě větší zásah do systému."
No super, takže důvod bychom měli. Ještě že tohle nefunguje třeba v letectví.
"Testovací verze systemd samozřejmě existovaly, jenže když to testuje pár uživatelů, "
Tak to jsou na tom teda dost blbě. No to jste mě teda uklidnil, že si udělají z uživatelů a ostrých nasazení test plant.
"systemd právě přináší tu modularizaci, protože ty komponenty si mezi sebou povídají stejným protokolem, takže můžete jednu komponentu snadno vzít a nahradit ji jinou komponentou"
Jinou komponentou, ale systemd komponentou. Oni se evidentně vy..li na interface a vše, na co narazí zahrnou do systemd. A to je právě ten problém. Kam ta jejich modularita vede se hezky probublalo až ke Gnome že, a taky jsem narazil na to, že Xfce ja na tom stejně. To je přímo ukázka nezávislosti.
Jinými slovy, místo aby změnili/spravili článek mezi jádrem a desktopem, vedle cronu atd, tak vytvořili moloch, který nároky spojil všechno dohromady tak, že je systemd závislé i grafické prostředí a ještě ani neměli před nasazením možnost to otestovat. No to je teda modularita. Ale takovou metodu vývoje znám, jeto metoda ŽáVeS - "Žádní velké sraní ..."
To si totiž pod pojmem modularita představujeme každý asi něco jiného. Já si pod pojmem modularita ne-představuji něco, co má nějaké části a někdo jim dá do jména "Modul" ale hromadu nezávislých komponent, který tvoří fungující a automaticky reagující celek.
Víte třeba jak se dělají změny na produkční databázi když ji prostě nemůžete jenom přehrát? Mám na mysli postup, že když chcete např. v tabulce Users zrušit sloupec "whole-name" a nahradit ho sloupci "first-name" a "surname", tak přece hned v aktualizaci nezlikvidujete sloupec a nenahradíte ho těmi dvěma, ale pouze vytvoříte ty dva nové, přehrajete do nich data a začnete tam přidávat i nové, běží to paralelně a pak, až Vám to hezky běhá s novými sloupci a nikdo nezaznamenává problémy, tak třeba v další aktualizaci odstraníte sloupec "whole-name" + kód k tomu a máte jistotu, že to všechno běží a nikomu nic nerozbíjíte. Ano, je to těžší postup ale nikomu z razu nic neodstřihnete
No super, takže důvod bychom měli. Ještě že tohle nefunguje třeba v letectví.
Taky doufám, že v letectví netrvá 15 let, než se začne řešit známý problém.
No to jste mě teda uklidnil, že si udělají z uživatelů a ostrých nasazení test plant.
Tak jako všichni ostatní, kteří píšou software, který se používá v milionech různých prostředí. Všechna ta různá prostředí totiž nejde nasimulovat.
Jinou komponentou, ale systemd komponentou.
Ne.
Oni se evidentně vy..li na interface a vše, na co narazí zahrnou do systemd.
Ne. Pouze píšou ty komponenty, které mohou z nového systému těžit a nenapíše je nikdo jiný.
Kam ta jejich modularita vede se hezky probublalo až ke Gnome že, a taky jsem narazil na to, že Xfce ja na tom stejně. To je přímo ukázka nezávislosti.
To, že nikdo jiný nenapsal implementaci logind, není chyba lidí od systemd. Pokud někdo che jinou implementaci, ať ji napíše. Nepsal už jsem to několikrát?
Jinými slovy, místo aby změnili/spravili článek mezi jádrem a desktopem, vedle cronu atd, tak vytvořili moloch, který nároky spojil všechno dohromady tak, že je systemd závislé i grafické prostředí
Ty nároky jsou mnohem menší, než byly u těch původních implementací. Vám pořád vadí, že nikdo nenapsal alternativní implementaci – ovšem vy patříte mezi ty, kteří ji nenapsali. Takže si stěžujete pouze na sebe.
ani neměli před nasazením možnost to otestovat
Mezi software, který takhle funguje, můžete zahrnout třeba také linuxové jádro.
No to je teda modularita.
Modularita znamená, že můžete komponenty přidávat a ubírat, aniž by o tom musely vědět ostatní komponenty. To, že třeba modul poskytující služby cronu nemůžete momentálně nahradit jiným modulem, protože neexistuje žádný jiný modul poskytující takové služby, není chyba modulárního systému. Je to chyba toho, kdo ten jiný modul potřebuje a nenapsal ho. To je jako kdybyste tvrdil, že linuxové jádro není modulární, protože když odstraníte modul ext4, nemáte žádný jiný modul, který by obsluhoval souborový systém ext4.
hromadu nezávislých komponent, který tvoří fungující a automaticky reagující celek.
Přesně takhle systemd funguje.
Mám na mysli postup, že když chcete např. v tabulce Users zrušit sloupec "whole-name" a nahradit ho sloupci "first-name" a "surname", tak přece hned v aktualizaci nezlikvidujete sloupec a nenahradíte ho těmi dvěma, ale pouze vytvoříte ty dva nové, přehrajete do nich data a začnete tam přidávat i nové, běží to paralelně a pak, až Vám to hezky běhá s novými sloupci a nikdo nezaznamenává problémy, tak třeba v další aktualizaci odstraníte sloupec "whole-name" + kód k tomu a máte jistotu, že to všechno běží a nikomu nic nerozbíjíte. Ano, je to těžší postup ale nikomu z razu nic neodstřihnete
Jenže pokud nemáte kontrolu nad všemi aplikacemi, které s tou databází pracují, zůstal byste na věky se třemi sloupci – protože některé aplikace by se prostě nepřizpůsobily, když by je k tomu nic nenutilo.
Navíc pokusy řešit ty problémy cestou mírného pokroku jsou staré minimálně patnáct let – a žádný z nich se neujal. Protože kvůli zachování zpětné kompatibility přinášely pouze malé výhody, přitom ale byly s předchozím řešením nekompatibilní. Takže se to ve výsledku moc nevyplatilo nasazovat. Takže se dál bastlily hacky na hacky, až se dospělo do bodu, kdy energie potřebná ke změně je menší, než energie nutná na udržování těch hacků.
"Taky doufám, že v letectví netrvá 15 let, než se začne řešit známý problém."
Jo, takže když už to trvalo dlouho, tak už to můžeme patlat a je to jedno. Zajímavé. Nehledě na to, že 15 let staré problémy akorát nahradili novými.
"Jinou komponentou, ale systemd komponentou.
Ne"
Ano.
"Ne. Pouze píšou ty komponenty, které mohou z nového systému těžit a nenapíše je nikdo jiný."
Tak to by mohli napsat nový celý systém a nemuseli zasírat ten stávající. Těžit mohou z nového a nikdo jiný je nenapsal. Aneb použiji li Vaši oblíbenou paušalizaci - Nikdo je nenutil opravovat init, mohli si vytvořit vlastí systemd distro.
"hromadu nezávislých komponent, který tvoří fungující a automaticky reagující celek.
Přesně takhle systemd funguje."
Nefunguje - protože ostatní moduly / celky pracující s ním musí změnit interface a zatratí tím interface k ostatním - Gnome, Xfce, cron zrovna přepsali .... Správně modulární by to bylo, kdyby se nic co je kolem systemd nemuselo měnit, jen systemd by sis tím co mu přijde přes interface nakládal po svém. ...
"Jenže pokud nemáte kontrolu nad všemi aplikacemi, které s tou databází pracují, zůstal byste na věky se třemi sloupci – protože některé aplikace by se prostě nepřizpůsobily, když by je k tomu nic nenutilo."
No to právě nechápete, protože záleží na Vás, na databázi, co poskytnete na interface. Pro ty staré poskytnete [pseudokod] concat( first_name, surname) pro ty nové můžete je poskytovat setejně + ještě odděleně a označit první způsob jako @deprecated --- ach,jak je tento postup neobvyklý, že? Takto se dodržuje modularita a ne že to změním a když se ti to nelíbí, tak si nainstaluj co chceš. Udělat to má právo, ale pak o něm mají lidi právo říct že je .... Zpětná kompatibilita je taky sprosté slovo že?
"Navíc pokusy řešit ty problémy cestou mírného pokroku jsou staré minimálně patnáct let – a žádný z nich se neujal. "
A to má jako znamenat, že někdo přijde a celé to rozbourá? Mimochodem kdyby nebyl systemd tak problémový tak by byl klid.
"Protože kvůli zachování zpětné kompatibility přinášely pouze malé výhody, přitom ale byly s předchozím řešením nekompatibilní. Takže se to ve výsledku moc nevyplatilo nasazovat. Takže se dál bastlily hacky na hacky, až se dospělo do bodu, kdy energie potřebná ke změně je menší, než energie nutná na udržování těch hacků."
No, malé pokroky jsou možná lepší, než vyměnit staré errory za nové.
Kdyby nebyl systemd tak problémový, měli bychom tu pořád ten starý systém postavený na nekompatibilních programech, které jsou různými hacky provázané tak, aby to připomínalo to, co bylo původně požadováno. Ty problémy jsou totiž převážně způsobeny tím, když se někdo ty hacky hacků pokouší naroubovat na systemd. Je to podobné jako s přechodem na IPv6, který je pro spoustu lidí také problémový, protože nevědí, jak v síti použít IPv6 adresy z privátního rozsahu a celou síť „schovat“ za NATem.
"Kdyby nebyl systemd tak problémový, měli bychom tu pořád ten starý systém postavený na nekompatibilních programech, které jsou různými hacky provázané tak, aby to připomínalo to, co bylo původně požadováno. Ty problémy jsou totiž převážně způsobeny tím, když se někdo ty hacky hacků pokouší naroubovat na systemd."
Takže je podle Vás v pořádku, že když si nainstaluji čistou Debian + systemd + Gnome a vyměním systemd tak už Gnome nespustím? No ještě že k tomu ostatní maintaineři balíčků přistupují svědomitě. Bylo fakt na prd vyměnit třeba nano za vim a už neotevřít žádný file, nebo nainstalovat htop a už nepustit ps. Ale jak to vypadá, možná i to bude nový standard. Ale co, jsem v klidu, protože si to přece můžu napsat sám, že?
"Je to podobné jako s přechodem na IPv6, který je pro spoustu lidí také problémový, protože nevědí, jak v síti použít IPv6 adresy z privátního rozsahu a celou síť „schovat“ za NATem."
Není, protože jim nikdo nesebral možnost mít ipv4, jinými slovy neplatí to, že jakmile odstraní ipv6, tak už některé věci bez hacků nepošlou po ipv4. Takž tento příklad trochu kulhá. Ale já Vám uvedu jiný.
Vemte si že systém (distro) je jako panelový dům a bytové jednotky jsou moduly.
Společný interface je schodiště, dveře do bytu a stoupačky. I okna, ale tam na ničem nic nezávisí.
No a teď se několik nájemníků rozhodne, že si opraví své zastaralé byty na novější a lepší a chtějí posunout stoupačky a dveře do bytu ( jsou ve 2. patře - 2. SW level ) a když už jsou v tom, tak je potřeba změnit schodiště (kvůli novým bytovým dveřím). Hlasuje se nějaký způsobem (na tom nezáleží) a vyhráli, tak to celé předělali. Občas se ale stane, že přes jejich nové stoupačky něco neteče občas nefungují chody a těm nad nimi (další SW vrstvy), komu se to nelíbí, řekli, ať si najde jiný podnájem nebo se přizpůsobí --- ale taky si mohou postavit schodiště a trubky vlastní a oni je možná přijmou.
O co v příkladu jde? Že nezachovali celek ___modul ( byt )__ s jeho rozhraním ale vrtali i do interfaces - zde spol. prostory ---- a proto kompatibilita s nimi znamená změny i pro ostatní byty a kdo nechce ať táhne nebo si udělá svoje, protože byt jejich tak je to jejich rozhodnutí --- samozřejmě majitel domu (zde třeba Debian) to v reálu povolit nesmí (naštěstí), ale u distra se to stalo.
To vystihuje daleko víc současnou situací
Takže je podle Vás v pořádku, že když si nainstaluji čistou Debian + systemd + Gnome a vyměním systemd tak už Gnome nespustím?
Když nějaká komponenta vyžaduje nějakou službu, a já poskytovatele té služby vyměním za něco jiného, co tu službu neposkytuje, je v pořádku a logické, že ta závislá služba přestane fungovat. Když nainstalujete X a Gnome, a pak X vyměníte za framebuffer, Gnome vám přestane fungovat – protože vyžaduje služby X, které framebuffer neposkytuje.
V pořádku není, pokud vám nějaká distribuce umožní udělat takovou „výměnu“, aniž by protestovala.
V pořádku by také nebylo, pokud byste implementaci té služby vyměnil za jinou implementaci té služby, a přestalo by to fungovat. Pak může být problém v některé z těch implementací, v nejasném rozhraní nebo v tom, že závislá aplikace závisí na specifickém chování konkrétní implementace, které není rozhraním zaručeno.
Není, protože jim nikdo nesebral možnost mít ipv4
Pokud vám ty možnosti někdo sebral, stěžujte si na něj – z toho, co píšete, předpokládám, že vám ji sebrali správci Debianu. Systemd pokud vím stále může běžet jako PID>1, ze systemd stále můžete spouštět jakékoli skripty, včetně původních init skriptů, stále můžete používat různé implementace cronu. Systemd tomu nijak nebrání, takže chybu hledejte jinde.
Ten váš příklad je úplně špatně. V původním řešení totiž neexistuje žádné jednotné rozhraní, každá komponenta s každou jinou komunikuje ad hoc rozhraním specifickým právě pro ty dvě komponenty. Správně by tedy ten příklad byl, kdyby ten původní dům žádný interface neměl. „Stoupačky“ by byly řešené tak, že by byla nějak přivedená voda do prvního patra, tam by se třeba před kohoutkem udělala odbočka, na ní nasadila hadice a tou voda vytáhla do druhého patra. Ve druhém patře by byla trvale zašpuntovaná vana, v ní ponorné čerpadlo a to by hnalo vodu do třetího patra – a kdyby ve vaně docházela voda, měli by z třetího patra dolů natažený provázek, kterým by zatáhli za pákový kohoutek ve druhém patře, aby se vana začala napouštět. Atd. atp.
Pak by přišli s tím, že je potřeba s tím něco udělat, udělat v celém baráku jednotný interface (normální stoupačky). Udělalo by se to, a nájemníci by si začali stěžovat. Ten ze třetího patra by si stěžoval, co je to za pitomý rozbitý interface, být napojený na stoupačky. On byl zvyklý na svůj interface – ponorné čerpadlo a provázkem ovládaný kohoutek o patro níž. A teď když se pokouší se na to připojit, musel si pořídit sud, do kterého napouští vodu z těch stoupaček, protože ponorné čerpadlo neumí čerpat vodu ze stoupaček. K ovládání kohoutku pro plnění sudu ze stoupaček musel přidat kladku pod strop, protože kohoutek má najednou u sebe a ne o patro níž, a když od něj vede provázek nahoru, už na něj nedosáhne. Nájemníci by tedy začali brblat, jak mají ty stoupačky špatný interface, že je potřeba, aby se to u nich v bytě napojilo na ten jejich původní – ale jinak v domě ať jsou samozřejmě ty stoupačky, protože si nájemníci od 4. patra výš rychle všimli, že ve stoupačkách je voda pořád, a ne podle toho, jak zrovna funguje čerpadlo ve 3. patře.
"Když nainstalujete X a Gnome, a pak X vyměníte za framebuffer, Gnome vám přestane fungovat"
Jenomže to tak není, protože Gnome před tím fungovalo a po výměně komponenty systemd se muselo změnit a už není kompatibilní s čím bylo
" původním řešení totiž neexistuje žádné jednotné rozhraní, každá komponenta s každou jinou komunikuje ad hoc rozhraním specifickým právě pro ty dvě komponenty."
Takže neexistují systémové proměnné a systémové funkce pro přístup ke zdrojům. Aha
