Hver dag blir datamaskinene våre en stadig viktigere del av livene våre. Hvis de har noen form for problemer, påvirker det humøret vårt og humoren vår, haha. Windows-brukere er selvfølgelig mer utsatt for panikkanfall: virus ( lenge leve Linux! ), defragmentering av harddisken, å finne og installere Clean Master for PC ( selv om vi her i Linux også må rense systemet; BleachBit er et av de foretrukne alternativene ). I det siste har noen Linux-brukere opplevd en viss hodepine som kalles systemd.
Uansett, for å komme til poenget, har jeg lest en interessant artikkel om systemd , som ser ut til å være veldig populært for tiden.
Systemd , som noen anser ( og jeg bruker en venns ord ) for å være «én ring som styrer dem alle »... for andre, som rett og slett er likegyldige; så lenge datamaskinen fungerer som den skal, bryr de seg ikke om init gjør X eller Y, eller om systemd brukes. Når det gjelder meg, vel... la oss bare si at jeg foretrekker init; jeg synes det er enklere.
Jeg legger igjen artikkelen her:
Før jeg begynner, må jeg si at jeg misliker sterkt avgjørelsen om å endre ting i Debian, men jeg har ingen intensjon om å forlate min elskede spiral. Jeg prøver bare å sørge for at hvis vi skal diskutere et emne, gjør vi det så forberedt som mulig, selv om jeg selv ikke anser meg selv som pro-systemd. For å avmystifisere systemd, vil jeg stole på en nettside der utviklere deler sine perspektiver , som jeg ble oppmerksom på gjennom en kollega som ser ut til å være pro-systemd, selv om han ikke er en Debian-bruker. Når det er sagt, tror jeg at jeg kan fortsette med å prøve å avmystifisere hva som blir sagt om systemd.
systemd er binærbasert
Kanskje dette er en av aspektene som sjokkerer oss mest, hvis alt er basert på binær, hvordan overvåker vi de tingene vi vanligvis gjør gjennom logger? Jeg aner ikke hvordan denne myten ble født, men det er ikke helt sant.
systemd er konfigurert nesten utelukkende gjennom vanlige tekstfiler. Noen innstillinger som også kan endres med kjernekommandolinjen og gjennom miljøvariabler. Det er ikke noe binært i konfigurasjonen din (ikke engang XML). Bare en enkel, grei og lettlest tekstfil.
Den tingen er monolitisk og kontrollerer alt
Før jeg kom til det nevnte nettstedet, innrømmer jeg at jeg selv tenkte på denne måten, men etter å ha lest hva utviklerne sier, har min mening endret noe ...
Hvis du bygger systemd med alle konfigurasjonsalternativer aktivert, vil du bygge 69 individuelle binærfiler . Disse binærfilene utfører forskjellige oppgaver og er nøye atskilt av en rekke årsaker. For eksempel ble systemd designet med sikkerhet i tankene; derfor kjører de fleste daemoner med minimale rettigheter (for eksempel ved bruk av kjernefunksjoner) og er kun ansvarlige for svært spesifikke oppgaver, noe som minimerer sikkerhetsoverflaten og påvirkningen. Systemd parallelliserer også oppstart mer enn noen tidligere løsning. Denne "parallelliseringen" skapes ved å kjøre flere prosesser parallelt. Dermed er det tydelig at systemd er veldig godt delt inn i mange binærfiler og følgelig prosesser. Faktisk er mange av disse binærfilene så godt atskilt at de er veldig nyttige utenfor systemd.
En pakke som inneholder 69 individuelle binærfiler kan knapt kalles monolittisk. Det som imidlertid er forskjellig fra tidligere løsninger, er at vi sender flere komponenter i en enkelt tarball og holder dem lenket sammen i et enkelt arkiv med en enhetlig utgivelsessyklus.
Det ser ikke ut som Unix
Det er absolutt noe sannhet i det. Systemd-kildefilene inneholder ikke en eneste kodelinje fra de originale UNIX-linjene. Imidlertid er inspirasjon hentet fra UNIX, og dermed er det mye UNIX i systemd. Et eksempel vil være UNIX-ideen "alt er en fil" som gjenspeiles i at i systemd blir alle tjenester eksponert i løpet av et kjernefilsystem, cgrupper. Så en av de originale egenskapene til UNIX var støtte for flere seter, basert på innebygd terminalstøtte. Med systemd fikk vi støtte fra flere seter innfødt igjen, men denne gangen med full støtte for dagens maskinvare, som dekker grafikk, mus, lyd, webkameraer og mer. Faktisk er utformingen av systemd som en serie integrerte verktøy som hver har sine individuelle formål, men når de brukes sammen, er mer enn summen av delene, som er mer eller mindre i sentrum for UNIX-filosofien. Så måten prosjektet vårt håndteres på (dvs. å beholde det meste av operativsystemkjernen i et enkelt git-arkiv) er mye nærmere BSD-modellen (som er en sann UNIX, i motsetning til Linux) for å få ting gjort (hvor det meste av kjerneoperativsystemet oppbevares i et enkelt CVS / SVN-lager), noe som aldri var tilfelle på Linux.
Til slutt, spørsmålet om noe er UNIX eller ikke betyr veldig lite. Å være teknisk utmerket er det neppe unikt for UNIX. For oss er UNIX en stor innflytelse (faktisk den største), men vi har også andre påvirkninger. Derfor vil systemd være veldig UNIX, og i andre litt mindre.
Det er veldig komplisert ...
Det er absolutt noe sannhet i det. Moderne datamaskiner er komplekse dyr, og operativsystemet som kjører på dem vil selvsagt også være det, så de må være komplekse. Imidlertid er systemd absolutt ikke mer komplisert enn tidligere implementeringer av de samme komponentene. Det er enklere, og har mindre redundans. På den annen side vil bygging av et enkelt systemd-basert operativsystem innebære langt færre pakker enn tradisjonell Linux-bruk. Færre pakker gjør det lettere å bygge systemet ditt, det blir kvitt gjensidig avhengighet og mye av den forskjellige oppførselen til alle involverte komponenter.
Det lar meg ikke bruke skallskript
Dette er fullstendig feil. Vi bruker dem rett og slett ikke til oppstartsprosessen fordi vi mener de ikke er det beste verktøyet for det spesifikke formålet, men det betyr ikke at systemd var inkompatibelt med dem. Du kan enkelt kjøre skallskript som systemd-tjenester eller daemoner; du kan kjøre skript skrevet på hvilket som helst språk som systemd-tjenester siden systemd ikke bryr seg det minste om hva som er inni den kjørbare filen din. Dessuten bruker vi skallskript i stor grad til våre egne formål: for å installere, bygge og teste systemd. Og du kan lime inn skriptene i den tidlige oppstartsprosessen, bruke dem til normale tjenester, kjøre dem i den endelige avslutningen – det er praktisk talt ingen grenser.
På dette tidspunktet antar jeg at noen av hovedoppfatningene kan ha blitt avklart. Selv om jeg ikke anser meg selv som en forkjemper for endring og har mine reservasjoner mot ideen om " én demon som skal herske over dem alle ", tror jeg at til slutt vil ingen tørre å si at det ikke fungerer i det hele tatt. Jeg kjenner til og med noen brukere som legger merke til at med systemd "kjører PC-en raskere", men det ville være en annen sak å diskutere. Foreløpig kan jeg bare invitere deg til å diskutere dine synspunkter her om init-systemet som mange distribusjoner har tatt i bruk, selv om de sterkeste reaksjonene for tiden sees i Debian-fellesskapet, som til og med har skapt en ny fork på grunn av alt dette. Om du liker det eller ikke er en personlig sak; for min del vil jeg bare gjøre mitt for å avmystifisere systemd, som til slutt vil være tilstede i Jessie, den neste stabile versjonen av Debian.
Jeg så artikkelen på GUTL (som igjen var hentet fra DesdeAbreus )
Systemd gjeldende?
Jeg er en av dem som ikke leser mye nyheter når noe genererer så mye kontrovers, jeg foretrekker å holde meg med mer tekniske detaljer. Saken er…. Noen ganger føler jeg at visse emner slutter å være en rent teknisk diskusjon eller debatt, og blir som en av de showbiz-sladderene
Først en åpen tirade fra en bruker om systemd kalt systemd VS intelligence , deretter Linus Torvalds som sier at systemd ikke er så ille som det fremstilles som ( og han har et poeng ), en fork kalt uselessed ... ingen kommentarer ... og for å gjøre en lang historie kort, til slutt Devuan.
Jeg vil ikke si om det er så ille som de sier, mindre ille eller verre. Systemet fungerer fint for meg, men personlig ville jeg foretrukket init, siden jeg liker måten det organiserer forskjellige ting på (som logger, for eksempel). Men hei, hvis systemd skal kalles en veddeløpshest og må erstatte init ( ville det være arbeidshesten vår, som gjør alt annet enn sakte? ), vel ... så lenge endringen ikke er for drastisk, brukerne kan tilpasse seg uten for mye problemer, og systemet fungerer bedre (ja, bedre, kanskje det ikke er nok for meg!), så velkommen det! 😉