Názory k článku
Ubuntu přechází na systemd
-
Robert Smol (neregistrovaný)
Je to zbytecne slozita architektura jez ma dnes uz zbytecne velky "overhead". Zkuste si priste udelat drobny vyzkum , napriklad do google jsem dnes zadal "why wayland" a odkazu je celkem dost.
http://wayland.freedesktop.org/architecture.html
http://julien.danjou.info/blog/2010/thoughts-and-rambling-on-the-X-protocol -
Jop, drobny vyskum som si urobil, ked som riesil ako doviest k pouzitelnosti androidi tablet. Za prve som zistil, ze si k Waylandu musim napisat vlastny kompozitor, pretoze ten jediny skoro-existujuci je modularny jak kovova gula a k behu potrebuje hadam aj driver v jadre. Plus teda, k behu akejkovek aplikacie vyzaduje len tak mimochodom beziaci X-server.
A za druhe som zistil, ze je X sice moloch, ale s architekturou jednoduchou a legovitou, takze nieje ziaden problem ukecat ho tak, aby si kreslil kdesi do bufferu, ktory ja potom v 20 riadkovom APK zrenderujem na display.
A samozrejme, ako spravca ocakavam od svojho vzdialeneho pristupu nieco viac, nez da VNC ;)
-
peter (neregistrovaný)
Nejedná sa o voľbu, jednoducho sa plánovali zviezť na práci odvedenej komunitou okolo Debianu. A s tým že to nestíhajú súhlasím. Dôkazmi sú napríklad meškanie s mobilnou platformou (mala byť hromadne prístupná pred dvoma rokmi) alebo MIR. Nájdu sa aj iné.
PS: Ja tiež veľa vecí nestíham, takže to neberiem až tak negatívne. Termín je závezný až na zmluve.
-
Trident (neregistrovaný)
Tak to soucasti vseobecne strategie zprznit co se da. Pulseaudio-Uhnity-systemd co bude dal? Divte se pak ze widlari si delaji z linuxaku srandu. Jeste ze mame BSD.
Je cas na to zrusit ubuntu na jednom svem desktopu kvuli systemd. Aspon ve chvili kdy dojede podpora.
Problem neni ani tak v myslence ktera je v zakladu dobra, ale v Lennartovi a jeho parte ktery designem a implementaci rozs...u na co prijdou.
Navrhuji crowdfunding na rentu pro nej a jeho nohsledy aby uz nic nevyvijeli.Proc je ta sr... zavisla na dbus? Nechci d-hnus! Chci veci co nejvic transparentni.
Init system by mel byt co nejvice minimalisticky. Naco early services? Jak to bude pak znovupouzitelne na embedded zarizenich kde je treba optimalizovat?Porovnani:
https://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems -
muf (neregistrovaný)
Souhlasím.
Pokud bude možnost nějakou finanční sbírkou ty magory zastavit a poslat někam, kde nebudou škodit, rád přispěji řádově v tisících korun.
Zrovna dnes jsem na OpenSUSE 13.1 řešil problém s tím, že po bootu nenaslouchal na LAN CUPS a uživatelé marně a marně posílali další joby na tiskárnu... Po startu PC s tiskárnou bylo vždy třeba CUPS nahodit ručně.
Nakonec jsem to víceméně obešel - zrušil tu hovadinu se .socket a udělal CUPS jako normální .service, která se při startu systému prostě spustí.
Mě teď, musím říci, nezajímá, že je to možná chyba správce systemd u SUSE a ne přímo bug v upstreamu. Mě prostě _s_e_r_e_, že ztrácím čas(v sobotu) nad hovadinami, ze kterých nekouká žádný technický benefit. Dříve bylo nahození služby průhlednou a triviální záležitostí, teď je to zasviněno produkty jakýchsi chorých mozků a o vše se stará více než pochybný superuniverzální moloch, bůhvíjak interpretující konfigurační soubory.
Nakopat ty magory a poslat je k Laelovi do Microsoftu - přesně tam patří. Jak jsem psal, rád se na tom budu finančně podílet. -
> Jak to bude pak znovupouzitelne na embedded zarizenich kde je treba optimalizovat?
Nijak. Robil som taky sukromny port userspacu Archu do x86 Androidu. Absolutne vsetky sluzby su dodavane so .service subormy, este aj v AURe furt niekto p.cuje, ze ma clovek sluzbu v /etc, kde normalne patri. Vo vysledku sice mozem nainstalovat napr. Apache, ale spustat si ho mozem akurat rucne, bo .service samozrejme nic pouzitelne neprecita.
Ale hlavne ze mame... co vlastne? -_-
-
ZiGi (neregistrovaný)
neviem ci sa da odrezat zo startu viac ako 2-3 sekundy zmenou init sysemu.
najvacsia zmena v rychlosti startu za posledne roky bolo zavedenie fast start v UEFI (alebo ako sa ta featurka vola). a ze by mi tie 3 sekundy stali za systemd a s nim spojene sracky...
Mozno som uz stary, ale vobec netuzim po journald, logind, uz tak je problem nastavit udev, srackovite polikity a podobne veci mi strpcuju zivot. a to ani nie som developer, staci administrovat nejaku tu zbierku serverov a desktopov. Preco, kurva, po kazdej zmene miesto slubovaneho zlepsenia su veci iba neprehladnejsie a horsie? -
zzz (neregistrovaný)
No ono neni az tak dulezite co chces ty, ale co chce RedHat a ten plati lidi jako Lennart aby makali pro _jejich_ cile. LP se zbytecne demonizuje. Je to jako v te bajce o oslu kteremu se vsechna zvirata v dzungli neodvazila postavit. Ne ze by se obavala jeho, ale lva ktery stal celou dobu za nim. Pokud by odesel on nebo Sievers, tak nasadi obratem nekoho jineho.
Ale jinak souhlas, pod taktovkou RedHatu - kolaboranta s nechvalne proslulou NSA, se ekoystem Linuxu vytrvale rozbiji a vzdaluje od *nixu smerem k Windows-like systemu. Jinak predem lituju adminy CentOS/RHEL.
-
sid (neregistrovaný)
Chlapci management RH na vas caka. Keby tusili, ze co za zbierku geniov tu je tak uz ten microsodf maju 5x zniceny:-). Preco miesto debilnych kecov si neforknete napr centos a neurobite si vlastny init? Kedze kazdy tomu tak rozumiete tak najneskor do roka urcite kazdy rozumny clovek to bude pouzivat. Specialne ten clovek co ma o
suse je uplne bozi. Takze chyba je mozno v upstreame odstranena ale sw je shit lebo to neni v jeho distribucii. Zasnem. -
muf (neregistrovaný)
Já žasnu nad tupostí některých lidí.
Tak ještě jednou pro ty pomalejší:
Psal jsem, že popsaný problém asi není způsoben chybou v upstreamu, ale možná nedostatkem při implementaci do distribuce. Vůbec se tomu nedivím a ani nenadávám správcům systemd a cupsu u SUSE, protože vidím, v jakých sračkách (udělaných dle nejlepších tradic Microsoftu) se v případě systemd ti nešťastníci musejí hrabat.K čemu mně systemd vlastně je? Rychleji to s ním nebootuje, je to uvnitř zbytečně složité a nepřehledné a tím náchylné ke všemožným chybám, nic to neušetří, distribuce s tím mívají problémy. S elegantním řešením to nemá nic společného, když s tím pracujete na příkazové řádce, připomíná to všechno možné jen ne unixový nástroj. Z dříve triviálních věcí se díky systemd někdy stane komplexní problém.
Určitě by to byla zajímavá čísla, pokud by si někdo dal tu práci a vyčíslil kolik času admini díky tomu ztrácejí zcela zbytečně.
A nejhorší na tom je, že to začíná prorůstat skoro všude - init je těm magorům málo...
Často se nadává na Canonical, ale jejich upstart se za slušnou náhradu rc scriptů považovat kupodivu dal. V CentOS 6 mě kupříkladu nikdy nenasral.... -
sid (neregistrovaný)
Jasne, admin sa nedokaze nic nove naucit? Neviem ci vam celkom dochadza ze to co bude implementovana a ako zavisi na ludoch co to robia a venuju tomu cas. Navyse nic vam nebrani si zaplatit support a potom sa dozadovat riesenia. Takto mozete maximalne zaplatit niekomu chytrejsiemu aby vam to urobil. Pripadne odist inde.
-
Trident (neregistrovaný)
Uvedom si ze tato oblast nejsou nagelovany startupovy agilni pometla programujici webovy pizmone v HTML666.9. Admini potrebuji stabilitu,prehlednost,jednoduchost a _zpetnou_kompatibilitu. Protoze sami musi spravovat slozity ekosystem a nemaji cas se piplat s takovymi trivialitami.
Maji spoustu jine prace nez zkoumat overingeneered zbytecne komplexni system. V momente kdy zajistuju clustery a staram se o to aby server mel spravne pripojeny disky neni muj problem zkoumat jak je momentalne roz...... systemd v jake verzi. Extremy typu ze si stracem pul dne zjistuju kam ta kravina vlastne saha nebudou vyjimkou.
Systemd porusuje pravidlo "Keep it simple, stupid" na vsech frontach.Proc se ucit neco co nedava smysl a je rozbity a rozbije se dal?
Proc se ucit neco co lenart pri pristi verzi zase jinak rozbije?
Proc se ucit neco co se vyviji odspodu nahoru?
Proc se ucit neco co pouziva zbytecny sluzby ktery v produkci nepouzivam?
Proc se ucit neco co ma spoustu tykadel okolo pres ktery je mozny to hacknout?
Jak maji chudaci distra udrzovat tenhle silenej moloch?
Cas je drahy. A je lepsi ho venovat studiu kvalitni technologie ktera ma nejakou budoucnost.Komplexnejsi Solarisi SMF jsem se naucil protoze mi reseni davalo smysl a celkem dobre to funguje. Sice se zde projevila uchylnost Sun/Oracle mit vsechno v xml - tipuju kvuli toolum pro engineered systemu, ale ten system funguje dobre a je prehledny. Pokud clovek a jen jak opica manazuje sluzby staci dva/tri prikazy. Stale vsak drzi zpetnout kompatibilitu s init skripty.
Tradeoff toho ze musim stravit cas naucenim se neceho jineho se vyplatil.A i doted po nakych 8mi letech od uvedeni ho rada adminu neumi. Vcetne Oraclu samotneho.
-
Ondra Satai NekolaZlatý podporovatelArgument KISSem je validni, ale ta sada urazek kolem je minimalne zbytecna.
-
sid (neregistrovaný)
Garantujem vam ze naucit sa dobre programovat je nepomerne zlozitejsie a ladit napr telefonu ustrednu (teraz mam na mysli to co sa predava pre gigantov ako TCom) je tak inde, ze mi vase vyplakanie o zlozitom ekosysteme pride sorry ale usmevne. Takze toto nekonecne fnukanie pri kazdej zmene hocicoho je podla mna znak toho, ze kopec adminov tomu figu rozumie a ma este mensiu chut cosi sa ucit. Naucili sa zaklady bashu a tym padom maju pocit, ze mozu kecat k veciam o ktorych ani netusia a jedine co vedia, ze pri pive mu pepa povedal, ze systemd je chujovina, tak ano urcite je to tak.
Dokazem pochopit, ze nie kazdy ma chut a cas sa ucit cosi uplne nove ale kolkokrat prechadzate na novy init system? Co vam brani pockat na centose 6 dalsie 3 roky kym sa systemd dostane na level ktory ocakavate? Zaroven stale je tu moznost prejst na nieco uplne ine, pripadne sa spojit zaplatit si ludi a naprogramovat si vlastne vyhovujuce riesenie.PS:
Keby zrovna teraz fungoval vsade systemd uz 10rokov a niekto by rozhodol, ze je dolezite mat init zalozeny na scriptoch a pid suboroch som absolutne presvedceny, ze ludia co teraz kricia boli v prvej rade a znova kricali, ze vsetko je rozbite, je to stupidne, atd atd. -
muf (neregistrovaný)
Škoda slov k těm vašim blábolům.
Naučil jsem se konfigurovat systemd docela dobře(když nic jiného, aspoň nějaká dokumentace k tomu je), totéž jsem učinil s upstartem. Jak jsem psal, upstart kupodivu nevadí. A právě proto píšu to co píšu.
Živím se mimo jiné také programováním v embedded a naprosto sebejistě můžu říci, že Poetering a spol. nemají s inženýry nic společného. Pokud bychom my přistupovali k softwaru jako oni, autům by nečekaně chcípal motor, blokovala by se kola a kdybychom škodili v leteckém průmyslu, letadla by padala a nikdo by nevěděl proč. Zato by se po havárii inspektoři přehrabovali v tunách zbytečného balastu a ztráceli cenný čas. Oni mají štěstí, že PC nebo server stojí v klidu na podlaze nebo v racku.
To že z někoho tryskají "skvělé" nápady a vize ještě neznamená, že jejich realizace bude přínosná, pokud se při tom nebude přemýšlet. Zatím se jim daří jediné - prznit linuxový "ekosystém". -
Sid (neregistrovaný)
ak mate pocit , ze systemd je pre RT embedded systemy tak tomu zjavne nerozumiete. Ak teda chapeme RT rovnako (len staticke alokacie, RT kernel, casova zlozitost algoritmov). Mate pocit ze Poetering a spolok mieria primarne na embedded zariadenia? Mna stale udivuje, ze velke firmy zamestnavaju dementov ked tolko "inzinierov" je v kazdej diskuzii. Vy viete o jednom svojom use case, ludia co to realne robia musia riesit xy dalsich a obcas protichodnych. Takze tieho hrdinske reci bez nejakej implentacie alebo navrhu (realnom) ktory za vami stoji su ako ked je u nas 5 milionov trenerov hokeja.
-
„Mate pocit ze Poetering a spolok mieria primarne na embedded zariadenia“
Já bych tomu neříkal pocit, jejich zaměření na embedded zařízení mi připadá více než zjevné. Pokud vím, tak glib a služby postavené nad glib odmítají s odůvodněním, že to není staticky analyzovatelné a tudíž to není obecně nasaditelné (tedy především v embedded světě). Mnohá rozhodnutí odůvodňují potřebami embedded vývojářu z různých větších společností.
-
Karel (neregistrovaný)
Nedávno jsem v podobné souvislosti slyšel krásné přirovnání:
Je to jako přecházet od dynamitu ke střelné bavlně. Má menší účinnost, je dražší, je nebezpečnější a přeprava je o dost náročnější. Ale dá se nacpat do kanónu a půjde z něj vystřelit, což se vám s dynamitem nepovede. Navíc je práce s ní mnohem větší adrenalin než ta nuda s dynamitem.
-
j (neregistrovaný)
Boze, ty ses zjevne z M$, tak je podobnych volu neurekom ... takze firma si misto admina bude jeste platit support, kterej ji ovsem posle doprdele s tim, ze za to muze tvurce balicku, takze ve finale si muze najmout asi tak 10 000lidi a nechat si napsat vlastni system ... aby mela pod kontrolou vse.
-
PavelC (neregistrovaný)
To organizujete nějakou soutěž v rychlosti bootování ? Sorry, ale mě to přijde jako neuvěřitelná hovadina nejen na desktopu (kde je suspend do paměti nebo na disk) a na serveru už tuplem. Kolik procent času připadá na čas bootu z celkové doby práce s počítačem ? 0,01 % ??
Až někdo napíše jinej init, kterej bude startovat ještě rychleji tak se zahodí systemd a přejde se na něj ?
Ach jo :( -
Ondra Satai NekolaZlatý podporovatel
Ono to ma samozrejme vyznam, pokud je serverova infrastruktura "on demand". Ale taky nemam pocit, ze by rychlost bootu byla nejdulezitesi kriterium (na druhou stranu: pokud na ctyrjadre s kopcem pameti a rozumnym SSD neco bootuje do desktopu trebas minutu, tak to take neni pro init zrovna vyznamenani a uvazoval bych, cim ho nahradit).
-
Trident (neregistrovaný)
Pokud je on demand tak jsou to stejne virtualy,hw partisny, zalozni boardy ktery nahodis..
A hot standby ty muzou byt jen zmrzly at uz ve stavu snapshotu nekde na discich a nebo zmrzly primo v ram aby se nahodily rychle.To co popisujes ty je cold-standby nabeh systemu uplne z vypnuteho stavu a tam se stejne pocita s nakou dobou nabehu protoze cold zejo.
Takze opet je tu tradeoff komplexity vetsi nez co ziskam na rychlejsim bootu. Rychlejsi boot mohu zajistit snadno jiz alternativnimi a odladenymi metodami.
Velke zelezo je stejne nabehle stale protoze boot trva fakt dlouho.
-
j (neregistrovaný)
Oni ti lidi tady kolem pak ty sracky musej adminovat vime? A je jim zcela uprdele kdo to posral, je zajima to, ze (jak tu je vejs) musej v sobotu misto vlaleni se u kafe resit, ze je neco rozmrdany, pricemz je to tim, ze nefunguje nejakej binarni moloch. Pokud mi nefunguje script, tak si za par minut napisu vlastni - mozne neuniverzalni, mozna uplne blbej, ale bude fungovat. Kdyz nebude fungovat binarni moloch ... tak muzu leda psat stiznosti na nadrazi.
-
-
Ondra Satai NekolaZlatý podporovatel
Coz ma prakticke dopady jake? Bylo to "potrebujeme implementovat tenhle dobry napad" nebo "potrebujeme implementovat tuhle svinarnu"?
-
liquidwater (neregistrovaný)
http://techrights.org/2013/11/24/tpm-back-doors-patriot-act-etc/
Na podvrzeni kryptografii ktere umi NSA cracknout v realnem case nebo primo backdoory jasny dukaz primo neni, ale minimalne ta vzajemna nepopirana spoluprace, co je NSA zac a co vyplavalo na povrch o spolupraci na smirovani se softwarovymi giganty jako Microsoft, Oracle, Google, Facebook, Apple je alarmujici. Tezko uverit ze s nekym takovym maji jen formalni vztahy.
-
Robert Smol (neregistrovaný)
Tak zkusim zareagovat jen na ty lepsi casti.
Proc d-bus/d-dbus? Protoze je to schopny mechanismus pro IPC. Standardizovany IPC pro Linux chybi. Sice je na systemu spousta IPC, ale zadny z nich vam standardne nedokaze dat ty vveci navic (zaruceni doruceni zpravy, fronty, bezpecnost) v ucelene podobe.
V tom porovnani vychazi systemd absolutne nejlepe, namitate ze ma proprietarni implementace cron/at? Co vam brani bezet cron/at?
Minimalisticke to je dost, podivejte na zdrojove kody https://github.com/systemd/systemd/tree/master/src, zjistite, ze takto dobre oddelenne moduly a ciste napsany kod tezko jinde najdete.
Lennartovi mozna muzete vytknout zpusob komunikace, ale osobne mi prijde dost podobny tomu co dela Linus. Rozhodne bych se ale s Lennartem neprel o technickou implementaci (ten clovek se tomu doiopravdy uz x let venuje, problematiku zna velmi dobre). Navic systemd/k-dbus neni zalezitost pouze Lennarta .
Systemd nam ve Fedore jede nejakou dobou a sama spokojenost. Jeden krasny system na spravu systemu, jeden .service file pro vsechny distribuce. Nevim, ja osobne jsem velmi spokojeny.
s pozdravem
-
j (neregistrovaný)
Ve widlich mi taky nic nebrani si nainstalovat vlastni shell, vlastni browser, vlastni ... ale vazne nevim, proc mam kurwa v tom systemu mit ten deravej exploder, kterej nanic nepotrebuju ... zato kdyz se podela, tak mi jen zpusobuje problemy.
Tohle je naprosto PRESNE totez, navic to mrvi dalsi balicky, ktery se to snazi schramstnout a integrovat => klidne z nich vyhodi funcionalitu, kterou pouziva bambilion lidi, jen proto, ze to politicky nezapada do systemd.
Ale nekteri toto samo nedokazou a nedokazou pochopit. Potrebujes udev? Musis mit systemd. Potrebujes d-bus? Musis mit systemd .... podela se neco na systemd = nebude ti fungovat system, a to i v pripade, ze systemd nepouzivas primo.
-
SB (neregistrovaný)
Jako mírně zkušeného uživatele Linuxu mě děsí, že bude init nahrazen nějakým komplikovaným molochem. Co když budu potřebovat něco upravit? Bude to stejně tak jednoduché? A stojí tolik práce a navýšení komplexnosti (tj. i chybovosti, udržovatelnosti, ...) řešení za těch 10 sekund při bootu???
-
Filip JirsákStříbrný podporovatelOn se opravdu někde používá jen init? Co já vím, ve skutečnosti je init tak „jednoduchý“, že už dávno nestačí a jen spouští jiný proces, který se teprve stará o skutečný start služeb systému. Mně vůbec nejde o nějakých deset sekund při bootu – já budu spokojen, když konečně nebudu mít v systému dva správce služeb, ale jen jednoho.
-
Filip JirsákStříbrný podporovatel
Ve které distribuci? V Gentoo, Fedoře, Debianu, Ubuntu, ArchLinuxu a OpenSUSE, když se používá sysvinit, jsou dva správci služeb – nejprve se spouští původní sysvinit, a z něj se pak spouští rc-*, OpenRC, upstart, systemd, daemontools nebo něco podobného.
-
Filip JirsákStříbrný podporovatel
Skript nestačí. Potřebujete něco, co ten skript při startu systému spustí. Tedy nějakého správce těch služeb – původně to byl init (proto jsou tam ty runlevely apod.). Postupně se ukáže, že je dobré, když se ten správce umí nějak postarat o závislosti služeb – nejprve tak, že je administrátor seřadí a správce je spouští postupně v určeném pořadí, později ten správce uměl pořadí podle závislostí stanovit sám. Také je dobré, když se ten správce umí o službu postarat i v průběhu běhu té služby – třeba spravovat logy nebo službu znovu spustit, pokud se ukončí. To znovuspuštění třeba uměl už sysvinit, ale správce založený jen na spouštění rc-skriptů o tuhle schopnost přišel.
-
> Potřebujete něco, co ten skript při startu systému spustí.
# Start daemons
for daemon in "${DAEMONS[@]}"; do
case ${daemon:0:1} in
'!') continue;; # Skip this daemon.
'@') start_daemon_bkgd "${daemon#@}";;
*) start_daemon "$daemon";;
esac
done
kde teda start_daemon zavola /etc/rc.d/"$1" start. Koniec citatu z poslednej pricetnej verzie Archovskeho initu :)Vsetko ostatne (spravovat logy? samoukoncujuce sa sluzby?!) je otazkou utilit, ktore v ziadnom pripade do initu nepatria.
-
Filip JirsákStříbrný podporovatel
Už tenhle skript je ale jeden nástroj navíc. Původně měl správu služeb zajišťovat init, s tím vaším skriptem už na to máte dva nástroje – nejprve init, a pak tenhle váš skript. Takže sysvinit asi neumí to, co se po něm dnes požaduje, když je nutné ho něčím doplňovat.
Samoukončující se služby jsou všechny služby – u každé služby může dojít k chybě, kvůli které se služba ukončí. Nastartovat službu, která se ukončila, umí i sysvinit – pokud to podle vás umět nemá, stěžujte si jeho autorům, že je to příliš velký bumbrlíček, který dělá i věci, které po něm nikdo nechce…
-
Ten skript je len funkcia z inicializacneho skriptu Archu. Nieje to ziaden nastroj, len to len kod, ktory nikto pricetny nebude z bashu prepisovat do cecka.
So sysvinitom sa, pokial viem, vzdy pouzivaju rc.d skripty, takze si neviem predstavit, ako by init vobec zistoval, ze sa nejaka sluzba zastavila.
-
Filip JirsákStříbrný podporovatel
Takže už jste si tak zvykl na to, že k initu musí být dobastlené další funkce v shellu, že vás ani nenapadlo přemýšlet o tom, zda by to nešlo udělat lépe. Někoho jiného to naštěstí napadlo.
sysvinit umí službu v případě pádu restartovat, slouží k tomu akce respawn v inittab.
-
Filip JirsákStříbrný podporovatel
Což je poněkud smutné vysvědčení pro nástroj, který je pro spouštění služeb určený.
Takže když už teď víme, že init nedělá zrovna nejlépe to, k čemu je určený, je nutné to dobastlovat různými skripty, které také nefungují zrovna perfektně, proč nenapsat nový nástroj, který to bude dělat lépe? No, a přesně takhle vznikly Upstart, Runit nebo Systemd.
-
> Což je poněkud smutné vysvědčení pro nástroj, který je pro spouštění služeb určený.
> Takže když už teď víme, že init nedělá zrovna nejlépe to, k čemu je určenýsysvinit. Sys-V-init. System 5 Init. Nastroj pre inicializaciu systemu. Robite si zo mna srandu?
Vsetko po inite, vratane spustenia sluzieb sa robi skriptami jednoducho preto, lebo to jednoduchsie spravit nejde. Skripty sa daju v pripade potreby jednoducho prisposobit a spravcovia balickov maju pekny zvyk prisposobene skripty neprepisovat. Skuste si prisposobit systemd tak, aby Vam to prezilo update :)
-
Filip JirsákStříbrný podporovatel
Místo žonglování se jménem si raději přečtěte popis, co sysvinit dělá. Sysvinit je nástroj pro spouštění a správu procesů. Není žádný principiální důvod spouštět některé procesy jedním nástrojem a další jiným. Důvod, proč se to tak dnes s sysvinitem dělá, je jednoduchý – sysvinit na dnešní požadavky nestačí.
Pomocí skriptů nemusíte spouštět jen nějaké služby, klidně můžete celý sysvinit nahradit skriptem. Akorát by se to špatně používalo.
Je potřeba rozlišovat dvě věci. Náhrada dvoj-initu sysvinit+rc-* skripty jedním schopnějším initem – o to se snaží víc projektů. Sám jste napsal, že na spouštění služeb není sysvinit vhodný a ani vás nenapadlo používat jej v původní podobě, bez doplnění skripty.
Druhá věc je místo imperativního popisu co jak spustit, zastavit restartovat apod. používat deklarativní popis, který se mnohem snáze kontroluje a vyhodnocuje. Při příležitosti náhrady initu je to dobrá příležitost změnit i tohle. Někomu se to nelíbí, někdo jiný je zase rád. Skripty sice umožňují přizpůsobit se zvláštnostem každého programu, já ale nevidím důvod, proč by se každý program měl startovat jinak, proč by se měl chovat jinak při spuštění z příkazové řádky a ze správce služeb apod. Já třeba některé služby už dávno spouštím pod daemontools od DJB, který k tomu měl podobný přístup. Služba má běžet na popředí, výstupy vypisovat na standardní výstup a běžet s právy, se kterými byla spuštěna. Ukončit se má signálem SIGINT. O logování výstupu, změnu efektivních práv, nastavení limitů, zastavování a spouštění služby se pak má starat správce služeb. Je to pohodlnější pro správu takových služeb, je to dokonce jednodušší i pro programátora takové služby. DJB to řešil skriptem, ale výše uvedené se dá snadno nakonfigurovat i v nějakém konfiguračním souboru.
-
> Sysvinit je nástroj pro spouštění a správu procesů. Není žádný principiální důvod spouštět některé procesy jedním nástrojem a další jiným.
> Důvod, proč se to tak dnes s sysvinitem dělá, je jednoduchý – sysvinit na dnešní požadavky nestačí.Zial, zjavne si pod Sysvinit-om nepredstavujeme obaja to iste (co je mimochodom dost zvlastny ukaz :p) Sysvinit pravdepodobne nikdy k spustaniu sluzieb nesluzil, uz v dobach system5 koncil u /etc/rccosi a gettty. Dovodom bol klasicky KISS princip - je ovela menej nachylne na chyby, ak init spravi len najnutnejsiu inicializaciu a skriptovanie necha na [ba|z|c|t]sh. Krasnou ukazkou toho bol rok 2012 za Archom, kde uspesny boot po update predstavoval dobry dovod otvorit flasku a neuspesny zasa flashku -_-
> Pomocí skriptů nemusíte spouštět jen nějaké služby, klidně můžete celý sysvinit nahradit skriptem. Akorát by se to špatně používalo.
Preco? Arch tak (minimalna binarka initu, *vsetko* ostatne bash) fungoval este minuly rok a nie som jediny, kto tak v pohode funguje dodnes.
> Sám jste napsal, že na spouštění služeb není sysvinit vhodný a ani vás nenapadlo používat jej v původní podobě, bez doplnění skripty.
Kde? :)
-
Filip JirsákStříbrný podporovatel
Co tedy váš sysvinit dělá jiného, než že spouští služby? Můj init má v manuálové stránce hned u názvu napsáno „process control initialization“ a v popisu pak „Init is the parent of all processes. Its primary role is to create processes from a script stored in the file /etc/inittab. This file usually has entries which cause init to spawn gettys on each line that users can log in. It also controls autonomous processes required by any particular system.“
Pokud by jedinou funkcí initu bylo spustit getty pro jednotlivé terminály a pak spustit nějaký další skript, k čemu tam jsou třeba runlevely?
-
Filip JirsákStříbrný podporovatel
Říká to o initu, že je to nástroj na spouštění a správu procesů (dnes se procesům spouštěným při startu většinou říká služby, dříve se jim také často říkalo démoni, podle toho, že běžely na pozadí). Není tam nic o tom, že je to nástroj pro spuštění getty a předání řízení nějakému dalšímu nástroji pro správu procesů.
-
ja (neregistrovaný)
A co ked ${daemon#@} naforkuje child procesy a sam sa ukonci (alebo zhuci)? Ako dokaze init stopnut takuto sluzbu?
Nedokaze. Dokaze to len ten zly zly systemd, ktory jednotlivych demonov oddeli do control groups a ked treba sluzbu zastavit, zastavi vsetko v danej control grupe.
A to je len priklad, kde systemd nieco riesi systemovo, kde sa doteraz pouzivali rozlicne hacky.
-
Filip JirsákStříbrný podporovatel
Spíš systemd standardizuje jeden z hacků. Někteří považují takové chování démonů za chybné už asi 20 let a tvrdí, že správným řešením je oprava takového programu.
-
-
System ma taku chybu hlasit, nie sa snazit riesit ju automaticky. Cize presne to, co robi klasicky rc skript.
Systemd ma tendenciu poziadat sluzbu, aby sa vypla a vzapati zamordovat vsetky jej procesy. Takze ak mi napriklad FTP server hlasi, ze uzivatel backup prave uploaduje a on ho ma zakazane odpajat, pokial doslova serverovna nehori, systemd zahlasi "iste" a zakilluje proces.
-
j (neregistrovaný)
Jen tak pro zajimavost ... dobre 10+let je "ifconfig" jen alias/emulace. Presto v defakto vsech systemech stale je, spousta lidi ho dal nerusene pouziva ... proc asi? Mno protoze zpetna kompatibilita. Tomuhle se da rikat rozumny pristup.
Dtto, v kernelu je hromada funkci, ktere se chovaji chybne, davno maji sveho opraveneho sourozence, ale presto tam porad jsou ... protoze se predpoklada, ze je nejaka appka muze pouzivat prave tim "chybnym" zpusobem. Taky rozumne.
A ted vemem systemd, vyhodime vsechny postupy/nastroje/vlastnosti, idealne ze dne na den a prohlasime jej bohem ... a pak se budem divit, ze na to vsichni nadavaj? lol lol lol.
