Avmystifierar System D.

Varje dag blir våra datorer en allt viktigare del av våra liv; om de har någon form av problem påverkar det vårt humör, vår humor, haha. Självklart är Windows-användare mer benägna att drabbas av panikattacker: virus ( länge leve Linux! ), defragmentering av hårddisken, att hitta och installera Clean Master för PC ( även om vi här i Linux också behöver rengöra systemet; BleachBit är ett av de föredragna alternativen ). På senare tid har vissa Linux-användare upplevt en viss huvudvärk som kallas systemd.

Hur som helst, för att komma till saken, jag har läst en intressant artikel om systemd , vilket verkar vara väldigt populärt nu för tiden.

Systemd , som vissa anser ( och jag använder en väns ord ) vara "en enda ring som styr dem alla "... för andra, som helt enkelt är likgiltiga; så länge datorn fungerar korrekt bryr de sig inte om init gör X eller Y, eller om systemd används. Vad mig beträffar, ja... låt oss bara säga att jag föredrar init; jag tycker det är enklare.

Jag lämnar artikeln här:

Innan jag börjar måste jag säga att jag ogillar starkt beslutet att ändra saker i Debian, men jag har ingen avsikt att överge min älskade spiral. Jag försöker helt enkelt se till att om vi ska diskutera ett ämne, så gör vi det så förberedda som möjligt, även om jag själv inte anser mig vara pro-systemd. För att avmystifiera systemd kommer jag att förlita mig på en webbplats där utvecklare delar med sig av sina perspektiv , vilket jag fick kännedom om genom en kollega som verkar vara pro-systemd, trots att han inte är en Debiananvändare. Med det sagt tror jag att jag kan fortsätta med att försöka avmystifiera vad som sägs om systemd.

systemd är binärt baserat

Kanske är det en av de aspekter som chockar oss mest, om allt är baserat på binär, hur övervakar vi de saker vi brukar göra genom loggar? Jag har ingen aning om hur denna myt föddes, men det är inte helt sant.

systemd konfigureras nästan uteslutande genom vanliga textfiler. Vissa inställningar som också kan ändras med kärnans kommandorad och genom miljövariabler. Det finns inget binärt i din konfiguration (inte ens XML). Bara en enkel, enkel och lättläst textfil.

systemd fans homer simpson

Den saken är monolitisk och den kontrollerar allt

Innan jag kom till ovannämnda webbplats erkänner jag att jag själv tänkte på det här sättet, men efter att ha läst vad dess utvecklare säger har min åsikt förändrat något ...

Om du bygger systemd med alla konfigurationsalternativ aktiverade kommer du att bygga 69 individuella binärfiler . Dessa binärfiler utför olika uppgifter och är noggrant separerade av ett antal anledningar. Till exempel designades systemd med säkerhet i åtanke; därför körs de flesta daemoner med minimala behörigheter (till exempel med hjälp av kärnfunktioner) och ansvarar endast för mycket specifika uppgifter, vilket minimerar deras säkerhetsyta och påverkan. Dessutom parallelliserar systemd uppstart mer än någon tidigare lösning. Denna "parallellisering" skapas genom att köra flera processer parallellt. Det är således tydligt att systemd är mycket väl uppdelat i många binärfiler och följaktligen processer. Faktum är att många av dessa binärfiler är så väl separerade att de är mycket användbara utanför systemd.

Ett paket som innehåller 69 individuella binärfiler kan knappast kallas monolitiskt. Det som skiljer sig från tidigare lösningar är dock att vi levererar fler komponenter i en enda tarball och håller dem sammankopplade i ett enda arkiv med en enhetlig utgivningscykel.

Det ser inte ut som Unix

Det finns verkligen viss sanning. Systemd-källfilerna innehåller inte en enda kodrad från de ursprungliga UNIX-raderna. Men inspiration hämtas från UNIX, och därmed finns det mycket UNIX i systemd. Ett exempel kan vara UNIX-idén "allt är en fil" vilket återspeglas i att i systemd alla tjänster exponeras vid körning i ett kärnfilsystem, c -grupper. Så, en av de ursprungliga funktionerna i UNIX var stöd för flera platser, baserat på inbyggt terminalstöd. Med systemd kom vi med stöd för flera platser naturligt igen, men den här gången med fullt stöd för dagens hårdvara, som täcker grafik, möss, ljud, webbkameror och mer. I själva verket är utformningen av systemd som en serie integrerade verktyg som alla har sina individuella syften men när de används tillsammans är mer än summan av delarna, vilket är mer eller mindre kärnan i UNIX-filosofin. Så sättet vårt projekt hanteras på (dvs. hålla det mesta av operativsystemets kärna i ett enda git-arkiv) är mycket närmare BSD-modellen (som är en sann UNIX, i motsats till Linux) för att få saker gjort (där det mesta av kärnoperativsystemet förvaras i ett enda CVS / SVN-förvar) vilket aldrig var fallet på Linux.

I slutändan betyder frågan om något är UNIX eller inte mycket lite. Eftersom det är tekniskt utmärkt är det knappast unikt för UNIX. För oss är UNIX ett stort inflytande (faktiskt det största), men vi har också andra influenser. Därför kommer systemd att vara mycket UNIX och i andra lite mindre.

Det är väldigt komplicerat ...

Det finns verkligen viss sanning i det. Moderna datorer är komplexa odjur och operativsystemet som körs på dem kommer självklart också att vara så de måste vara komplexa. Systemd är dock inte mer komplicerat än tidigare implementeringar av samma komponenter. Det är enklare och har mindre redundans. Å andra sidan kommer att bygga ett enkelt systemd-baserat operativsystem innebära mycket färre paket än traditionella Linux-användningar. Färre paket gör det lättare att bygga ditt system, det blir av med varandra beroende och mycket av det olika beteendet hos alla inblandade komponenter.

Det låter mig inte använda skalskript

Detta är helt felaktigt. Vi använder dem helt enkelt inte för startprocessen eftersom vi anser att de inte är det bästa verktyget för just det ändamålet, men det betyder inte att systemd var inkompatibelt med dem. Du kan enkelt köra shell-skript som systemd-tjänster eller daemoner; du kan köra skript skrivna på vilket språk som helst som systemd-tjänster eftersom systemd inte bryr sig det minsta om vad som finns inuti din körbara fil. Dessutom använder vi shell-skript i stor utsträckning för våra egna ändamål: för att installera, bygga och testa systemd. Och du kan klistra in skripten i den tidiga startprocessen, använda dem för vanliga tjänster, köra dem i den slutliga avstängningen – det finns praktiskt taget inga gränser.

Vid det här laget antar jag att några av de viktigaste uppfattningarna kan ha klargjorts. Även om jag inte anser mig vara en förespråkare för förändring och har mina reservationer mot idén om " en demon som styr dem alla ", tror jag att i slutändan kommer ingen att våga säga att det inte fungerar alls. Jag känner till och med några användare som märker att med systemd "kör datorn snabbare", men det skulle vara en annan diskussionsfråga. För tillfället kan jag bara bjuda in er att debattera era synpunkter här på init-systemet som många distributioner har anammat, även om de starkaste reaktionerna för närvarande ses inom Debian-gemenskapen, som till och med har skapat en ny fork på grund av allt detta. Huruvida ni gillar det eller inte är en personlig fråga; för min del vill jag bara göra min del för att avmystifiera systemd, som så småningom kommer att finnas i Jessie, nästa stabila version av Debian.

Jag såg artikeln på GUTL (som i sin tur är hämtad från DesdeAbreus )

poettering-1984

Systemström?

Jag är en av dem som inte läser mycket nyheter när något genererar så mycket kontroverser, jag föredrar att stanna kvar vid mer tekniska detaljer. Saken är den…. Ibland känner jag att vissa ämnen slutar vara en rent teknisk diskussion eller debatt, och blir som ett av dessa skvaller 

Först ett öppet utbrott från en användare om systemd som heter systemd VS intelligence , sedan Linus Torvalds som säger att systemd inte är så illa som det framställs ( och han har en poäng ), en fork som heter uselessed ... inga kommentarer ... och för att göra en lång historia kort, slutligen Devuan.

Jag tänker inte säga om det är så illa som de säger, mindre illa eller sämre. Systemet fungerar bra för mig, men personligen skulle jag föredra init, eftersom jag gillar dess sätt att organisera olika saker (som loggar, till exempel). Men hallå, om systemd ska kallas en tävlingshäst och måste ersätta init ( skulle det vara vår arbetshäst, som gör allt utom långsamt? ), ja... så länge förändringen inte är för drastisk, användarna kan anpassa sig utan alltför mycket problem, och systemet fungerar bättre (ja, bättre, kanske det inte räcker för mig!), så välkomna det! 😉


Lägg till som prioriterad källa i Google