Avmystifisere System D.

@xiep Jeg kan ikke være mer enig i kommentaren din.

@juanfgs du virker den eneste som leser, i alle fall heier jeg deg for det, men du må lese noe veldig viktig som er i kommentaren min, det spiller ingen rolle jeg legger det her:

»NIH Hvor? Det ser ut til at gode gamle Lennart liker å troll og stort. "

Jeg tror ikke han skrev det av en uskyldig grunn, han var klar over det faktum at det var nok en Lennart-vits for aprilens tulledag (dårlig humør), samt hans lidenskap for å konvertere /, / etc og alt annet til / Linux. 🙂

PS: Takk, men jeg trenger ikke å øve meg på engelsk, jeg har brukt språket siden jeg var 6 år gammel
aaahh og alt annet er sant, bekreft det 🙂

@juanfgs, jeg tar deg med ordet ditt spesielt om dette:

«Og realiteten er at det meste av antisystemet ikke består denne testen, selv om det er en håndfull mennesker som av en eller annen grunn VET MER enn menneskene bak: Debian, Fedora, Archlinux, Linux-kjernen, hele GNOME-prosjektet Sannsynligvis også KDE-prosjektet siden de ikke har klaget på systemd, SUSE, og lenge osv.

Allikevel er hans giftige og glitrende tale det eneste han oppnår, å skape splittelse, problemer og andre. Slikt er poenget at jeg ikke kan vente på at de endelig bytter til BSD ettersom de har truet fra Xorg, NetworkManager, PulseAudio, og jeg vet ikke om på grunn av ren teknisk uvitenhet eller fordi de ikke ville klage på det. "

Så I OVERENSSTEMMELSE med deg er vi alle anti-systemd giftige og vitrioliske at det eneste vi oppnår er uenighet, problemer og så videre. La meg fortelle deg at det er den største forargelsen jeg har vært i stand til å lese rundt her. Jeg vet ikke hvorfor pro-systemet bryr seg når strukturelle problemer i et system blir brakt i lys, noe som åpenbart vil påvirke dem på et eller annet tidspunkt, fordi ingenting kan ha skjedd med dem nå, men på et tidspunkt vil de. det vil, og så vil noen anti-systemd minne dem om ordene de sa mange ganger, og ingen stoppet dem, og kanskje noen andre anti-systemd vil gi dem en hånd.

Personlig liker jeg ikke systemd, men det betyr ikke at jeg ikke bruker init, det må jeg, for nettopp i jobben min hvis jeg skal ta på en maskin med den init må jeg ha kunnskap om hvordan jeg skal håndtere den. Personlig har jeg også brukt det siden jeg kom til Archlinux og til og med i Debian og Gentoo, så ikke fortell meg at synet mitt er partisk ved å ikke bruke systemd, jeg har brukt det, og jeg vet hvor lat det er. , og om jeg må hjelpe noen her på forumet DesdeLinux eller på IRC eller Debian-listen (som er den distroen hvor jeg har vært lengst og jeg fortsatt bruker den i arbeidet mitt) vil jeg gjerne gjøre det, for nettopp hvis det er noe jeg liker med Linux-fellesskapet, er det at til tross for forskjellen er det alltid hjelp.

Nå for å bytte til BSD, er det mulig, men jeg vil bare gjøre det hvis systemd blir noe så virulent at det ikke tillater meg å bruke noe annet alternativ, i mellomtiden holder jeg meg på Linux, og deaktiverer all den galskapen, inkludert mange av Cgroups-tingene .

Glibc har sine feil ingen kan skjule dem, det er store Glibc-feil som påvirker kjernen og hundrevis av kjørbare filer. Forskjellen mellom Glibc og systemd er at førstnevnte er en base hvorfra tusenvis av programvareprosjekter kan omdannes til binærfiler, mens systemd er en init, hvis formål er å være et stabilt, bevist og praktisk talt ufeilbarlig stykke. Ikke bare det, Glibc må tilpasse seg hundrevis av forskjellige maskinvarearkitekturer (CPUer), til forskjellige optimaliseringsflagg og unike egenskaper ved CPUen, til forskjellige former for programvareoptimalisering, et mye mer anstrengende og vanskelig arbeid enn systemd også. Jeg ser egentlig ikke noen måte å presentere en sammenligning mellom de to prosjektene i samme skala.

Det samme gjelder GCC, GCC er en kompilator som for øvrig støtter mange språk (totalt 13 teller de uoffisielle), og har egenskaper som ligner på Glibc, som støtter mange arkitekturer (70 arkitekturer for versjon 4.9), binær optimalisering flagg, CPU-optimaliseringsflagg og mange andre funksjoner. Nå er de på samme vanskelighetsgrad, en kompilator med en init. Svaret er mer enn åpenbart, og begynner med at systemd er i C, og mye av GCC-koden er i assembler, eller du må bruke assembler for å få ting til å fungere i binær, noe som er litt vanskelig å gjøre.

Hva er galt med GCC og Glibc? Klar. Selv Linus har gitt dem sitt angrep, men i GCC og Glibc har de noe positivt at i systemd blir de ofte glemt, og det vil si en feil rapportert, en feil sett, en feil løst.

Dessuten glemmer ingen at Kay Sievers ikke bare brøt kjernen cmdline, men ønsket å holde kjeft, tross alt "generisk er generisk".

Jeg tror du leste og analyserte feil (det er viktig å analysere), eller du bare ikke engang ga deg selv en sjanse til å gjøre det. At to prosesser overfører informasjon er ikke en grunn til at et system går i stykker, men når du har binærfiler med dynamisk handling som nettverkskontroll, logger eller coredump, som sender informasjon direkte til init, kan ting gå galt og de vil gå galt, fordi hvis noen av binærfiler brytes, er sjansene for å bryte resten mye høyere, og det er ganske realistisk, og det har skjedd, kjernen cmdline krasjer nylig, ACPI-problemene som Nvidia Devs hadde takket være systemd-212, alt det er en prøve av det jeg sier.

@anonym, jeg vil bare se hvordan TTY-problemet vil utvikle seg i Linux. Når CONFIG_VT-koden kommer ut, til fordel for å dele VT i to godt differensierte deler (kjerneområde og brukerområde), trenger vi noe verktøy for å kontrollere VT-ene fra brukerområdet, og der kan systemd-trøstes spille i å være en sterk avhengighet som trekker resten av distroene til nødvendigheten av å måtte installere systemd-komponentene, bare for å gjøre det mulig for systemet å fungere. Det jeg sier er ikke en overdrivelse, det er en veldig, veldig stor mulighet og veldig bekymringsfull. Det er andre prosjekter, som KMSCon, men hvis de fleste stasjonære maskiner og distroer går til fordel for systemd, kan ting som KMSCon dø raskere enn mange tror.

@anonymt er spørsmålet at fjerning av CONFIG_VT er noe som til slutt vil være totalt (fra det jeg har lest), det vil si at i kjernen vil bare primitivene være igjen, mens resten av verktøyene vil være i brukerområdet, dette er ikke dårlig, tvert imot, det vil fjerne mye gammel kode fra kjernen, gjøre det lettere å vedlikeholde og mye mer konfigurerbar (full KMS / DRM-støtte for konsoll). Gjerne i begynnelsen vil det være begge systemene, men på lang sikt (15-20 utgivelser) vil det muligens gå ut av kjernen, eller enda tidligere, mange verktøy støtter ikke lenger slik kode til fordel for nyere og bedre støttet kode.

Nå sier du at hvis systemd gjør det, fordi 50 flere ikke kan gjøre det (jeg forestiller meg 50 flere applikasjoner). Vel, hvis vi ser de sterke avhengighetene til KMSCon (det eldste prosjektet i denne forstand), er de libudev (kode som snart blir koblet til systemd, den støttes ikke og vil komme i konflikt med systemd hvis den fungerer alene), libdrm , libxkbcommon, libtsm og systemd for å håndtere multisete, så når du ser dette, innser du hvordan ting tar form i å ta for seg mange verktøy som er nødvendige for at et GNU / Linux OS skal fungere uten problemer.

@ anonym, absolutt det du sier er den andre muligheten, eudev vil ta større styrke i denne forbindelse og vil holde alternativene åpne for å velge forskjellige verktøy.

PS: Som du sier, det ville være interessant å se hvordan VTs tar fordelene av KMS / DRM sammen med fbdev 😀

@dariem forklarte på en enkel måte for å se om du fikk ideen:

Det du sier er absolutt atferden som alltid forventes fra modulære programmer og prosesser. Modularitet ble implementert for det formålet, det å skille to prosesser og at de okkuperer sine egne hukommelsesrom, og at de kommuniserer på noen måter (IPC, etc.), slik at i tilfelle noe går galt, skjer det ikke noe dårlig. Og systemet kan fortsette å fungere uten avbrudd. En teori som absolutt har hatt stor støtte på grunn av potensialet og den enorme marginen for pålitelighet som den har gitt til dagens databehandling. Dette er ikke alltid sant (livet er ikke alltid vakkert), og jeg tror du sikkert har vært et offer for disse hendelsene ved en eller annen anledning (dette gjelder sikkert for alle uansett operativsystem du bruker), og jeg vil gi et par eksempler.

Den første går med Xorg (som er en modulær prosess akkurat som systemd), som noen ganger blir gal med en driver og bare krasjer og etterlater deg uten grafikk, mens resten av systemet fortsetter å fungere som forventet (Blessed modularity 😀). Så langt så bra fungerer teorien vår om at modulære prosesser ikke trenger å bryte systemet. Men (det er alltid noe men) noen ganger gir Xorg noe mer enn galskap og av en eller annen merkelig grunn (som kan variere fra musekontroll til grafikkdriver), krasjer ikke bare Xorg, men det gir deg også det vakreste av kjernepanikken (og en graffiti på skjermen som Picasso) som du kan forestille deg, og så innser du at uansett hvor modulær den er, hvis en prosess kommuniserer og utveksler informasjon / data med en annen, og noe går galt i en av dem, og av en eller annen grunn, kan ikke feilen håndteres riktig, sjansene for at de aktuelle prosessene blir berørt øker, for det enkle faktum at dataene er feil eller rett og slett korrupte, og så kommer det katastrofen.

Hvis du tror at dette ikke kan skje, etterlater jeg deg noen feilrapporter (en er min i Debian og har et par bilder) av en gammel feil som er i Xorg, mesa, nouveau og kjernens drm / kms-driver, behandler det til tross for løpe ** hver for seg og være modulær **, sammen kommer de ikke veldig bra sammen, i det minste ikke under disse omstendighetene.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742930
https://bugzilla.redhat.com/show_bug.cgi?id=901816
https://bugzilla.redhat.com/show_bug.cgi?id=679619

Nå vil det andre eksemplet gi deg med systemd. Vår gamle Sysvinit hadde en særegenhet at til tross for at den var gammel, var den veldig pålitelig, til det punktet at hvis / etc / fstab hadde en partisjonsoppføring (ikke viktig for systemet, forstå a / mnt / Disk160GB), og det er det kunne ikke monteres av en eller annen grunn, monteringen ble rett og slett hoppet over, ga deg en advarsel og fortsatte med oppstartsprosessen. Nå er systemd en annen historie, til tross for modulariteten. Hvis du har en oppføring i / etc / fstab og systemd av en eller annen grunn ser at det er umulig å montere den, venter den ikke bare på at partisjonen skal være tilgjengelig (den normale programmerte oppførselen) for montering, men hvis tiden slutter, stoppes systemet ditt, og du kan ikke gjøre mer enn å gå inn i gjenopprettingsmodus og fjerne den linjen fra / etc / fstab, noe mislykkes faktisk. Den lille detaljene ikke mer under automatmonteringen i oppstarten, og hele prosessen stopper, først (systemd-) var den lille detaljene styggere, fordi dumpen bare dukket opp og du måtte starte på nytt. Noen som har gått gjennom detaljene forteller deg.

Et annet eksempel jeg kan gi er coredumpd i systemd. coredumpd sender som standard all informasjonen til journald for at sistnevnte skal skrive den fangede informasjonen til disken, så langt så bra, vi bruker moduliteten til systemd til vår fordel. Men det skjer noen ganger, når coredumps er veldig store, bare så store, at de kan ta opp flere GB, og i ferd med å overføre informasjon fra coredump til journald og deretter til disk, skjer rare ting som Xorg slutter å fungere og til og med kjernepanikk. Det skjer ikke bare med systemd selvfølgelig, men måten det er designet på øker feilfaktoren og skaper andre ubehagelige detaljer (blant annet økt minneforbruk, loggkorrupsjon, ufullstendige dump), som har måttet jobbe Med en KDE coredump har du sikkert vært gjennom flere episoder som disse, og du vil ha forstått viktigheten av å ha synkroniseringsalternativet i / etc / fstab for dumppartisjonen din, og du vil sikkert hate det faktum at du ikke kan bruke et annet alternativ for å håndtere dumpene, hvis du har installert system. Et eksempel på hva som kan skje med systemd-coredumpd.

https://bugs.archlinux.org/task/41728

Nå, for å fullføre:

Skal de ikke være modulære programmer og prosesser? Ja, de er modulære. Kjernen er den eneste monolitiske tingen jeg har snakket om her, men den aksepterer også moduler (LKM), så det ville komme til å være, en slags hybridkjerne, selv om den ikke er utformet i denne typen struktur, og det gjør det litt ustabilt under visse omstendigheter.

Den modulariteten burde ikke tillate meg å forhindre at prosessene og systemet krasjer hvis noe går galt? Det er sant, modularitet er et mål designet for å oppnå en høy grad av stabilitet og pålitelighet, men det er ikke et 100% ufeilbarlig tiltak, for hvis noe kan gå galt, vil det rett og slett gå galt, uansett hvor modulært, det er en realitet.

Hvilket systemd må ha kontroll over alt for å muliggjøre bruk av cgroups og andre alternativer lagt til kjernen? Helt falsk. Det er ikke nødvendig i det hele tatt, systemd kunne ha fått igjen et grensesnitt for å kontrollere oppstart og tildeling av cgroups til prosessene og demonene som vil være i systemet, uten å måtte overta antall tjenester det nå har, og det beste eksempel på det er; at OpenRC også er i stand til å bruke cgroups og ikke er av den grunn så invadere for å utføre den oppgaven.

Hva er jeg partisk og redd når jeg snakker om systemd? Jeg aner ikke hvor han får det fra, for som du ser svaret mitt, er jeg ikke redd for det, jeg snakker bare om aspekter som jeg ikke liker med systemd og allerede, uten å stole på meninger fra tredjeparter.

Til slutt sier du at: "Hvis programmereren var så dårlig til å ikke inkludere kode som kan håndtere uventet input og output, er det noe annet ..."

Absolutt å si at programmereren for å ikke inkludere en kode som håndterer ALLE mulige måter som hans program kan bli ødelagt av feil datainnføring, er DÅRLIG, det virker for meg en opprørende. Uansett hvor god en programmerer han er, en person ikke klarer å designe et ufeilbarlig og feilsikkert program, vil det ALLTID være en feil, hvilken som helst måte vil komme til syne, og når det gjør det, vil det være takket være en tilfeldig feil under dens bruk, av en hacker eller cracker som utnytter et sårbarhet, ved en kodevurdering og revisjon eller på noen annen måte som programmereren kan stole på. Bedre å måle ordene før du sier noe sånt.

Hilsener.