Demystificerend SystemD

@xiep Ik kan het niet meer eens zijn met uw opmerking.

@juanfgs je lijkt de enige die leest, daar juich ik je tenminste voor toe, maar je moet iets heel belangrijks lezen dat in mijn opmerking staat, het maakt niet uit, ik zet het hier:

»NIH Waar? Het lijkt erop dat de goede oude Lennart graag trollen en groots vindt. "

Ik denk niet dat hij het schreef om een ​​onschuldige reden, hij was zich bewust van het feit dat het weer een Lennart-grap was voor April's Fool Day (slecht humeur), evenals zijn passie om /, / etc en al het andere in / te veranderen Linux. 🙂

PS: Bedankt, maar ik hoef mijn Engels niet te oefenen, ik gebruik de taal sinds ik 6 jaar oud was
aaahh en al het andere is waar, verifieer het 🙂

@juanfgs, ik neem u specifiek op uw woord hierover:

«En de realiteit is dat de meeste anti-systemd deze test niet doorstaan, toch zijn er een handjevol mensen die om de een of andere reden MEER WETEN dan de mensen erachter: Debian, Fedora, Archlinux, de Linux-kernel, het hele GNOME-project Waarschijnlijk ook het KDE-project, aangezien ze niet hebben geklaagd over systemd, SUSE en een lange etc.

Toch is zijn giftige en venijnige toespraak het enige dat hij bereikt, verdeeldheid, problemen en anderen teweegbrengen. Dat is het punt dat ik niet kan wachten tot ze eindelijk overschakelen naar BSD, aangezien ze bedreigd zijn door Xorg, NetworkManager, PulseAudio, en ik weet niet of dit komt door pure technische onwetendheid of omdat ze er niet over zouden klagen. "

Dus VOLGENS jullie zijn wij allemaal anti-systemisch giftig en venijnig dat het enige dat we bereiken verdeeldheid, problemen enzovoort is. Laat me je vertellen dat dat de grootste verontwaardiging is die ik hier heb kunnen lezen. Ik weet niet waarom het pro-systeem de moeite zou nemen, als de structurele problemen van een systeem aan het licht komen, die hen op een gegeven moment duidelijk zullen treffen, omdat er nu misschien niets met hen is gebeurd, maar op een gegeven moment wel. het zal, en dan zal een of ander anti-systeem hen herinneren aan de woorden die ze vaak zeiden en niemand hield hen tegen, en misschien zal een ander anti-systeem hen een handje helpen.

Persoonlijk hou ik niet van systemd, maar dat betekent niet dat ik init niet gebruik, dat moet wel, want juist in mijn werk als ik een machine met die init moet aanraken, moet ik weten hoe ik ermee om moet gaan Het. Persoonlijk heb ik het ook gebruikt sinds ik bij Archlinux kwam en zelfs in Debian en Gentoo, dus vertel me niet dat mijn visie vertekend is door het niet gebruiken van systemd, ik heb het gebruikt, en ik weet hoe saai het is. , en als ik iemand hier op het forum moet helpen DesdeLinux of op IRC of de Debian-lijst (wat de distro is waar ik het langst ben geweest en die ik nog steeds gebruik in mijn werk) zal ik het met plezier doen, want juist als ik iets leuk vind aan de Linux-gemeenschap, is het dat ondanks de verschil het is altijd hulp.

Om nu over te schakelen naar BSD, is het mogelijk, maar ik zal het alleen doen als systemd zo virulent wordt dat het me niet toestaat om een ​​andere optie te gebruiken, in de tussentijd blijf ik op Linux en schakel ik al die waanzin uit, inclusief veel van de Cgroups dingen.

Glibc heeft zijn bugs die niemand kan verbergen, er zijn enorme Glibc-bugs die de kernel en honderden uitvoerbare bestanden beïnvloeden. Het verschil tussen Glibc en systemd is dat de eerste een basis is van waaruit DUIZENDEN softwareprojecten kunnen worden omgezet in binaire bestanden, terwijl systemd een init is, waarvan het doel is om een ​​stabiel, bewezen en praktisch onfeilbaar stuk te zijn. Niet alleen dat, Glibc moet zich aanpassen aan honderden verschillende hardware-architectuur (CPU), aan verschillende optimalisatievlaggen en unieke kenmerken van de CPU, aan verschillende vormen van software-optimalisatie, een veel moeilijker en moeilijker werk dan dat van systemd. Ik zie niet echt een manier om een ​​vergelijking tussen de twee projecten op dezelfde schaal te presenteren.

Hetzelfde geldt voor GCC, GCC is een compiler die overigens vele talen ondersteunt (13 in totaal, de onofficiële geteld), en kenmerken heeft die erg lijken op Glibc, en ondersteunt vele architecturen (70 architecturen voor versie 4.9), binaire optimalisatie vlaggen, CPU-optimalisatievlaggen en vele andere functies. Nu hebben ze dezelfde moeilijkheidsgraad, een compiler met een init. Het antwoord ligt voor de hand, te beginnen met dat systemd is in C, en veel van de GCC-code zit in assembler of je moet assembler gebruiken om dingen binair te laten werken, iets dat een beetje "moeilijk te doen" is.

Wat zijn GCC- en Glibc-fouten? Doorzichtig. Zelfs Linus heeft ze zijn aanval gegeven, maar in GCC en Glibc hebben ze iets positiefs dat ze in systemd vaak worden vergeten, en dat wil zeggen, een gerapporteerde bug, een waargenomen bug, een bug opgelost.

Ook vergeet niemand dat Kay Sievers niet alleen de kernel-cmdline heeft verbroken, maar ook wilde stoppen, 'generiek is generiek'.

Ik denk dat je het verkeerd hebt gelezen en geanalyseerd (analyseren is belangrijk) of je hebt jezelf gewoon niet eens de kans gegeven om dat te doen. Dat twee processen informatie doorgeven, is geen reden voor een systeem om te breken, maar als je binaire bestanden hebt met dynamische actie zoals netwerkcontrole, logboeken of coredump, die informatie direct doorgeeft aan init, kunnen er dingen misgaan en gaan ze mis, want als sommige binaire bestanden breken, is de kans om de rest te breken veel groter, en dat is vrij realistisch, en het is gebeurd, de kernel cmdline crash onlangs, de acpi-problemen die Nvidia-ontwikkelaars hadden dankzij systemd-212, dat is alles voorbeeld van wat ik zeg.

@anonymous, ik wil gewoon zien hoe het TTY-probleem zich zal ontwikkelen in Linux. Wanneer de CONFIG_VT-code naar buiten komt, hebben we ten gunste van het verdelen van VT in twee goed gedifferentieerde delen (kernelspace en gebruikersruimte) een tool nodig om de VT's vanuit de gebruikersruimte te besturen en daar kan systemd-consoled een sterke afhankelijkheid zijn die de rest van de distro's naar de noodzaak om de systemd-componenten te installeren, alleen om het systeem te laten werken. Wat ik zeg is niet overdreven, het is een heel, heel grote mogelijkheid en echt zorgwekkend. Er zijn andere projecten, zoals KMSCon, maar als de meeste desktops en distributies voor systemd gaan, kunnen dingen als KMSCon sneller doodgaan dan veel mensen denken.

@anoniem de vraag is dat het verwijderen van CONFIG_VT iets is dat uiteindelijk totaal zal zijn (van wat ik heb gelezen), dat wil zeggen dat in de kernel alleen de primitieven zullen blijven, terwijl de rest van de tools in gebruikersruimte zal zijn, dit is niet slecht, integendeel, het zal veel oude code uit de kernel verwijderen, het gemakkelijker maken om te onderhouden en veel beter configureerbaar (volledige KMS / DRM-ondersteuning voor console). Zeker in het begin zullen er beide systemen zijn, maar op de lange termijn (15-20 releases) zal het mogelijk de kernel verlaten, of zelfs eerder, veel tools ondersteunen dergelijke code niet meer ten gunste van nieuwere en beter ondersteunde code.

Nu zeg je dat als systemd het doet, omdat 50 andere het niet kunnen (ik stel me 50 meer applicaties voor). Welnu, als we de sterke afhankelijkheden van KMSCon zien (het oudste project in deze zin) zijn ze libudev (code die binnenkort aan systemd wordt toegevoegd, zal niet worden ondersteund en zal conflicteren met systemd als het op zichzelf werkt), libdrm, libxkbcommon, libtsm en systemd zelf om multi-seat aan te kunnen, dus als je dit ziet, realiseer je je hoe de dingen vorm krijgen door voor zichzelf veel tools te nemen die nodig zijn om een ​​GNU / Linux OS zonder problemen te laten werken.

@ anoniem zeker wat u zegt is de andere mogelijkheid, eudev zal in dit opzicht meer kracht gebruiken en de opties open houden om verschillende tools te kiezen.

PS: Zoals je zegt, zou het interessant zijn om te zien hoe VT's de voordelen van KMS / DRM samen met fbdev gebruiken 😀

@dariem uitgelegd op een eenvoudige manier om te zien of je het idee snapt:

Wat u zegt, is zeker het gedrag dat altijd wordt verwacht van modulaire programma's en processen. Daartoe werd modulariteit geïmplementeerd, namelijk het scheiden van twee processen en dat ze hun eigen geheugenruimte innemen, en dat ze op de een of andere manier communiceren (IPC, enz.), Zodat er niets ergs gebeurt als er iets misgaat. systeem kan blijven functioneren zonder onderbreking. Een theorie die zeker grote steun heeft gekregen vanwege het potentieel en de enorme marge van betrouwbaarheid die het heeft gegeven aan de huidige computergebruik. Dit is niet altijd waar (het leven is niet altijd mooi), en ik denk dat je zeker wel eens het slachtoffer bent geweest van deze gebeurtenissen (dit geldt zeker voor iedereen, ongeacht het besturingssysteem dat je gebruikt), en ik zal je een paar voorbeelden.

De eerste gaat met Xorg (wat een modulair proces is, net als systemd), dat soms gek wordt met een stuurprogramma en gewoon crasht en je zonder grafische afbeeldingen achterlaat, terwijl de rest van het systeem blijft werken zoals verwacht (Blessed modularity 😀). Tot zover goed, onze theorie dat modulaire processen het systeem niet hoeven te breken, werkt prima. Maar (er zijn er altijd maar) soms geeft Xorg iets meer dan waanzin en om een ​​of andere vreemde reden (die kan variëren van muisbesturing tot grafische driver) crasht Xorg niet alleen, maar het geeft je ook de mooiste kernel panic ( en een graffiti op de monitor zoals Picasso) die je je kunt voorstellen, en dan realiseer je je dat, hoe modulair het ook is, als een proces onderling communiceert en informatie / gegevens uitwisselt met een ander, en er iets misgaat in een van hen, en voor Om de een of andere reden kan de fout niet correct worden afgehandeld, neemt de kans toe dat de processen in kwestie worden beïnvloed, door het simpele feit dat de gegevens fout zijn of gewoon corrupt, en dan komt het de catastrofe.

Als u denkt dat dit niet kan gebeuren, laat ik u enkele bugrapporten achter (een is van mij in Debian en heeft een paar foto's) van een oude fout in Xorg, mesa, nouveau en de drm / kms-driver van de kernel, verwerkt die ondanks ** afzonderlijk draaien en modulair **, samen kunnen ze niet zo goed met elkaar overweg, althans niet onder die omstandigheden.

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

Nu het andere voorbeeld dat ik je ga geven met systemd. Onze oude Sysvinit had een bijzonderheid dat het, ondanks dat het oud was, zeer betrouwbaar was, tot het punt dat als je / etc / fstab een partitie-item had (niet belangrijk voor het systeem, begrijp een / mnt / Disk160GB) en het kan niet ' Om de een of andere reden niet werd gemount, werd de mount gewoon overgeslagen, kreeg u een waarschuwingsbericht en ging verder met het opstartproces. Nu, systemd is een ander verhaal, ondanks zijn modulariteit, als je een ingang hebt in / etc / fstab en systemd om de een of andere reden ziet dat het onmogelijk is om het te mounten, wacht het niet alleen tot de partitie beschikbaar is (het normale geprogrammeerde gedrag ) voor de montage, maar als de tijd voorbij is, wordt uw systeem gestopt en kunt u niets anders doen dan de herstelmodus openen en die regel verwijderen uit / etc / fstab, iets wat eigenlijk niet lukt. Dat kleine detail niet meer tijdens het automount in het opstarten, en het hele proces stopt, in eerste instantie (systemd-) was het kleine detail lelijker, omdat de dump net verscheen en je moest herstarten. Iemand die de details heeft doorgenomen, vertelt het je.

Een ander voorbeeld dat ik kan geven is coredumpd in systemd. coredumpd geeft standaard al zijn informatie door aan journald zodat laatstgenoemde de vastgelegde informatie naar schijf kan schrijven. Tot dusverre gebruiken we de modulariteit van systemd in ons voordeel. Maar het gebeurt soms, wanneer de coredumps erg groot zijn, net zo groot, dat ze meerdere GB in beslag kunnen nemen, en tijdens het doorgeven van informatie van coredump naar journald en vervolgens naar schijf, gebeuren er vreemde dingen zoals Xorg stopt met werken en zelfs kernel paniek. Dat gebeurt natuurlijk niet alleen met systemd, maar de manier waarop het is ontworpen verhoogt de faalfactor en creëert andere onaangename details (waaronder verhoogd geheugengebruik, logboekcorruptie, onvolledige dumps), wie er ook moest werken Met een KDE-coredump, je hebt zeker verschillende afleveringen zoals deze hebben meegemaakt, en je zult het belang hebben begrepen van de synchronisatie-optie in / etc / fstab voor je dumppartitie, en je zult zeker een hekel hebben aan het feit dat je geen andere optie kunt gebruiken om de dumps af te handelen, als je hebt systemd geïnstalleerd. Een voorbeeld van wat er kan gebeuren met systemd-coredumpd.

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

Nu, om te eindigen:

Moeten het niet modulaire programma's en processen zijn? Ja, ze zijn modulair opgebouwd. De kernel is het enige monolithische waar ik het hier over heb, maar het accepteert ook modules (LKM), dus het zou een soort hybride kernel zijn, hoewel de basisontwerpvorm niet is ontworpen in dat type structuur, en dat maakt het onder bepaalde omstandigheden een beetje onstabiel.

Die modulariteit zou me niet moeten toelaten om te voorkomen dat mijn processen en systeem crashen als er iets misgaat? Het is waar, modulariteit is een maatregel die is ontworpen om een ​​hoge mate van stabiliteit en betrouwbaarheid te bereiken, maar het is geen 100% onfeilbare maatregel, want als er iets mis kan gaan, gaat het gewoon fout, hoe modulair ook, dat is een realiteit.

Welk systeem moet alles onder controle hebben om het gebruik van cgroups en andere opties die aan de kernel zijn toegevoegd mogelijk te maken? Helemaal niet waar. Dat is helemaal niet nodig, systemd had een interface kunnen hebben om het opstarten en toewijzen van cgroups aan de processen en daemons die in het systeem zullen zitten te regelen, zonder het aantal services dat het nu heeft over te nemen, en de beste voorbeeld daarvan is; dat OpenRC ook in staat is om cgroups te gebruiken en om die reden niet zo binnenvalt om die taak uit te voeren.

Wat ben ik bevooroordeeld en bang als ik het over systemd heb? Ik heb geen idee waar hij dat vandaan haalt, want zoals je mijn antwoord ziet, ben ik daar niet bang voor, ik praat alleen over aspecten die ik niet leuk vind aan systemd en nu al, zonder te vertrouwen op de meningen van derden.

Ten slotte zeg je dat: "Als de programmeur zo slecht was om geen code op te nemen die kan omgaan met onverwachte invoer en uitvoer, is dat iets anders ..."

Zeker om te zeggen dat de programmeur voor het niet opnemen van een code die ALLE mogelijke manieren behandelt waarop zijn programma kan worden verbroken door een foutieve gegevensinvoer, SLECHT is, lijkt mij een schande. Het maakt niet uit hoe goed een programmeur is, een persoon is niet in staat een onfeilbaar en faalveilig programma te ontwerpen, er zal ALTIJD een storing zijn, die op de een of andere manier aan het licht zal komen, en als dat het geval is, zal dat te danken zijn aan een willekeurige storing tijdens het gebruik ervan, door een hacker of cracker die misbruik maakt van een kwetsbaarheid, door een code-review en -audit of op enige andere manier waarop de programmeur kan rekenen. Het is beter om de woorden te meten voordat u zoiets zegt.

Groeten.