Vsak dan postajajo naši računalniki vse pomembnejši del našega življenja; če imajo kakršne koli težave, to vpliva na naše razpoloženje, naš humor, haha. Seveda so uporabniki sistema Windows bolj nagnjeni k napadom panike: virusi ( naj živi Linux! ), defragmentiranje trdega diska, iskanje in namestitev programa Clean Master za računalnik ( čeprav moramo tudi v Linuxu očistiti sistem; BleachBit je ena od prednostnih alternativ ). V zadnjem času so nekateri uporabniki Linuxa imeli določeno težavo, imenovano systemd.
Kakorkoli že, da preidem k bistvu, prebral sem zanimiv članek o systemd , ki je te dni očitno zelo priljubljen.
Systemd , ki ga nekateri ( in uporabil bom besede prijatelja ) smatrajo za "en sam obroč, ki vlada vsem " ... za druge, ki so preprosto brezbrižni; dokler računalnik deluje pravilno, jih ne zanima, ali init izvede X ali Y ali ali se uporablja systemd. Kar se mene tiče, no ... recimo le, da imam raje init; zdi se mi preprostejši.
Članek pustim tukaj:
Preden začnem, moram povedati, da mi odločitev o spremembah v Debianu močno ni všeč, vendar nimam namena opustiti svoje ljubljene spirale. Preprosto poskušam zagotoviti, da če se bomo že pogovarjali o neki temi, to storimo čim bolj pripravljeni, čeprav se sam ne smatram za zagovornika systemda. Da bi demistificiral systemd, se bom zanesel na spletno stran, kjer razvijalci delijo svoja stališča , kar sem opazil prek kolega, ki se zdi zagovornik systemda, čeprav ni uporabnik Debiana. Glede na to mislim, da lahko nadaljujem z demistifikacijo tega, kar se govori o systemdu.
systemd temelji na binarni datoteki
Morda je to eden izmed vidikov, ki nas najbolj šokira, če pa vse temelji na binarnosti, kako nadzirati stvari, ki jih običajno počnemo prek dnevnikov? Pojma nimam, kako se je rodil ta mit, vendar ni povsem resničen.
systemd je konfiguriran skoraj izključno prek navadnih besedilnih datotek. Nekatere nastavitve, ki jih je mogoče spremeniti tudi z ukazno vrstico jedra in s spremenljivkami okolja. V vaši konfiguraciji ni nič binarnega (niti XML). Preprosta, preprosta in lahko berljiva besedilna datoteka.
Ta stvar je monolitna in nadzoruje vse
Preden sem prišel na zgoraj omenjeno spletno stran, priznam, da sem tudi sam razmišljal tako, toda po branju tega, kar pravijo njegovi razvijalci, je moje mnenje nekaj spremenilo ...
Če zgradite systemd z vsemi omogočenimi možnostmi konfiguracije, boste zgradili 69 posameznih binarnih datotek . Te binarne datoteke služijo različnim nalogam in so skrbno ločene iz več razlogov. Systemd je bil na primer zasnovan z mislijo na varnost; zato večina demonov deluje z minimalnimi privilegiji (na primer z uporabo zmogljivosti jedra) in so odgovorni le za zelo specifične naloge, kar zmanjšuje njihovo varnostno površino in vpliv. Poleg tega systemd vzporedno zaganja zagon bolj kot katera koli prejšnja rešitev. Ta "vzporednost" nastane z vzporednim izvajanjem več procesov . Tako je jasno, da je systemd zelo dobro razdeljen na številne binarne datoteke in posledično procese. Pravzaprav so mnoge od teh binarnih datotek tako dobro ločene, da so zelo uporabne zunaj systemd.
Paket, ki vsebuje 69 posameznih binarnih datotek, bi težko imenovali monoliten. Kar pa se od prejšnjih rešitev razlikuje, je to, da pošiljamo več komponent v eni sami tarball datoteki in jih hranimo povezane v enem samem repozitoriju z enotnim ciklom izdajanja.
To ni videti kot Unix
V tem je gotovo nekaj resnice. Izvorne datoteke systemd ne vsebujejo niti ene vrstice kode iz prvotnih vrstic UNIX. Vendar navdih izhaja iz UNIX-a, zato je v sistemu UNIX veliko UNIX-a. Primer bi lahko bila ideja UNIX "vse je datoteka", ki se odraža v tem, da so v sistemu systemd vse storitve izpostavljene med izvajanjem v datotečnem sistemu jedra, cgroupfs. Ena od prvotnih lastnosti UNIX-a je bila torej podpora za več sedežev, ki temelji na vgrajeni podpori terminalov. S sistemom systemd smo znova vgradili podporo za več sedežev, a tokrat s popolno podporo za današnjo strojno opremo, ki zajema grafiko, miši, zvok, spletne kamere in še več. Dejansko je zasnova systemd kot zbirke integriranih orodij, ki imajo vsak svoj namen, vendar kadar se uporabljajo skupaj, več kot vsota delov, kar je bolj ali manj v središču filozofije UNIX. Način ravnanja z našim projektom (tj. Ohranjanje večine jedra OS v enem samem git-repozitoriju) je veliko bližje modelu BSD (ki je pravi UNIX, v nasprotju z Linuxom), da se stvari opravijo (kjer je večina jedra operacijski sistem je shranjen v enem skladišču CVS / SVN), kar v Linuxu ni bilo nikoli.
Na koncu je vprašanje, ali je nekaj UNIX ali ne, zelo malo. Ker je tehnično odličen, je komaj edinstven za UNIX. Za nas ima UNIX velik vpliv (pravzaprav največji), imamo pa tudi druge vplive. Zato bo na nekaterih področjih systemd zelo UNIX, na drugih pa malo manj.
To je zelo zapleteno ...
V tem je gotovo nekaj resnice. Sodobni računalniki so zapletene zveri in operacijski sistem, ki deluje na njih, bo očitno preveč, zato morajo biti zapleteni. Vendar systemd zagotovo ni nič bolj zapleten kot prejšnje izvedbe istih komponent. Je preprostejša in ima manj odvečnosti. Po drugi strani pa bo gradnja preprostega sistemskega operacijskega sistema vključevala veliko manj paketov kot običajna uporaba Linuxa. Manj paketov olajša gradnjo vašega sistema, znebi se soodvisnosti in večjega števila različnih vedenj vseh vpletenih komponent.
To mi ne dovoljuje uporabe skriptov lupine
To je popolnoma napačno. Preprosto jih ne uporabljamo za postopek zagona, ker menimo, da niso najboljše orodje za ta poseben namen, vendar to ne pomeni, da systemd ni bil združljiv z njimi. Skripte lupine lahko preprosto zaženete kot storitve ali demone systemd; skripte, napisane v katerem koli jeziku, lahko zaženete kot storitve systemd, saj systemd sploh ne zanima, kaj je v vaši izvedljivi datoteki. Poleg tega skripte lupine pogosto uporabljamo za lastne namene: za namestitev, gradnjo in testiranje systemd. Skripte lahko prilepite v postopek zgodnjega zagona, jih uporabite za običajne storitve, jih zaženete ob končni zaustavitvi – praktično ni omejitev.
Na tej točki predvidevam, da so nekatera glavna prepričanja morda pojasnjena. Čeprav se ne smatram za zagovornika sprememb in imam pomisleke glede ideje o " enem demonu, ki bi vladal vsem ", mislim, da si na koncu nihče ne bo upal reči, da sploh ne deluje. Poznam celo nekaj uporabnikov, ki opažajo, da s systemd "računalnik deluje hitreje", vendar bi to bila druga tema za razpravo. Zaenkrat vas lahko le povabim, da tukaj razpravljate o svojih stališčih o sistemu init, ki ga je sprejelo veliko distribucij, čeprav se najmočnejše reakcije trenutno pojavljajo v skupnosti Debian, ki je zaradi vsega tega celo ustvarila novo vejo. Ali vam je všeč ali ne, je osebna stvar; jaz pa želim le prispevati svoj delež k demistifikaciji systemd, ki bo na koncu prisoten v Jessieju, naslednji stabilni različici Debiana.
Videl sem članek o GUTL (ki je bil posledično vzet iz DesdeAbreusa ).
Sistemski tok?
Sem eden tistih, ki ne bere veliko novic, ko nekaj povzroči toliko polemike, raje ostanem pri bolj tehničnih podrobnostih. Stvar je v tem.... Včasih se mi zdi, da nekatere teme niso več zgolj tehnična razprava ali razprava in postanejo kot eden od tistih tračev iz estrade
Najprej odkrita tirada uporabnika o systemd-u z naslovom systemd VS intelligence , nato Linus Torvalds, ki pravi, da systemd ni tako slab , kot ga prikazujejo ( in ima prav ), fork z naslovom useledd ... brez komentarjev ... in da skrajšam dolgo zgodbo, končno Devuan.
Ne bom rekel, ali je tako slabo, kot pravijo, manj slabo ali še slabše. Sistem mi deluje v redu, vendar bi osebno raje imel init, saj mi je všeč njegov način organiziranja različnih stvari (na primer dnevnikov). Ampak hej, če se bo systemd imenoval dirkalni konj in bo moral nadomestiti init ( bi bil naš delovni konj, ki bi počel vse, a počasi? ), no ... dokler sprememba ni preveč drastična, se lahko uporabniki prilagodijo brez večjih težav in sistem deluje bolje (ja, bolje, morda to ne bo dovolj zame!), potem jo pozdravljam! 😉