Každý deň sa naše počítače stávajú čoraz dôležitejšou súčasťou našich životov; ak majú nejaký problém, ovplyvňuje to našu náladu, náš humor, haha. Používatelia Windowsu sú samozrejme náchylnejší na záchvaty paniky: vírusy ( nech žije Linux! ), defragmentácia HDD, nájdenie a inštalácia Clean Masteru pre PC ( hoci aj tu v Linuxe potrebujeme vyčistiť systém; BleachBit je jednou z preferovaných alternatív ). V poslednej dobe niektorí používatelia Linuxu zažívajú určitý problém s názvom systemd.
Aby som sa dostal k veci, čítal som zaujímavý článok o systemd , ktorý je v poslednej dobe veľmi populárny.
Systemd , ktorý niektorí považujú ( a použijem slová kamaráta ) za „jeden prsteň, ktorý vládne všetkým “... pre iných, ktorým je to jednoducho ľahostajné; pokiaľ počítač funguje správne, je im jedno, či init vykoná X alebo Y, alebo či sa použije systemd. Čo sa mňa týka, no... povedzme, že uprednostňujem init; považujem ho za jednoduchší.
Článok nechávam tu:
Predtým, ako začnem, musím povedať, že sa mi rozhodne nepáči rozhodnutie zmeniť veci v Debiane, ale nemám v úmysle opustiť svoju milovanú špirálu. Snažím sa len zabezpečiť, aby sme v prípade diskusie o nejakej téme boli čo najlepšie pripravení, aj keď sa sám nepovažujem za zástancu systemd. Aby som demystifikoval systemd, spoľahnem sa na webovú stránku, kde vývojári zdieľajú svoje názory , o ktorých som sa dozvedel prostredníctvom kolegu, ktorý sa zdá byť zástancom systemd, aj keď nie je používateľom Debianu. S ohľadom na to si myslím, že môžem pokračovať v pokuse o demystifikáciu toho, čo sa o systemd hovorí.
systemd je binárny
Možno je to jeden z aspektov, ktoré nás najviac šokujú, ak je všetko založené na binárnych súboroch, ako monitorujeme veci, ktoré zvyčajne robíme, pomocou protokolov? Netuším, ako sa tento mýtus zrodil, ale nie je to úplne pravda.
systemd sa konfiguruje takmer výlučne prostredníctvom súborov vo formáte obyčajného textu. Niektoré nastavenia, ktoré je možné zmeniť aj pomocou príkazového riadku jadra a prostredníctvom premenných prostredia. Vo vašej konfigurácii nie je nič binárne (ani XML). Iba jednoduchý, priamy a ľahko čitateľný textový súbor.
Tá vec je monolitická a ovláda všetko
Predtým, ako som sa dostal na spomínaný web, priznám sa, že som to takto myslel aj ja, ale po prečítaní, čo hovoria jeho vývojári, môj názor niečo zmenil ...
Ak zostavíte systemd so všetkými povolenými možnosťami konfigurácie, zostavíte 69 samostatných binárnych súborov . Tieto binárne súbory slúžia rôznym úlohám a sú starostlivo oddelené z niekoľkých dôvodov. Napríklad systemd bol navrhnutý s ohľadom na bezpečnosť; preto väčšina démonov beží s minimálnymi privilégiami (napríklad s využitím možností jadra) a je zodpovedná iba za veľmi špecifické úlohy, čím sa minimalizuje ich bezpečnostný povrch a vplyv. Systemd tiež paralelizuje bootovanie viac ako akékoľvek predchádzajúce riešenie. Táto „paralelizácia“ sa vytvára paralelným spustením viacerých procesov . Je teda zrejmé, že systemd je veľmi dobre rozdelený do mnohých binárnych súborov a následne aj procesov. V skutočnosti sú mnohé z týchto binárnych súborov tak dobre oddelené, že sú veľmi užitočné aj mimo systemd.
Balík obsahujúci 69 jednotlivých binárnych súborov by sa len ťažko dal nazvať monolitickým. Od predchádzajúcich riešení sa však líši tým, že dodávame viac komponentov v jednom tarballe a uchovávame ich zreťazené v jednom repozitári s jednotným cyklom vydávania.
To nevyzerá ako Unix
Určite na tom niečo pravdy je. Zdrojové súbory systemd neobsahujú jediný riadok kódu z pôvodných riadkov systému UNIX. Inšpirácia je však odvodená od systému UNIX, a preto je v systéme systemd veľa systému UNIX. Príkladom môže byť myšlienka systému UNIX „všetko je súbor“, ktorá sa odráža v tom, že v systéme systemd sú všetky služby vystavené za behu systému súborov jadra, cgroupfs. Jednou z pôvodných funkcií systému UNIX bola teda podpora viacerých sedadiel založená na zabudovanej podpore terminálu. So systémom systemd sme opäť natívne priniesli podporu viacerých sedadiel, tentokrát však s plnou podporou dnešného hardvéru pokrývajúcou grafiku, myši, zvuk, webové kamery a ďalšie. V skutočnosti je návrh systemd ako súboru integrovaných nástrojov, z ktorých každý má svoje individuálne účely, ale keď sa používajú spoločne, viac ako súčet častí, ktorý je viac-menej jadrom filozofie UNIX. Takže spôsob, akým je náš projekt riešený (t. J. Udržiavanie väčšiny jadra operačného systému v jednom úložisku git), je oveľa bližšie k modelu BSD (čo je na rozdiel od Linuxu skutočný UNIX, na rozdiel od Linuxu), vďaka ktorým je možné robiť veci (kde väčšina základný operačný systém je uložený v jednom úložisku CVS / SVN), čo v prípade systému Linux nikdy nebolo.
Nakoniec záleží na tom, či je niečo UNIX alebo nie, veľmi málo. Pretože je technicky vynikajúci, je pre UNIX ťažko jedinečný. Pre nás je UNIX dôležitý vplyv (v skutočnosti najväčší), ale máme aj ďalšie vplyvy. Preto v niektorých oblastiach bude systemd veľmi UNIX, v iných o niečo menej.
To je veľmi zložité ...
Určite na tom niečo pravdy je. Moderné počítače sú zložité zvieratá a operačný systém, ktorý na nich beží, zjavne tiež bude, takže musia byť zložité. Systemd však určite nie je zložitejší ako predchádzajúce implementácie rovnakých komponentov. Je to jednoduchšie a má menšiu nadbytočnosť. Na druhej strane, vybudovanie jednoduchého operačného systému založeného na systémoch bude vyžadovať oveľa menej balíkov ako tradičné Linuxy. Menej balíkov uľahčuje zostavenie vášho systému, zbavuje sa vzájomných závislostí a veľa rozdielneho správania všetkých zúčastnených komponentov.
To mi nedovolí používať shell skripty
Toto je úplne nesprávne. Jednoducho ich nepoužívame na proces zavádzania, pretože si myslíme, že nie sú najlepším nástrojom na tento konkrétny účel, ale to neznamená, že systemd s nimi nebol kompatibilný. Shellové skripty môžete jednoducho spúšťať ako služby alebo démony systemd; skripty napísané v akomkoľvek jazyku môžete spúšťať ako služby systemd, pretože systemd sa vôbec nestará o to, čo je vo vašom spustiteľnom súbore. Navyše, shellové skripty hojne používame na vlastné účely: na inštaláciu, zostavovanie a testovanie systemd. A skripty môžete vložiť do procesu skorého spustenia, použiť ich pre bežné služby, spustiť ich pri konečnom vypnutí – prakticky neexistujú žiadne obmedzenia.
V tomto bode predpokladám, že niektoré z hlavných presvedčení boli objasnené. Hoci sa nepovažujem za zástancu zmien a mám výhrady k myšlienke „ jedného démona, ktorý vládne všetkým “, myslím si, že nakoniec sa nikto neodváži povedať, že to vôbec nefunguje. Dokonca poznám niektorých používateľov, ktorí si všimli, že so systemd „beží počítač rýchlejšie“, ale to by bola iná téma na diskusiu. Zatiaľ vás môžem len pozvať, aby ste tu diskutovali o svojich názoroch na systém init, ktorý prijalo mnoho distribúcií, hoci najsilnejšie reakcie sa v súčasnosti prejavujú v komunite Debianu, ktorá kvôli tomu všetkému dokonca vytvorila nový fork. Či sa vám to páči alebo nie, je to vaša osobná vec; ja chcem len prispieť svojou troškou k demystifikácii systemd, ktorý bude nakoniec prítomný v Jessie, ďalšej stabilnej verzii Debianu.
Videl som článok o GUTL (ktorý bol prevzatý z DesdeAbreus )
Systemd aktualny?
Som z tých, ktorí nečítajú veľa správ, keď niečo vyvoláva toľko kontroverzií, radšej zostanem pri technickejších detailoch. Vec sa má…. Niekedy mám pocit, že niektoré témy prestávajú byť čisto technickou diskusiou alebo debatou a stávajú sa ako jedna z tých šoubiznisových klebiet
Najprv otvorená tiráda od používateľa o systemd s názvom systemd VS intelligence , potom Linus Torvalds, ktorý povedal, že systemd nie je taký zlý , ako sa o ňom hovorí ( a má pravdu ), fork s názvom useledd ... žiadne komentáre... a aby som to skrátil, nakoniec Devuan.
Nepoviem, či je to také zlé, ako sa hovorí, menej zlé alebo horšie. Systém pre mňa funguje dobre, osobne by som však uprednostnil init, pretože sa mi páči jeho spôsob organizácie rôznych vecí (napríklad protokolov). Ale ak sa systemd bude nazývať dostihovým koňom a bude musieť nahradiť init ( bol by naším ťažným koňom, ktorý robí všetko, ale pomaly? ), no... pokiaľ zmena nebude príliš drastická, používatelia sa môžu prispôsobiť bez väčších problémov a systém bude fungovať lepšie (áno, lepšie, možno mi to nebude stačiť!), tak ju vítam! 😉