TrueOS (dříve PC-BSD) přechází od FreeBSD RC initu na OpenRC, který je udržovaný vývojáři Gentoo a najdete jej například také v Alpine Linuxu.
Místo skriptů v rc.d, OpenRC používá init.d s konfiguracemi v /etc/conf.d/. Použití OpenRC prý zkrátí čas startu TrueOS z jedné minuty na 10 sekund.
(zdroj: phoronix)
pokud je pro někoho důležitá rychlost startu, tak pak ok.
Já si poměrně hodně zvykl na freeBSD a na to, že vždy služby startují ve stejném pořadí, snáze se mi kontrolují logy ze startu - vím, v které fázi, která služba si na něco stěžuje.
Takze rychlost startu je zase to nejdulezitejsi. Kvuli tomu stoji za to i zasrat si system systemd (ktery z jakehosi zahadneho duvodu zde nezvolili), neni-liz pravda. Nicmene kdyz je funkcni suspend a hibernace, koho tolik zajima rychlost startu? Krome toho 1 minuta je porad o dost mene, nez je typicky start Widli, nasledny beh wupdate a update antiviraku. Z ceho tedy komu naskytuje vyrazka? Nerikam, ze prechod na jiny init je zlo, ale delat to kvuli par vterinam startu mi pripada trochu mimo. Rad bych slysel zavaznejsi duvody.
A jak asi mohli zvolit systemd, kdyz TrueOS nepodporuje cgroups?
A k duvodum pro zmenu initu mas jeden z odkazu zpravicky:
"With OpenRC, TrueOS boot times have been reduced from generally over 1 minute to around 10 seconds. The organization of service config files lends itself to simpler manipulation of individual services. OpenRC also provides more reliable service status by using the start-stop-daemon or the built-in supervisor. So, TrueOS now starts faster, is more/differently organized, and is more reliable."
Tovizejo nekola, binarni logy, ktery kdyz se podelaj, tak ve skutecnosti nebudes mi ZADNY logy, protoze kdyz chces mit jeste nejaky dalsi, tak je musis napojit az za ten blob. DHCP server kterej se jen tak pro tu prdel spousti tak nejak sam od sebe, driv nez ma system vubec moznost mu to zakazat to je taky parada. Odstrelovani aplikaci v odpojeny sesne ... protoze tvurce je kreten (zadnej jinej duvod to totiz nema) je taky fajn. Rozmrdani zcela funkcni veci (priprazeni nazvu sitovce napr) ... to je uz jen tresnicka ... jo jasne, jednomu z tisice to nefungovalo. Nebo treba takovy uzasny startovani sluzeb ... to je taky parada. Predevsim kdyz clovek od sluzby tak nejak ceka, ze kdyz ji spusti, tak ze i bezi, treba takovej printserver zejo. A pak "reseni" na tema kdyz to nejde palici, vemem vetsi palici, kdy se do sluzby jeste pak kopne, aby teda jako vazne nastartovala ... lol. A jeste lepsi ... kdyz ta sluzba zbuchne ... no tak ji restartujem ... co na tom, ze tim dojebem data. Pricemz o tom ze sluzba zbuchla se ovsem dovime jen v pripade, ze zbuchne slusne ... kdyz prestane odpovidat ale tvari se bezicne, tak vime lautr hovno.
Binarni logy, na ktere ve skutecnosti nemusim spolehat, a pak co? Bud politikia nebo neprectena dokumentace (kde si do dokumentace dovolim zapocitat i SystemD Myths).
Binarni logy, casto nefunkcni, jsou vyzivne, ale neni to zdaleka jediny duvod. Ten, ktery bych oznacil za hlavni, je to, ze systemd jde proti nixove filosofii. Syatemd neni kostka ve stavebnici, kterou muzu vymenit za jinou, ktera se mi libi vic. Je to prujem, ktery znecistuje cim dal silneji ostatni casti systemu nebo je dokonce pohlcuje a stava se nenahraditelnym a neodstranitenym. Cim dal vice SW ma nove vzniklou zavistlost na systemd, ktera eventuelne vznikla jen proto, aby byla obejita nejaka systemd picovina nebo proto, ze systemd neco rozbil. Za chvili bude portovani SW odjinud na Linux mnohem obtiznejsi kvuli systemd a opacnym smerem pak (skoro) nemozne. Z Linuxu tak budou dalsi Widle, kde lze provozovat SW z Linuxu a nic jineho a SW z Linuxu vubec nikde jinde nepobezi. Bodejt ne, kdyz budouci linux se bude skladat akorat z jadra, systemd a graficke nadstavny. Pricemz nahrada jadra systemd se pripravuje a bude se tomu pak rikat Poetteringux.
... http://www.openwall.com/lists/oss-security/2017/01/24/4
ten je peknej ... zjevne je to vyspelej, bezpecnej a otestovanej init ... lol. Tohle jako nekdo mysli vazne? Nasadit do provozu? Teda ja obcas delam veci ze kterych ostantim vstavaj vlasy ... ale tohle bych nezkousel ani v labu.
... Netreba psat/udrzovat ... jasne ze, ony se ty servisy, specielne ty se spoustou podminek, nastartujou samy ... tak nejak od prirody aplikace vytusi, ze databaze uz vazne bezi, takze muze nastartovat ... telepaticky pozna, ze uz bezi sit, ze uz se inicializovala krabice na seriovy lince ...
2klokan ... naprosto mimo. Muzu su vybrat z asi tak 30 log demonu, a minimalne jeden loguje XML. Ten binarni blob stejne nebude obsahovat nic jinyho nez pole datum a pole text. Jenze to XML prectu i kdyz se castecne podela, zato tu binarku muzu leda zahodit.
2) naprostej nesmysl, logovat si muzu cokoli si nastavim ze se logovat bude. Vazne nevim proc by cron mel resit sit, kdyz s ni nijak nesouvisi. Naopak zavislost to tak maximalne rozbije.
3) zadny api neexistuje, kdyby existovalo, tak davno nekdo tu hruzu prepise.
Je k dizpozici minimalne nekolik daleko lepsich initu ktery navic nic nerozbijej. Kdo ze bude rozbitej init opravovat? Vyvojar, kterej je linej napsat script, nebo admin? Par adminu znam. jeden nebo dva si na svy zelezo pustili i systemd. Ostatni nejsou zjevne dost velky magori aby to zkouseli. Zhruba dva dodavatele se snazili dodat neco, co chteli provozovat na distru se systemd. Oba dva hned v prvnich dnech testovani narazili na to, ze neco nefunguje ...
2MP: Neocekavas ze budou existovat 2 nebo dokonce vic distribuci, to je totiz zcela neresitelnej problem z hlediska vyvoje software ... jeden jim vsem kaze, ... do temnoty ...
Netreba psat/udrzovat slozite bash skripty pro spravu sluzby...Uz vidim, jak to nasi vyvojari pisou misto nekolikaradkove definice systemd service unity.
Ano, systemd je naprosto unikatni init, ktery jako jediny funguje bez dlouhych bashovych skriptu. Pockejte, vlastne ne. I jine inity misto nich maji jednoduche konfiguraky o par radcich a to i presto, ze se do nich nepromitly paprsky Poetteringova genia. Tak mi znovu unika, proc misto SysV zavadet zrovna systemd, kde se nektere veci serou, jine se meni adminum pod rukama, protoze soudruzi neco nedomysleli a dneska to proste funguje jinak a jeste to pozira okolni system jak zelena smrt.
Argumenty pro systemd byly probírány do omrzení, takže jenom krátce a v kostce:
1. Logy. Sice binární, ale v jasně definovaném formátu. Kdo někdy psal parser syslogu tohle ocení.
2. Integrace všech typů systémových událostí se závislostmi. V klasickém Unixu například cron a síť o sobě vůbec nevědí a žádná vzájemná závislost tudíž není tudíž není možná, přihlášení a odhlášení uživatele nejsou zaznamenané nijak apod.
3. Všechno má API, což je jeden z největších problémů klasického Unixu, kde ovládat a konfigurovat systém programově v podstatě nejde. Víc než cokoli jiného je tohle důvodem, proč se Unix ani Linux není schopný doopravdy dostat na desktop.
Někdo tady použil přirovnání ke stavebnici. Ano, Unix je stavebnice, ale taková, ve které má každá kostka jiný tvar, jiný rozměr, je z jiného materiálu a každá je nějak vadná, jenom každá jinak. Jistě, i z takové stavebnice se při troše dobré vůle dá něco postavit, ale to že to jde neznamená, že by člověk nemohl chtít lepší stavebnici. No a když ji dostane, tak ho nijak moc nemrzí, když ty staré kostky do ní už nezapadají.
Argumentů proti systemd je, pokud vím, primárně pět:
1. Rozbije to kompatibilitu s FreeBSD/NetBSD apod... Budiž. V tom je snad jakás logika, ale v zásadě je to stejné, jako odmítat TCP/IP, protože není kompatibilní s UUCP.
2. Binární logy. Viz výše: jsou v každém případě mnohem lepší. Textové by třeba byly ještě lepší, to je možné, ale rozhodně je to dle mého názoru krok kupředu. Operační systém má být navržen primárně pro potřeby vývojářů, ne sysadminů.
3. Návrh systemd není optimální. Nikdo netvrdí, že je dokonalý. Žádný lepší ale prostě k mání není a nikdo žádný takový ani nevyvíjí, takže v praxi je to buď systemd, nebo status quo. Většina zjevně volí tedy systemd.
4. Do teďka jsme se bez systemd obešli. Aneb k čemu mikroprocesor, zbytečně integruje moc funkcí a sálové elektronkové počítače se bez něj do teďka taky obešly.
5. Není to Unix. Na tohle je dle mého názoru přiměřená odpověď: "no a co má být?"
1. Logy. Sice binární, ale v jasně definovaném formátu. Kdo někdy psal parser syslogu tohle ocení.
Hm, tak zrovna ty binani logy a jejich parsovani tu jednou nekdo rozpatlavat a jestli se pamatuju, tak s tim parsovanim je to jeste horsi, nez u textovych logu. A to dokonce i v pripade, kdy se clceku podari se k tem binanim logum dostat, protoze zrovna nespadly.
Operační systém má být navržen primárně pro potřeby vývojářů, ne sysadminů.
Vazne? Ja si vzdyzky myslel, ze pocitace jsou navrhovany pro uzivatele. S vasim pristupem bychom dnes meli treba vysavace takove, ze by lidi radsi klepali koberce na klepadle na dvore.
Vyvojar vyviji pro uzivatele a tim je v pripade spravy systemu admin, ne vyvojar.
Vazne? Ja si vzdyzky myslel, ze pocitace jsou navrhovany pro uzivatele.
Pro uživatele jsou navrhovány aplikace. Operační systémy jsou (respektive měly by být) navrhovány pro vývojáře aplikací. Tak je to u Apple, Google i Microsoftu, jenom unixáci s tím mají pořád problém.
S vasim pristupem bychom dnes meli treba vysavace takove, ze by lidi radsi klepali koberce na klepadle na dvore.
A to jako proč? S vaším, tj. unixáckým přístupem, bychom měli vysavače, které by byly dělané každý na jinou elektrickou síť, hadici by mohl ohýbat jenom oprávněný technik v servisu, hubici by si člověk musel dodělat doma sám a nic by se na tom nesmělo vylepšit, protože by to už nebyla "filozofie" původního modelu od Electroluxu.
Vyvojar vyviji pro uzivatele a tim je v pripade spravy systemu admin, ne vyvojar
U operačního systému je uživatelem vývojář aplikací pro koncové uživatele.
Operační systémy jsou (respektive měly by být) navrhovány pro vývojáře aplikací. Tak je to u Apple, Google i Microsoftu, jenom unixáci s tím mají pořád problém.
Zrejme proto zastoupeni Widli, Masoxu a Androidu na serverech nikoho neohromi. Uzivatele serveru jsou totiz admini a ti si system predstavuji urcitym zpusobem, ktery je s uvedenymi OS nekompaibilni.
Tak pokud vím Wokna mají na serverech kolem 33%. O to ale nejde. Linux dneska nezaostává na serverech ale na desktopu. A kdyz budu parafrázovat Linuse, tak udělat OS pro servery je snadné. Horší je to na desktopu, protože to musí šlapat na mnohem širší škále konfigurací, kde se hardware, síť apod. mění pod rukama, člověk neustále instaluje a odinstalovává různé aplikace, a to všechno musí spolehlivě fungovat samo od sebe, bez žádného admina. Od toho je systemd. Jestli všechny tyhle požadavky splní se teprve ukáže, ale je to rozhodně nejnadějnější a vlastně jediný vážný pokus, jak je realizovat.
Mimochodem i na serverech je to dneska jinak. Čím dál víc firem chce servery na klíč (a/nebo rovnou v cloudu), které fungují samy a případná (vzácná) administrace se dělá přes webové rozhraní, které tím pádem předpokládá správní API - a jsme opět u systemd. Admini na plný úvazek, kralující nad systémem i nad uživateli, kteří si bastlí vlastní init skripty a kompilují kernel, už z velké části patří do jiné doby. Můžeme o tom vést spory, můžeme s tím i nesouhlasit, ale to je všechno, co proti tomu můžeme dělat ;-)
Linux dneska nezaostává na serverech ale na desktopu. A kdyz budu parafrázovat Linuse, tak udělat OS pro servery je snadné. Horší je to na desktopu, protože to musí šlapat na mnohem širší škále konfigurací, kde se hardware, síť apod. mění pod rukama, člověk neustále instaluje a odinstalovává různé aplikace, a to všechno musí spolehlivě fungovat samo od sebe, bez žádného admina. Od toho je systemd. Jestli všechny tyhle požadavky splní se teprve ukáže, ale je to rozhodně nejnadějnější a vlastně jediný vážný pokus, jak je realizovat.
Tak me to tak nejak uz leta funguje a bez systemd. Udev a tak, ze jo.
Ja ale nechapu, proc kvuli tomu, ze Poetteringovi to nefunguje na desktopu, musime v OS mit v podstate nevykorenitelny init, ktery proto musi byt i na serveru, protoze na nem uz pulka veci zavisi. Pricemz tedy zrovna na serveru je lepsi cokoliv jineho, nez systemd.
A to jako proč? S vaším, tj. unixáckým přístupem, bychom měli vysavače, (...)
-kde by filtr filtroval a neposílal analýzu vysávaného svinstva na centrálu
-kde by při objednání byla možnost zvolit si barvu, materiály, povrchovou úpravu, umístění a tvar madel
-kde by mi při ukončení podpory danému vysavači zpravidla nabídli nový vysavač
-které by měly kabel přesně tak dlouhý jak je zrovna potřeba
z citovaného příspěvku dále
-které by byly dodávané s přechodkami na různé síťové zásuvky
-který by měl ohebnou hadici a ne pevnou rouru
-kde bych si hubici mohl vybrat z katalogu, pokud by mi nevyhovovala dodaná
a hlavně
-u kterého když odejde kompresor nepošlu do hajzlu celý vysavač, protože to není monolit.
Ach ano, nekrmit trolly...
2. ... Operační systém má být navržen primárně pro potřeby vývojářů, ne sysadminů.
To si robis srandu? Tebe webserver, mail server a cely system spravuje vyvojar? Tak to vela stastia...
3. ... Žádný lepší ale prostě k mání není a nikdo žádný takový ani nevyvíjí, takže v praxi je to buď systemd, nebo status quo. Většina zjevně volí tedy systemd.
Ano a preto chlapci z TrueOS prechadzaju na OpenRC lebo ten nieje vyvyjany a udrzovany ludmi z Gentoo... Vecsina voli systemd aby mohla na distre spustit gnome a dalsie systemd dependency app...
4. Do teďka jsme se bez systemd obešli. Aneb k čemu mikroprocesor, zbytečně integruje moc funkcí a sálové elektronkové počítače se bez něj do teďka taky obešly.
Systemd mal nahradit stary SysVinit a nie nahradit cely system...
To si robis srandu? Tebe webserver, mail server a cely system spravuje vyvojar? Tak to vela stastia...
Tak předně, jak už bylo mnohokrát řečeno, cílem systemd je primárně zlepšit konkurenceschopnost Linuxu na desktopu a docílit toho, aby Linux už nebyl JENOM pro webservery a mailové serveru. Dále je fakt, že spousta firem dává přednost MS IIS a Exchange na Windows, i přes to, že nevýhody a problémy těchto produktů jsou všeobecně známy (proprietárnost, uzavřenost apod), a proč? Protože to není systém stylu "dodělej doma", kde rozchodit email je práce na týden. Uživatelé si kupují servery ze stejného důvodu, ze kterého si kupují desktopy: aby jim na nich chodily aplikace, které zrovna potřebují. Ne pro to, aby je mohli spravovat. Model centrálního počítače s adminem, do kterého se uživatelé přihlašují přes terminály, už mírně řečeno není typickým scénářem a návrh OS se musí vyvíjet podle toho. Někdo to holt pořád ještě nedokáže pochopit.
Ano a preto chlapci z TrueOS prechadzaju na OpenRC lebo ten nieje vyvyjany a udrzovany ludmi z Gentoo... Vecsina voli systemd aby mohla na distre spustit gnome a dalsie systemd dependency app...
Přesně tak, "vecsina voli systemd aby mohla na distre spustit gnome a dalsie systemd dependency app". TrueOS a Gentoo používají OpenRC, to je samozřejmě pravda a mají na to plné právo, ale při vší úctě to nejsou zrovna většinové distribuce. Neboli silně pochybuju, že by volba OpenRC v TrueOS nějak ovlivnila celkové směřování Linuxu a drtivé většiny komunity. Je samozřejmě dobře, že takové distribuce jsou a jistě dobře poslouží těm, kteří se s existencí systemd stále nemůžou smířit. Od toho je to open source - i když upřímně řečeno nevím, proč tito kverulanti nepoužívají radši rovnou BSD.
Systemd mal nahradit stary SysVinit a nie nahradit cely system...
Systemd měl nahradit návrh (nebo možná nedostatečně promyšlený návrh) starého Unixu. To logicky obsahuje init, ale zdaleka jenom ne init. Ale váš příspěvek je svým způsobem velmi ilustrativní: lidem, kteří uvažují striktně v Unixových pojmech, jako je init, syslog apod., se systemd pochopitelně asi nikdy líbit nebude. Jenomže o to jeho vývojářům ani zastáncům nejde. Připomíná mi to klasickou hlášku, už nevím od koho: "FreeBSD dělají lidé, kteří milují Unix; Linux dělají lidé, kteří milují operační systémy."
je ti vic nez 13let? prijde mi ze pokud ne, tak si prosel nejakym mesicnim kurzem vymejvani mozku...
systemd neni o tom aby mohl byt "linuxovy desktop", ten uz minimalne 10let existuje (tedy myslim stav kdy opravdu takovy desktop mohl 99% BFU slouzit, jinak byl samozrejme uz roky predtim i kdyz ne tolik pro BFU)
tvuj pocit ze "pred systemd" byl GNU/Linux vhodny jen pro server hranici s "technickou demenci"
exchange neni o tom ze je to na kliknuti (coz neni) ze je to bezproblemove (coz uz vubec neni), ale o tom ze to stoji penize a je to od microsoftu, protoze o jeho nasazeni rozhodujou nejcasteji manazeri co technickeho aspektu nerozumi, ale zastavaji nazor "co je zadarmo nemuze byt dobre", "kdyz uz mame od Microsoftu tamto, tak koupime i tohle", v neposledni rade slysi na marketaky od microsoftu co prijde a ukecaj je na vzdusne zamky...
systemd mel nahradit init, nemel nahradit "cely vesmir", pokud by mel nahradit Unix koncept, tak ma podle tebe teda nahradit komplet GNU nastroje? X11/X.Org? a muze zustat Linux jadro? bootloader take musi byt systemd? takze tvuj promyslenej koncepts je SystemD/SystemD? a DE muze byt Gnome/KDE/Xfce nebo DE take musi nahradit system-desktopenviroment?
Dále je fakt, že spousta firem dává přednost MS IIS a Exchange na Windows, i přes to, že nevýhody a problémy těchto produktů jsou všeobecně známy (proprietárnost, uzavřenost apod), a proč? Protože to není systém stylu "dodělej doma", kde rozchodit email je práce na týden.
Ano ked ty ten maiserver/webserver spravuje vyvojar tak to je praca na tyzden, sysadmin ti ho rozbeha za 2 hodky a pritom si da cigaro, kavu a precita ten tvoj vyplod tu...
BFU ak si chce urobit vlastny web/mail server si zavola nejakeho kamosa co s tym ma skusenosti a nevyhodi 50k+ za exhchange+winserver+IIS, popripade si stiahne XAMPP
Uživatelé si kupují servery ze stejného důvodu, ze kterého si kupují desktopy: aby jim na nich chodily aplikace, které zrovna potřebují.
Ano a bez systemd to (nebolo) nieje mozne... Vdaka za systemd lebo bez neho som si nemohol spustit FF, LO, GIMP a tonu dalsieho softu, nastavit si job v crone pre backup, nastavit web sluzby atd...
Přesně tak, "vecsina voli systemd aby mohla na distre spustit gnome a dalsie systemd dependency app". TrueOS a Gentoo používají OpenRC, to je samozřejmě pravda a mají na to plné právo, ale při vší úctě to nejsou zrovna většinové distribuce.
No a predstav si ze na tom Gentoo beha aj GNOME (maju vlastny build tusim, mam zadsej KDE) takze je zaujimave ze ked to oni dokazu spravovat preco to nedokaze ta vecsinova distribucia s ovela vecsou zakladnou??? Inac to ze Open RC bude pouzivat aj TrueOS moze priniest novych vyvojarov na OpenRC a mozno sa zobudia a zacnu ho tiez pouzivat.
Ale váš příspěvek je svým způsobem velmi ilustrativní: lidem, kteří uvažují striktně v Unixových pojmech, jako je init, syslog apod., se systemd pochopitelně asi nikdy líbit nebude.
Nie moze to byt kludne aj systemd, syslog cron apod.., ale nie systemd, syslogd, crond, apod..
Tak předně, jak už bylo mnohokrát řečeno, cílem systemd je primárně zlepšit konkurenceschopnost Linuxu na desktopu a docílit toho, aby Linux už nebyl JENOM pro webservery a mailové serveru.
Aha. A jakym zpusobem presne diky systemd nastane rok Linuxu na desktopu? Kde presne je v systemd skryta ta wunderwaffe, diky ktere se to prihodi?
Ja mam podobny problem. Zase jsem neslysel dobry argument pro systemd. Stejna situace, donekonecna muzeme resit co je to "dobry"...
Je uplne jedno, jestli systemd je dobry nebo ne, pokud si kazdy bude moci vybrat, jestli to chce pouzit nebo jestli radsi pouzije neco jineho. A to uz bohuzel neni pravda, systemd se stava neodstranitelnym sajrajtem, zakorenenym jak svlacec.
Asi tě to nepotěší, ale realita je taková, že jeden z důvodů pro systemd je právě i to, že není možné si vždycky "vybrat". Systém, kde si každý může donekonečna "vybírat" každou jednotlivou komponentu znamená, že vývojář nemůže absolutně nic předpokládat a každá aplikace je tak vlastně OS sám pro sebe. Výsledek je pak ta nechutná slátanina, jakou známe, kde člověk musí neustále řešit, proč v aplikaci A nejde zvuk, když funguje v aplikace B, proč má aplikace C totálně podělané fonty, proč se služba D nerozběhne pro probuzení z hibernace atd. Opravdu bych byl rád, kdybych mohl věnovat trochu míň času "vybírání" a trochu víc produktivní činnosti.
Systém, kde si každý může donekonečna "vybírat" každou jednotlivou komponentu znamená, že vývojář nemůže absolutně nic předpokládat a každá aplikace je tak vlastně OS sám pro sebe.
Tohle by se dalo rici o nejakych aplikacich, ktere bezi jako daemon v systemu. Jenze situace je takova, ze za chvili bez systemd nepobezi ani piskvorky. Ale tesi me, ze systemd usetri strasne moc prace s psanim par shell skriptu lidem, kteri napriklad napisi databazi s kodem 15 km dlouhym. Tech 100 radky v bashi by uz asi nezvladli.
Výsledek je pak ta nechutná slátanina, jakou známe, kde člověk musí neustále řešit, proč v aplikaci A nejde zvuk, když funguje v aplikace B, proč má aplikace C totálně podělané fonty,
Ano, tohle se diky systemd urcite zlepsi. Jen by me zajimalo, jestli za vase problemy se zvukem nemuze Pulse Audio od tehoz geialniho umelce.
proč se služba D nerozběhne pro probuzení z hibernace atd.
Ano, jiste i na toto je systemd zazracnym lekem. Kdyz se sluzba neprobudi s obycehnym initem v bile krabici s cernym potiskem, tak se urcite probudi se systemd, s duhou na krabici a granulemi Poetteringova genia, ktere odstrani kazdy problem s ospalou sluzbou.
>jestli za vase problemy se zvukem nemuze Pulse Audio od tehoz geialniho umelce.
No pro mě přesně naopak :) Ale jo, před PA to byla lahůdka. Jedna aplikace OSS, druhá ALSA, do toho dělal nepořádek Arts v KDE.. Když jsem potřebovala přehodit výstup aplikace na jinou zvukovou kartu, musela jsem se modlit aby měla aplikace v konfigu výběr výstupního ALSA device a i tak to bylo krkolomnější než mít vše na jednom místě...
Tohle by se dalo rici o nejakych aplikacich, ktere bezi jako daemon v systemu. Jenze situace je takova, ze za chvili bez systemd nepobezi ani piskvorky.
Tak piškvorky, pokud jsou (jako že asi jsou) založené na frameworku gnome, bez systemd asi opravdu nepoběží, protože bez něj neběží gnome. Na tom ale není vůbec nic nového. Živě si vzpomínám na doby, kdy se řvalo proti GTK, Qt, Gnome a KDE, protože prý to je zbytečný balast, aplikace mají být napsané čistě v Xlib, ti co argumentovali tím, že potřebujeme lepší API, lokalizaci, přístup pro postižené, podporu drag-drop atd. byli posíláni do oněch míst, protože nechápou, že to odporuje "filozofii" unixu atd atd atd. Ještě předtím byli lidé, co trpěli infarkty kvůli samotnému X11, protože to je prý jako Windows, na unixu to nemá co dělat, správný admin dělá všechno ve vi (nebo v emacsu) a nikdo jiný, než admini, zřejmě počítače nepoužívá. Nic nového pod sluncem. Až implementujete piškvorky, které nemají zbytečné závislosti na libc a na kernelu, a nebrání vám tak v té tolik ceněné možnosti výběru, tak mi dejte vědět.
Ale tesi me, ze systemd usetri strasne moc prace s psanim par shell skriptu lidem, kteri napriklad napisi databazi s kodem 15 km dlouhym. Tech 100 radky v bashi by uz asi nezvladli.
Právě, že by je nezvládli, protože oněch 100 řádků v bashi je nejen na každém distru, ale pomalu na každém jednotlivém počítači jiných. A nestydíte se vůbec takhle vnucovat bash? Co možnost výběru? Co když trvám na tcsh?
To je právě příklad toho, co se systemd snaží řešit. Vývojáři databáze k ní přiloží jeden unit soubor a hotovo, uživatel ani oni už nemusí dál nic řešit. Prostě to funguje.
Tak piškvorky, pokud jsou (jako že asi jsou) založené na frameworku gnome, bez systemd asi opravdu nepoběží, protože bez něj neběží gnome. Na tom ale není vůbec nic nového.
Tak Gnome je uz davno docela monstruozita samo o sobe. Pokud Gnome ma byt dovodem, proc vsichni potrebuji systemd, tak vezte, ze spousta lidi Gnome nepouziva.
otevrene file descriptory - sysV init
lrwx------ 1 root root 64 Jan 24 19:08 10 -> /dev/initctl
to same systemd
lrwx------ 1 root root 64 24. Jan 17:56 0 -> /dev/null
lrwx------ 1 root root 64 24. Jan 17:56 1 -> /dev/null
lr-x------ 1 root root 64 24. Jan 17:56 10 -> /proc/swaps
lrwx------ 1 root root 64 24. Jan 17:56 11 -> socket:[15563]
lrwx------ 1 root root 64 24. Jan 17:56 12 -> anon_inode:[timerfd]
lrwx------ 1 root root 64 24. Jan 17:56 14 -> socket:[24537]
lrwx------ 1 root root 64 24. Jan 17:56 15 -> socket:[1224]
lrwx------ 1 root root 64 24. Jan 17:56 16 -> socket:[1235]
lrwx------ 1 root root 64 24. Jan 17:56 17 -> socket:[1238]
lrwx------ 1 root root 64 24. Jan 17:56 18 -> socket:[15570]
lrwx------ 1 root root 64 24. Jan 17:56 2 -> /dev/null
lr-x------ 1 root root 64 24. Jan 17:56 27 -> /dev/autofs
lr-x------ 1 root root 64 24. Jan 17:56 3 -> anon_inode:inotify
lrwx------ 1 root root 64 24. Jan 17:56 39 -> socket:[16250]
lrwx------ 1 root root 64 24. Jan 17:56 4 -> anon_inode:[eventpoll]
l-wx------ 1 root root 64 24. Jan 17:56 40 -> /dev/kmsg
lrwx------ 1 root root 64 24. Jan 17:56 41 -> socket:[1240]
lrwx------ 1 root root 64 24. Jan 17:56 42 -> socket:[15200]
lrwx------ 1 root root 64 24. Jan 17:56 43 -> socket:[15585]
lrwx------ 1 root root 64 24. Jan 17:56 44 -> socket:[15584]
lrwx------ 1 root root 64 24. Jan 17:56 45 -> socket:[15203]
lrwx------ 1 root root 64 24. Jan 17:56 46 -> socket:[15206]
lrwx------ 1 root root 64 24. Jan 17:56 47 -> socket:[15207]
lrwx------ 1 root root 64 24. Jan 17:56 48 -> /run/dmeventd-server
lrwx------ 1 root root 64 24. Jan 17:56 49 -> /run/dmeventd-client
lrwx------ 1 root root 64 24. Jan 17:56 5 -> anon_inode:[signalfd]
lrwx------ 1 root root 64 24. Jan 17:56 50 -> /dev/initctl
lrwx------ 1 root root 64 24. Jan 17:56 51 -> socket:[15577]
lrwx------ 1 root root 64 24. Jan 17:56 52 -> socket:[15602]
lrwx------ 1 root root 64 24. Jan 17:56 53 -> socket:[12545]
lrwx------ 1 root root 64 24. Jan 17:56 54 -> socket:[12546]
lr-x------ 1 root root 64 24. Jan 17:56 55 -> pipe:[15590]
lr-x------ 1 root root 64 24. Jan 17:56 6 -> /sys/fs/cgroup/systemd
lrwx------ 1 root root 64 24. Jan 17:56 7 -> anon_inode:[timerfd]
lrwx------ 1 root root 64 24. Jan 17:56 8 -> socket:[15560]
lr-x------ 1 root root 64 24. Jan 17:56 9 -> /proc/1/mountinfo
a to jen systemd s pid=1
V poctu otevrenych descriptoru vede systemd jasne pred SAP a Oracle
Co to s lopatou melete za blbosti? Spousteni sluzeb je u systemd uplne stejny jako u klasickyho initu a stejny jako u jakyhokoli jinyho initu v UNIXu. Spusti se shellovej skript kterej spusti danou sluzbu. shellovej script se po startu sluzby ukonci a parrentem procesu se stane init. Tak to funguje u System V init, OpenRC, Runit, Systemd i SMF u Solarisu. Jedinej rozdil u Systemd a SMF je ze je tam navic textak popisujici jak presne se ma ten script (pripadne kontrolni exac treba apachectl) spoustet.
Ale prosímtě, ty vůbec nevíš, jak systemd funguje a jenom šíříš FUD. Systemd nespouští žádný shell, ale spouští service přímo jako proces. Těch možností, jak to může udělat, je spousta, doporučuju nastudovat https://www.freedesktop.org/software/systemd/man/systemd.service.html# konkrétně option Type.
systemd navíc umí socket activation, který ještě více šetří zdroje pokud chceš, tohle shell based inity neumí vůbec a musíš na to vzít další komponentu (inetd).
Ja vim presne jak systemd funguje. Uz sem nejen pro nej par servicu delal. Type je jen nastaveni supervisoru. Nijak to neresi, veci jako nastaveni prostredi, zmeny uzivate atd. Sice tam mas ExecStartPre, ale psat do toho naky pre checky ci cleanup to by bylo dost pro masochisty.
Cili pro par service presne navrzenych systemd to neusetri nic, protoze to misto shellovyho scriptu otevre textak. A pro cokoli se slozitejsim spoustenim to veme dvakrat vic file deskriptoru, protoze krome spousteciho scriptu musi nejdriv ten textak, aby ten script vubec nasel.
A to ze se usetri jeden file deskriptor na inetd, kdyz si to otevre 20 dalsich fakt nemuzes myslet vazne...
Aha, takže otevřít textový soubor a ten přečíst je podle tebe stejná režije, jako spustit bash a spustit v něm skript, který teprve spustí aplikaci?
Jinak mně je jedno, že nemáš rád systemd, ale nešiř o něm prosím FUD a nepravdy, systemd opravdu žádný bash pro spuštění service nepotřebuje a nespouští. Tvoje tvrzení bylo nepravdivé.
Nesirim FUD jen rikam jak to je. Tech servicu kterych start up script potrebuje je porad hodne a to cislo se nikdy blizit nule nebude.
Mas pravdu, ze pokud ten textak parsuje primo systemd pri startu, tak na ukor permanentniho naroku na pamet teoreticky v idealnim pripade nemusi spoustet dalsi interpret (shell) pokud to sluzba nevyzaduje.
To uz ale neplati pri manualnim spousteni sluzeb, kdy je narok vzdy minimalne stejny ci vyssi nez u klasickyho initu.
systemctl + .service (+ shell + script) + samotnej service
vs.
shell + script + service
Kazdopadne vsechno pohle je naprosto bezpredmetny, protoze ten script bezi vzdy par sekund, takze v realu systemd nenabizi vubec zadnou vyhodu na ukor pameti a slozitosti...
OK, muzu porovnavat debian se systemd, kde bezi ssh, httpd a proxy oproti openwrt s busyboxem, kde bezi ssh, httpd, pppd, hostapd a dnsmasq
Debian ukazuje po startu posledni PID 1647
openwrt ukazuje PID 1676.
Kde ze je tech "bambilion spousteni shellu v klasickych init resenich", ktery systemd usetri?
systemd navíc umí socket activation, který ještě více šetří zdroje pokud chceš, tohle shell based inity neumí vůbec a musíš na to vzít další komponentu (inetd).
Cim presne je lepsi pouziti komponenty systemd namisto jine komponenty (inetd)? Ten systemd to jaksi nedela zazracne zadarmo, ale ma na to zase nejaky ten necod, ktery tam musi bezet misto initd a otazka je, jestli to dela nejak lepe nebo usporneji.
A proč by to nemohlo být i v systemd? Uživatelé to asi chtějí, tak je to i v systemd. Co bude nebo nebude v systemd závisí jen na poptávce uživatelů a ochotě přispěvatelů to do systemd implementovat. Nebo už je problém i v tom, že systemd implementuje nějakou funkcionalitu? Chtěl bys to nějak direktivně řídit, rozhodovat o tom, co v systemd bude a nebude? Můžeš, pošli patch na odstranění podpory socket activation ze systemd, pokud s tím máš problém a nechceš to. Obavám se ale, že takový patch komunita nepřijme.
Soft limit je uplne neco jinyho. Soft limit a hard limit se uplatnuje na uzivatele (ulimit) a s nastavenim jadra nema nic spolecnyho.
Limit v jadre je prave to na co si odkazoval a ma zabezpecit stabilitu jadra. Samozrejme muzes si to menit, ale jako u spousty dalsich nastaveni jadra se pak nesmis divit az ti zacne padat...
Zase šíříš FUD... Proč by mělo začít jádro padat? Změna file-max je naprosto standardní operace, která se provádí z user space, není důvod, aby cokoliv padalo.
Tvůj původní argument o tom, že systemd otvírá desítky descriptorů a něco v jádře by mohlo dojít je naprosto směšný, to se ti snažím vysvětlit. Zaprvé v jádře žádný limit není a zadruhé omezení, které si můžeš sám nastavit, je bežně řádově ve stovkách tisíc descriptorů.
Koukam, logicky mysleni neni tvoje silna stranka co?
Proc myslis, ze to nastaveni vubec v jadre je? Pro strandu kralikum?
Maximalni pocet file deskriptoru muzes menit, ale ne nijak dramaticky, protoze moc vysokym pocem ohrozujes stabilitu pocitace (resp. muze vycerpat volnou pamet).
Linux Dokumentation project doporucuje 256 filedeskkriptoru na 4MB pameti.
http://tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap6sec72.html
Cili je to omezeny resource a ne ze ne. To ze ten limit je bezne ve stovkach tisic sem nikde nerozporoval...
TrueOS jsem zkusil a vratil se zpět k FreeBSD, prostě upřednostňuji stabilitu před nejnovějšími X apod. OpenRC není špatná volba ale zkrácení z původní jedné minuty není nic jiného než reklamní nesmysl - mě kompletní FreeBSD i se všemi službami startuje 15 vteřin a to 6 z toho stráví v BIOSU...
Je zajímavé jak se tu strhla diskuze o systemd (jak je dobrý, jak je špatný), když zprávička zmiňuje init a OpenRC? (senilita? neschopnost myšlenku udržet... a neschopnost myšlenku opustit).
OpenRC je celkem dobrá volba, hraji si s tím na Gentoo a myslím, že vývoj jde správným směrem jako alternativa k výše zmíněným. Přidat službu do OpenRC je velmi jednoduché (nelze srovnat s init; systemd). Bohužel, ačkoliv podporuje paralelní starty, uvádějí autoři, že to může občas způsobit problémy. Obecně jde o to, správně nastavit závislosti (jinak to ostatně nejde ani v systemd) a kvůli tomu, že je to alternativní (minoritně využívaný spouštěcí) systém, ne vždy to bude správně (často skript píše někdo úplně jiný, než autor aplikace).
Jinak ta přehlednost jednoduchost je u toho systému nesrovnatelná se všemi alternativami a na server/embed dobrá volba. Drží se základní unixové filozofie - jednoduchosti.
