Demüstifitseeriv süsteemD

@xiep Ma ei saa teie kommentaariga rohkem nõus olla.

@juanfgs tundud sa ainus, kes loeb, vähemalt kiidan sind selle eest, kuid peate lugema midagi väga olulist, mis on minu kommentaaris, pole tähtis, ma panen selle siia:

»NIH Kus? Tundub, et vanale heale Lennartile meeldib trallida ja suurelt. "

Ma arvan, et ta ei kirjutanud seda süütul põhjusel, ta oli teadlik nii asjaolust, et see oli järjekordne Lennarti nali aprillinaljaks (halb tuju), kui ka kirest /, / jne ja kõige muu Linuxisse teisendamise kirest. 🙂

PS: Tänan, kuid mul pole vaja oma inglise keelt harjutada, ma olen seda keelt kasutanud 6-aastasest saati
aaahh ja kõik muu on tõsi, kontrollige seda 🙂

@juanfgs, võtan teid konkreetselt selle peale:

«Ja reaalsus on see, et enamik süsteemivastastest testidest ei läbi, isegi nii on käputäis inimesi, kes teavad mingil põhjusel rohkem kui taga olevad inimesed: Debian, Fedora, Archlinux, Linuxi kernel, kogu GNOME projekt Ilmselt ka KDE projekt, kuna nad pole süsteemi, SUSE ja pikka aega jne kurtnud

Isegi nii, et tema mürgine ja vitrioolne kõne on ainus asi, mis ta saavutab, on ebakõla, probleemide ja teiste tekitamine. See on punkt, mida ma ei saa oodata, kuni nad lõpuks BSD-le üle lähevad, kuna nad on ähvardanud Xorgi, NetworkManageri, PulseAudio kaudu, ja ma ei tea, kas puhta tehnilise teadmatuse tõttu või seetõttu, et nad selle üle ei kaebaks. "

Nii et vastavalt teile oleme kõik süsteemivastased mürgised ja vitrioolsed, et ainus asi, mida saavutame, on lahusus, probleemid ja nii edasi. Las ma ütlen teile, et see on suurim nördimus, mida olen saanud siit lugeda. Ma ei tea, miks süsteemi pooldajad häirivad, kui tuuakse üles süsteemi struktuuriprobleemid, mis ilmselgelt mingil hetkel neid mõjutavad, sest nendega ei pruugi praegu midagi juhtuda, kuid mingil hetkel küll. nii saab ja siis tuletab mõni süsteemivastane meelde neid sõnu, mida nad mitu korda ütlesid ja keegi neid ei peatanud ning võib-olla annab mõni muu süsteemivastane käsi neile kätte.

Mulle isiklikult systemd ei meeldi, aga see ei tähenda, et ma initit ei kasuta, pean kasutama, sest just minu töös, kui ma pean selle initiga masinat puudutama, peavad mul olema teadmised selle käsitsemise kohta. seda. Samuti olen isiklikult seda kasutanud alates Archlinuxisse jõudmisest ja isegi Debianist ja Gentoost, nii et ärge öelge mulle, et minu nägemus on systemd mittekasutamise tõttu kallutatud, olen seda kasutanud ja tean, kui labane see on. , ja kui ma pean siin foorumis kedagi aitama DesdeLinux või IRC-s või Debiani nimekirjas (mis on distro, kus olen olnud kõige kauem ja kasutan seda siiani oma töös) teen seda hea meelega, sest just siis, kui mulle midagi Linuxi kogukonna juures meeldib, on see, et vaatamata erinevus on alati abi.

Nüüd BSD-le üleminekuks on see võimalik, kuid teen seda ainult siis, kui systemd muutub millekski nii virulentseks, et see ei võimalda mul ühtegi teist võimalust kasutada, vahepeal jään Linuxisse, keelates kogu selle hulluse, sealhulgas paljud Cgroupsi asjad.

Glibcil on oma vead, mida keegi ei saa varjata, on tohutuid Glibci vigu, mis mõjutavad tuuma ja sadu käivitatavaid. Glibci ja systemd erinevus seisneb selles, et esimene on baas, kust saab tuhandeid tarkvaraprojekte muuta binaarfailideks, samas kui systemd on init, mille eesmärk on olla stabiilne, tõestatud ja praktiliselt eksimatu tükk. Vähe sellest, Glibc peab kohanema ka sadade erineva riistvaraarhitektuuri (CPU), erinevate optimeerimislippude ja protsessori ainulaadsete omadustega, tarkvara optimeerimise erinevate vormidega, palju vaevalisema ja keerulisema tööga kui systemd. Ma ei näe tegelikult võimalust, kuidas esitada kahe sama mastaabiga projekti võrdlust.

Sama kehtib ka GCC kohta, GCC on kompilaator, mis toetab muide paljusid keeli (kokku 13 mitteametlikku keelt) ja millel on Glibciga väga sarnased omadused, mis toetab paljusid arhitektuure (versiooni 70 puhul 4.9 arhitektuuri), binaarseid optimeerimislippe , Protsessori optimeerimise lipud ja paljud muud funktsioonid. Nüüd on nad samal raskusastmel, algatajaga kompilaator. Vastus on enam kui ilmne, alustades sellest, et systemd on C-s ja suur osa GCC-koodist on assembleris või peate asjade binaarse toimimise saamiseks kasutama assemblerit, mis on natuke "raske teha".

Mis on GCC ja Glibci vead? Selge. Isegi Linus on neile andnud oma rünnaku, kuid GCC-s ja Glibcis on neil midagi positiivset, et süsteemis unustatakse nad mitu korda ja see tähendab teatatud viga, nähtud viga, viga parandatud.

Pealegi ei unusta keegi, et Kay Sievers mitte ainult ei rikkunud kerneli cmdline'i, vaid tahtis selle kinni panna, lõppude lõpuks on "geneeriline on üldine".

Ma arvan, et lugesid ja analüüsisid valesti (analüüsimine on oluline) või sa lihtsalt ei andnud endale selleks võimalust. See, et kaks protsessi edastavad teavet, ei ole süsteemi purunemise põhjus, kuid kui teil on dünaamilise toimega kahendfailid, näiteks võrgu juhtimine, logid või coredump, edastate teavet otse init-le, võivad asjad valesti minna ja lähevad valesti, sest kui Mõni binaarfail katkeb, ülejäänute purustamise võimalus on palju suurem ja see on üsna realistlik, ja see on juhtunud, tuuma cmdline kukkus hiljuti kokku, Acpi probleemid, mis Nvidia devidel tekkisid tänu systemd-212-le , see kõik on valim sellest, mida ma ütlen.

@ anonüümne, ma tahan lihtsalt näha, kuidas TTY probleem Linuxis areneb. Kui CONFIG_VT kood välja tuleb, on VT jagamiseks kaheks hästi diferentseeritud osaks (kernelspace ja userspace) vajame mõnda tööriista VT juhtimiseks kasutajaruumist ja süsteemiga lohutatud võib olla tugev sõltuvus, mis tõmbab ülejäänud osa juhised süsteemi süsteemikomponentide installimise vajalikkusest, et süsteem saaks lihtsalt töötada. See, mida ma ütlen, pole liialdus, see on väga-väga suur võimalus ja tõesti murettekitav. On ka teisi projekte, näiteks KMSCon, kuid kui enamik töölaudu ja distrosid toetavad systemd-d, võivad sellised asjad nagu KMSCon surra kiiremini, kui paljud arvavad.

@anonüümne on küsimus, et CONFIG_VT eemaldamine on midagi, mis lõpuks on totaalne (sellest, mida ma lugenud olen), see tähendab, et kernelis jäävad alles vaid primitiivid, ülejäänud tööriistad jäävad kasutajaruumi, see pole halb, vastupidi, see eemaldab kernelt palju vana koodi, muudab selle hooldamise lihtsamaks ja palju paremini seadistatavaks (täielik KMS / DRM-i tugi konsoolile). Kindlasti on alguses olemas mõlemad süsteemid, kuid pikemas perspektiivis (15–20 väljalaset) võib see tuumast väljuda või isegi varem, paljud tööriistad ei toeta enam sellist koodi uuema ja paremini toetatud koodi kasuks.

Nüüd ütlete, et kui systemd seda teeb, sest veel 50 ei saa hakkama (kujutan ette, et veel 50 rakendust). Noh, kui näeme KMSConi (selles mõttes vanim projekt) tugevaid sõltuvusi, siis on need libudev (kood, mis liidetakse peagi systemd-ga, seda ei toetata ja see on vastuolus systemd-ga, kui see töötab iseenesest), libdrm , libxkbcommon, libtsm ja systemd ise saavad hakkama mitme kohaga, nii et kui seda näete, mõistate, kuidas asjad kujunevad, kui võtate endale palju tööriistu, mis on vajalikud GNU / Linuxi operatsioonisüsteemi probleemideta toimimiseks.

@ anonüümne on kindlasti ka see võimalus, mida te ütlete, eudev võtab selles osas suuremat jõudu ja hoiab võimalused erinevate tööriistade valimiseks avatud.

PS: Nagu te ütlete, oleks huvitav näha, kuidas virtuaalseadmed kasutavad KMS / DRMi eeliseid koos fbdeviga 😀

@dariem selgitas lihtsal viisil, kas saate idee:

See, mida te ütlete, on kindlasti käitumine, mida modulaarsetest programmidest ja protsessidest alati oodatakse. Selleks viidi ellu modulaarsus, kahe protsessi eraldamine ja nende enda mäluruumide hõivamine ning suhtlemine mingite vahenditega (IPC jne), nii et kui midagi läheb valesti, siis ei juhtu midagi halba. ja süsteem saab jätkata häireteta tööd. Teooria, millel on kindlasti olnud suur tugi tänu oma potentsiaalile ja tohutule usaldusväärsusele, mille ta on praegusele andmetöötlusele andnud. Nüüd pole see alati tõsi (elu pole alati ilus) ja ma arvan, et olete kindlasti ühel või teisel korral nende sündmuste ohver olnud (see kehtib kindlasti kõigi jaoks, olenemata teie kasutatavast operatsioonisüsteemist) ja ma annan teile paar näidet.

Esimene neist käib koos Xorgiga (mis on moodulprotsess täpselt nagu systemd), mis ajab selle draiveriga mõnikord hulluks ja lihtsalt kukub kokku ning jätab teid graafikata, samal ajal kui ülejäänud süsteem töötab ootuspäraselt (õnnistatud modulaarsus) 😀). Siiani on meie teooria, et modulaarsed protsessid ei pea süsteemi lõhkuma, hästi toimima. Kuid (neid on alati, kuid) mõnikord annab Xorg midagi enamat kui hullus ja mingil kummalisel põhjusel (mis võib ulatuda hiire juhtimisest graafikadraiverini) mitte ainult ei kuku Xorg kokku, vaid annab teile ka kõige ilusama tuuma paanikast (ja graffiti ekraanil nagu Picasso), mida võite ette kujutada, ja siis mõistate, et ükskõik kui modulaarne see ka pole, kui protsess suhtleb ja vahetab teavet / andmeid teisega ja midagi läheb valesti üks neist ja mingil põhjusel ei saa viga õigesti käsitseda, suureneb tõenäosus, et kõnealuseid protsesse mõjutatakse, sest lihtsalt see, et andmed on valed või lihtsalt rikutud, ja siis see tuleb katastroof.

Kui arvate, et seda ei saa juhtuda, jätan teile mõned veateated (üks on Debianis minu oma ja sellel on paar fotot) Xorgis, mesas, nouveau's ja kerneli drm / km draiveris olevast vanast veast, mis töötleb, vaatamata sellele joostes ** eraldi ja olles modulaarsed **, ei saa nad koos eriti hästi läbi, vähemalt mitte sellistel tingimustel.

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üüd toon teise näite systemd-ga. Meie vanal Sysvinitil oli eripära, et hoolimata vanast, oli see väga usaldusväärne, niivõrd kui teie / etc / fstab-l oli partitsioonikirje (süsteemi jaoks pole see oluline, mõistke a / mnt / Disk160GB) ja see on seda ei saanud mingil põhjusel paigaldada, lihtsalt jäeti see vahele, see andis teile hoiatusteate ja jätkas alglaadimist. Nüüd on systemd, hoolimata modulaarsusest, teine ​​lugu, kui teil on kirje kataloogis / etc / fstab ja systemd mingil põhjusel näeb, et seda on võimatu paigaldada, ei oota see ainult partitsiooni olemasolu (tavaline programmeeritud käitumine) selle kokkupanekuks, kuid kui aeg lõpeb, peatatakse teie süsteem ja te ei saa midagi muud teha, kui siseneda taasterežiimi ja eemaldada see rida failist / etc / fstab. See väike detail ei ole enam käivitusautomaadil oleku ajal ja kogu protsess seiskub, algul (systemd-) oli see väike detail kole, sest prügikast ilmus just välja ja te peate taaskäivitama. Keegi, kes selle detaili läbi käis, ütleb sulle.

Teine näide, mida saan tuua, on cordumpd süsteemis. Vaikimisi edastab coredumpd kogu oma teabe journalnaldile, et viimane jäädvustatud teabe kettale kirjutaks, seni on see nii hea, et kasutame systemd modulaarsust enda kasuks. Kuid seda juhtub mõnikord, kui südamikud on väga suured, lihtsalt nii suured, et need võivad mahutada mitu GB, ja teabe edastamise käigus coredumpist ajakirjasse ja seejärel kettale juhtub kummalisi asju, näiteks Xorg lakkab töötamast ja isegi tuuma paanika. Muidugi ei juhtu seda mitte ainult süsteemiga, vaid selle ülesehitus suurendab ebaõnnestumistegurit ja tekitab muid ebameeldivaid detaile (nende hulgas suurenenud mälutarbimine, logi korruptsioon, puudulikud prügimäed), kes on pidanud töötama KDE coredumpiga olete kindlasti läbi käinud mitu sellist episoodi ja olete mõistnud, kui oluline on, et sünkroonimisvalik oleks / etc / fstab oma dump partitsiooni jaoks, ja kindlasti vihkate seda, et te ei saa kasutada mõnda muud võimalust prügimägede käsitsemiseks, kui olete süsteemi installinud. Näide sellest, mis võib juhtuda systemd-coredumpd abil.

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

Nüüd lõpetuseks:

Kas need ei peaks olema moodulprogrammid ja protsessid? Jah, nad on modulaarsed. Kernel on ainus monoliitne asi, millest olen siin rääkinud, kuid see aktsepteerib ka mooduleid (LKM), seega oleks see mingi hübriidtuum, kuigi selle põhikujundusvorm pole seda tüüpi struktuuris kujundatud, ja see muudab selle teatud tingimustel natuke ebastabiilseks.

See modulaarsus ei tohiks lubada mul hoida oma protsesse ja süsteemi kokku kukkumast, kui midagi valesti läheb? Tõsi, modulaarsus on meede, mis on loodud kõrge stabiilsuse ja usaldusväärsuse saavutamiseks, kuid see pole sajaprotsendiliselt eksimatu meede, sest kui midagi võib valesti minna, siis läheb see lihtsalt valesti, ükskõik kui modulaarselt, see on reaalsus.

Millisel systemd-l peab olema kõik kontroll, et võimaldada tuumale lisatud gruppide ja muude valikute kasutamist? Täiesti vale. See pole üldse vajalik, systemd oleks võinud jätta liidese, et kontrollida gruppide käivitamist ja määramist süsteemis olevatele protsessidele ja deemonitele, ilma et peaksite üle võtma praeguste teenuste arvu ja parim selle näide on; et OpenRC on võimeline kasutama ka gruppe ja sel põhjusel ei tungita selle ülesande täitmiseks nii palju.

Mida ma olen süsteemist rääkides erapoolik ja kartlik? Mul pole aimugi, kust ta selle saab, sest nagu näete minu vastust, ei karda ma seda, räägin ainult aspektidest, mis mulle süsteemikeskkonnas ei meeldi, ja juba ilma kolmandate isikute arvamustele tuginedes.

Lõpuks ütlete järgmist: "Kui programmeerijal oli nii halb, et ta ei lisanud koodi, mis suudaks toime tulla ootamatu sisendi ja väljundiga, on see midagi muud ..."

Kindlasti on halb öelda, et kui programmeerija ei lisanud koodi, mis käsitleb KÕIKI võimalikke viise, kuidas tema vigane andmesisestus võib tema programmi rikkuda, siis see on minu arvates nördimus. Ükskõik kui hea programmeerija ta ka pole, ei suuda inimene koostada eksimatut ja tõrkekindlat programmi, tuleb ALATI ebaõnnestumine, mis ühel või teisel viisil selgub ja kui juhtub, siis tänu juhuslikule ebaõnnestumisele selle ajal kasutada häkkerit või häkkerit, mis kasutab haavatavust, koodi ülevaatuse ja auditi abil või muul viisil, millele programmeerija võib loota. Parem mõõta sõnu enne, kui midagi sellist ütlete.

Tervitused.