Demystifioiva järjestelmäD

@xiep En voi olla samaa mieltä kommenttisi kanssa.

@juanfgs näytät ainoalta lukijalta, ainakin minä kiitän sinua siitä, mutta sinun täytyy lukea jotain erittäin tärkeää, joka on kommentissani, ei ole väliä, laitan sen tänne:

»NIH Missä? Näyttää siltä, ​​että vanha hyvä Lennart tykkää uistella ja iso. "

En usko, että hän kirjoitti sen viattomasta syystä, hän oli tietoinen siitä, että se oli toinen Lennartin vitsi huhtikuun hullupäivälle (huono mieliala), sekä intohimonsa muuntaa /, / jne ja kaikki muu Linux. 🙂

PS: Kiitos, mutta minun ei tarvitse harjoitella englantiani, olen käyttänyt kieltä 6-vuotiaasta lähtien
aaahh ja kaikki muu on totta, tarkista se 🙂

@juanfgs, otan sinut sanallesi nimenomaan tästä:

«Ja todellisuus on, että suurin osa anti-systemdistä ei läpäise tätä testiä, silti he ovat kourallinen ihmisiä, jotka tietävät jostain syystä enemmän kuin takana olevat ihmiset: Debian, Fedora, Archlinux, Linux-ydin, koko GNOME-projekti , luultavasti myös KDE-projekti, koska he eivät ole valittaneet systemd: stä, SUSE: sta ja pitkistä jne.

Silti hänen myrkyllinen ja vitriolinen puheensa ainoa asia, jonka hän saavuttaa, on tuottaa erimielisyyttä, ongelmia ja muita. Tällainen on se kohta, jota en voi odottaa, että he lopulta siirtyvät BSD: hen, koska he ovat uhanneet Xorgista, NetworkManagerista, PulseAudiosta, enkä tiedä johtuuko pelkästään teknisestä tietämättömyydestä tai siitä, etteivätkö he valittaisi siitä. "

Joten sinun mukaansi me kaikki järjestelmien vastaiset olemme myrkyllisiä ja vitriolisia, että ainoa asia, jonka saavutamme, on erimielisyys, ongelmat ja niin edelleen. Haluan kertoa teille, että tämä on suurin suuttumus, jonka olen voinut lukea täältä. En tiedä, miksi pro-systemd vaivaa, kun järjestelmän rakenteelliset ongelmat tuodaan esiin, mikä tietysti jossain vaiheessa vaikuttaa heihin, koska heille ei ehkä ole tapahtunut mitään, mutta jossain vaiheessa he tekevät. se tulee, ja sitten joku anti-systemd muistuttaa heitä sanoista, joita he sanoivat monta kertaa, eikä kukaan pysäyttänyt heitä, ja ehkä joku muu anti-systemd antaa heille käden.

En lo personal, no me gusta systemd, pero eso no significa que no use el init, tengo que hacerlo, porque precisamente en mi trabajo si tengo que tocar alguna maquina con ese init, debo tener conocimiento de como manejarlo. Además en lo personal también lo he usado desde que llego a Archlinux e incluso en Debian y Gentoo, así que no me venga a decir que mi visión es sesgada por no hacer uso de systemd, yo le he usado, y se de que pata renquea, y si tengo que ayudar a alguien acá en el foro DesdeLinux o en IRC o la lista de Debian (que es la distro donde yo más tiempo he estado y aún uso en mi trabajo) lo haré con gusto, porque precisamente si algo me agrada de la comunidad Linux, es que pese a la diferencia siempre se ayuda.

Siirtyminen BSD: hen on nyt mahdollista, mutta teen sen vain, jos systemd muuttuu niin virulenteiksi, että se ei salli minun käyttää mitään muuta vaihtoehtoa. Sillä välin pysyn Linuxissa, poistamalla kaikki hulluudet, mukaan lukien monet Cgroups-asiat .

Glibc: llä on vikoja, joita kukaan ei voi piilottaa, on valtavia Glibc-vikoja, jotka vaikuttavat ytimeen ja satoihin suoritettaviin tiedostoihin. Ero Glibc: n ja systemd: n välillä on se, että edellinen on perusta, josta TUHANNET ohjelmistoprojekteja voidaan muuntaa binääreiksi, kun taas systemd on init, jonka tarkoituksena on olla vakaa, todistettu ja käytännössä erehtymätön pala. Paitsi, että Glibcin on sopeuduttava satoihin erilaisiin laitteistoarkkitehtuuriin (CPU), erilaisiin optimointilippuihin ja CPU: n ainutlaatuisiin ominaisuuksiin, erilaisiin ohjelmistojen optimointimuotoihin, mikä on myös paljon työlästä ja vaikeaa työtä kuin systemd: llä. En todellakaan näe mitään tapaa esittää vertailua kahden saman mittakaavan hankkeen välillä.

Sama koskee GCC: tä, GCC on kääntäjä, joka tukee muuten monia kieliä (yhteensä 13 epävirallisia kieliä) ja jolla on hyvin samanlaiset ominaisuudet kuin Glibc: llä, joka tukee monia arkkitehtuureja (70 arkkitehtuuria versiolle 4.9), binääristä optimointia liput, suorittimen optimointiliput ja monia muita ominaisuuksia. Nyt he ovat samalla vaikeustasolla, kääntäjällä, jolla on init. Vastaus on enemmän kuin ilmeinen, aloittaen siitä, että systemd on C: ssä, ja suuri osa GCC-koodista on assemblerissa tai joudut käyttämään assembleria saadaksesi asiat toimimaan binaarisesti, jotain hieman "vaikea tehdä".

Mitä GCC- ja Glibc-virheitä on? Asia selvä. Jopa Linus on antanut heille hyökkäyksensä, mutta GCC: ssä ja Glibcissä heillä on jotain positiivista, että järjestelmässä heidät usein unohdetaan, eli ilmoitettu vika, nähty vika, vika korjattu.

Kukaan ei myöskään unohda, että Kay Sievers ei vain rikkonut ytimen cmdline-ohjelmaa, vaan halusi sulkea sen, kun kaikki "geneerinen on yleinen".

Luulen, että olet lukenut ja analysoinut väärin (analysointi on tärkeää) tai et vain antanut itsellesi mahdollisuutta tehdä niin. Nämä kaksi prosessia välittävät tietoja eivät ole syy järjestelmän hajoamiseen, mutta kun sinulla on binäärejä, joilla on dynaaminen toiminta, kuten verkon hallinta, lokit tai coredump, tietojen välittäminen suoraan initille, asiat voivat mennä pieleen ja ne menevät pieleen, koska Jos jotkut binäärit hajoavat, mahdollisuudet rikkoa loput ovat paljon suuremmat, ja se on varsin realistista, ja niin on tapahtunut, ydin cmdline kaatui äskettäin, Acpi-ongelmat, joita Nvidia devsilla oli systemd-212: n ansiosta, kaikki mikä on näyte mitä sanon.

@ nimetön, haluan vain nähdä, kuinka TTY-asia kehittyy Linuxissa. Kun CONFIG_VT-koodi tulee ulos, VT: n jakamiseksi kahteen hyvin erilaistettuun osaan (ytimetila ja käyttäjätila) tarvitsemme jonkin verran työkalua VT: iden hallitsemiseksi käyttäjätilasta, ja järjestelmä-lohduttama voi olla vahva riippuvuus, joka vetää loput distrot tarpeeseen asentaa systemd-komponentit vain järjestelmän toiminnan mahdollistamiseksi. Se, mitä sanon, ei ole liioittelua, se on erittäin, erittäin suuri mahdollisuus ja todella huolestuttava. On muitakin projekteja, kuten KMSCon, mutta jos useimmat työpöydät ja distrot suosivat systemd: tä, KMSConin kaltaiset asiat voivat kuolla nopeammin kuin monet ihmiset ajattelevat.

@ anonyymi on kysymys siitä, että CONFIG_VT: n poistaminen on loppujen lopuksi täydellistä (lukemastani), ts. ytimessä vain primitiivit jäävät, kun taas muut työkalut ovat käyttäjätilassa, tämä ei ole huono, päinvastoin, se poistaa paljon vanhaa koodia ytimestä, tekee siitä helpomman ylläpidettävän ja paljon konfiguroitavamman (koko KMS / DRM-tuki konsolille). Varmasti alussa on molemmat järjestelmät, mutta pitkällä aikavälillä (15-20 julkaisua) se mahdollisesti sulkee ytimen, tai jopa aikaisemmin, monet työkalut eivät enää tue tällaista koodia uudemman ja paremmin tuetun koodin hyväksi.

Sanot nyt, että jos systemd tekee sen, koska 50 muuta ei voi tehdä sitä (kuvittelen vielä 50 sovellusta). No, jos näemme KMSConin (tässä mielessä vanhin projekti) vahvat riippuvuudet, ne ovat libudev (koodi, joka liitetään pian systemd: hen, ei tueta ja on ristiriidassa systemd: n kanssa, jos se toimii yksin), libdrm, libxkbcommon, libtsm ja systemd itse hoitavat monipaikan, joten kun näet tämän, huomaat kuinka asiat muotoutuvat ottamalla itselleen paljon työkaluja, joita tarvitaan GNU / Linux-käyttöjärjestelmään toimimaan ongelmitta.

@ tuntematon, mitä sanot, on varmasti toinen mahdollisuus, eudev ottaa tässä suhteessa enemmän voimaa ja pitää avoimena vaihtoehtoja eri työkalujen valitsemiseksi.

PS: Kuten sanot, olisi mielenkiintoista nähdä, kuinka VT hyödyntää KMS / DRM: n etuja yhdessä fbdevin kanssa 😀

@dariem selitti yksinkertaisella tavalla nähdäksesi, saatko idean:

Se, mitä sanot, on varmasti käyttäytymistä, jota modulaarisilta ohjelmilta ja prosesseilta aina odotetaan. Modulaarisuus toteutettiin tätä tarkoitusta varten, kahden prosessin erottamiseksi toisistaan ​​ja siitä, että ne käyttävät omia muistitilojaan ja että ne kommunikoivat jollakin tavalla (IPC jne.), Jotta siinä tapauksessa, että jotain menee pieleen, ei tapahdu mitään pahaa. järjestelmä voi jatkaa toimintaansa keskeytyksettä. Teoria, jolla on varmasti ollut suuri tuki potentiaalinsa ja valtavan luotettavuusmarginaalin ansiosta, jonka se on antanut nykyiselle tietojenkäsittelylle. Tämä ei ole aina totta (elämä ei ole aina kaunista), ja luulen, että olet varmasti joutunut näiden tapahtumien uhriksi yhdessä tai toisessa tilanteessa (tämä pätee varmasti kaikille riippumatta käyttöjärjestelmästä, jota käytät), ja annan pari esimerkkiä.

Ensimmäinen liittyy Xorgiin (joka on modulaarinen prosessi kuten systemd), joka joskus ajaa sen hulluksi ohjaimen kanssa ja vain kaatuu ja jättää sinut ilman grafiikkaa, kun taas muu järjestelmä toimii edelleen odotetusti (siunattu modulaarisuus 😀). Toistaiseksi niin hyvä teoriamme, että modulaaristen prosessien ei tarvitse rikkoa järjestelmää, toimii hyvin. Mutta (aina on joitain mutta) Xorg antaa joskus jotain muuta kuin hulluutta ja jostain outosta syystä (joka voi vaihdella hiiren ohjauksesta grafiikkaohjaimeen) Xorg ei vain kaatuu, mutta antaa sinulle myös kauneimman ytimen paniikeista (ja graffiti näytöllä, kuten Picasso), jonka voit kuvitella, ja sitten huomaat, että riippumatta siitä, kuinka modulaarinen se on, jos prosessi kommunikoi ja vaihtaa tietoja toisen kanssa ja jotain menee pieleen yhtä heistä, ja jostain syystä virhettä ei voida käsitellä oikein, mahdollisuudet vaikuttaa kyseisiin prosesseihin kasvavat, yksinkertaisesti tosiasia, että tiedot ovat väärät tai yksinkertaisesti korruptoituneet, ja sitten se tulee katastrofi.

Jos luulet, ettei näin voi tapahtua, jätän sinulle joitain vikailmoituksia (yksi on minun Debianissa ja siinä on pari valokuvaa) vanhasta virheestä, joka on Xorgissa, mesassa, nouveaussa ja ytimen drm / kms-ohjaimessa, prosessit, jotka huolimatta juoksevat ** erikseen ja ovat modulaarisia **, yhdessä he eivät tule toimeen kovin hyvin, ainakaan olosuhteissa.

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

Nyt toinen esimerkki, jonka aion antaa sinulle systemd: llä. Vanhalla Sysvinit-laitteellamme oli erikoisuus, että vanhasta huolimatta se oli erittäin luotettava siihen pisteeseen asti, että jos / etc / fstab -laitteellasi oli osiotiedosto (ei ole tärkeää järjestelmälle, ymmärrä / mnt / Disk160GB) ja se on sitä ei voitu asentaa jostain syystä, kiinnitys yksinkertaisesti ohitettiin, antoi sinulle varoitusviestin ja jatkoi käynnistysprosessia. Nyt systemd on toinen juttu modulaarisuudestaan ​​huolimatta, jos sinulla on merkintä tiedostossa / etc / fstab ja systemd jostain syystä näkee, että sen asentaminen on mahdotonta, se ei vain odota, että osio on käytettävissä (normaali ohjelmoitu käyttäytyminen) sen kokoonpanoa varten, mutta jos aika loppuu, järjestelmäsi pysäytetään, etkä voi tehdä muuta kuin siirtyä palautustilaan ja poistaa tuon rivin tiedostosta / etc / fstab. Se pieni yksityiskohta ei enää enää käynnistyksen automaattisen asennuksen aikana, ja koko prosessi pysähtyy, aluksi (systemd-) pieni yksityiskohta oli ruma, koska kaatopaikka ilmestyi juuri ja sinun oli käynnistettävä uudelleen. Joku, joka kävi läpi yksityiskohdat, kertoo sinulle.

Toinen esimerkki, jonka voin antaa, on cordumpd systemd: ssä. coredumpd välittää oletusarvoisesti kaikki tietonsa journaln: lle, jotta viimeksi mainittu voi kirjoittaa kaapatut tiedot levylle, toistaiseksi niin hyvältä, käytämme systemd: n modulaarisuutta eduksi. Mutta sitä tapahtuu joskus, kun ytimot ovat hyvin suuria, vain niin suuria, että ne voivat viedä useita Gt, ja tiedonsiirron aikana Coredumpista journalin ja sitten levylle tapahtuu outoja asioita, kuten Xorg lakkaa toimimasta ja jopa ytimen paniikkia. Tämä ei tietenkään tapahdu pelkästään järjestelmän kanssa, mutta sen suunnittelu lisää vikatekijää ja luo muita epämiellyttäviä yksityiskohtia (muun muassa lisääntynyt muistin kulutus, lokivirhe, puutteelliset kaatopaikat), kuka tahansa piti työskennellä KDE-coredumpin avulla olet varmasti käynyt läpi useita tällaisia ​​jaksoja, ja olet ymmärtänyt, kuinka tärkeää synkronointiasetuksella on / etc / fstabissa dump-osioosi, ja vihaat varmasti sitä, ettet voi käyttää muuta vaihtoehtoa käsitellä kaatopaikkoja, jos olet asentanut systemd. Esimerkki siitä, mitä voi tapahtua systemd-coredumpd: n kanssa.

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

Lopuksi:

Eivätkö niiden tarvitse olla modulaarisia ohjelmia ja prosesseja? Kyllä, ne ovat modulaarisia. Ydin on ainoa monoliittinen asia, josta olen puhunut täällä, mutta se hyväksyy myös moduulit (LKM), joten se olisi eräänlainen hybridiydin, vaikka sen perusmuotoa ei ole suunniteltu tämän tyyppiseen rakenteeseen, ja se tekee siitä hieman epävakaa tietyissä olosuhteissa.

Tämän modulaarisuuden ei pitäisi antaa minun pitää prosessejani ja järjestelmääni kaatumasta, jos jokin menee pieleen? On totta, modulaarisuus on toimenpide, jolla on tarkoitus saavuttaa korkea vakaus ja luotettavuus, mutta se ei ole 100-prosenttisesti erehtymätön toimenpide, koska jos jokin voi mennä pieleen, se yksinkertaisesti menee pieleen riippumatta siitä, kuinka modulaarista, se on todellisuutta.

Millä systemd: llä on oltava kaiken hallinta, jotta cgroupien ja muiden ytimeen lisättyjen vaihtoehtojen käyttö on mahdollista? Täysin väärä. Se ei ole lainkaan välttämätöntä, systemd: lle olisi voitu jättää käyttöliittymä, jolla voidaan hallita ryhmien käynnistystä ja määritystä järjestelmässä oleville prosesseille ja demoneille tarvitsematta ottaa haltuunsa nykyisten palvelujen määrää. esimerkki siitä on; että OpenRC pystyy myös käyttämään c-ryhmiä eikä ole siksi syystä tunkeutunut suorittamaan kyseisen tehtävän.

Mitä olen puolueellinen ja pelokas puhuessani systemd: stä? Minulla ei ole aavistustakaan, mistä hän saa sen, koska kuten näet vastaukseni, en pelkää sitä, puhun vain niistä näkökohdista, jotka eivät pidä järjestelmääni, ja jo nyt ilman, että luotan kolmansien osapuolten mielipiteisiin.

Lopuksi sanot: "Jos ohjelmoija oli niin huono, ettei se sisältänyt koodia, joka pystyy käsittelemään odottamattomia tuloja ja lähtöjä, se on jotain muuta ..."

Varmasti sanomalla, että ohjelmoija on huono, koska se ei sisällyttänyt koodia, joka käsittelee KAIKKIA mahdollisia tapoja, joilla hänen ohjelmansa voi rikkoutua virheellisen tietojen syöttämisen vuoksi. Ei ole väliä kuinka hyvä ohjelmoija hän on, ihminen ei pysty suunnittelemaan erehtymättömää ja vikaturvallista ohjelmaa, tulee AINA epäonnistuminen, joka tavalla tai toisella tulee esiin, ja kun se tapahtuu, se johtuu satunnaisesta epäonnistumisesta sen aikana käyttää hakkeri tai hakkeri, joka hyödyntää haavoittuvuutta, koodin tarkistuksella ja tarkastuksella tai muulla tavalla, johon ohjelmoija voi luottaa. Parempi mitata sanoja ennen kuin sanot sellaista.

Tervehdys.