A számítógépeink minden nap az életünk fontosabb részét képezik, ha valamilyen problémája van, az befolyásolja a hangulatunkat, a humorunkat hehe. Bizony, a Windows felhasználói hajlamosabbak a pánikrohamokra, mintha vírusok (éljen a linux!), mi lenne, ha töredezettségmentesítenénk a HDD-t, mi lesz, ha keresünk és telepítünk Tiszta Master for PC (bár itt a Linuxban még meg kell tisztítanunk a rendszert, a BleachBit az egyik előnyben részesített alternatíva). Nemrégiben a Linux-felhasználóknak (némelyiküknek) bizonyos fejfájása van: systemd
Nos, lényegem szerint egy érdekes cikket olvastam a témáról systemd, ami látszólag nem sokáig volt divat.
SystemD, ami néhányaknak tetszik (és egy barátom szavát fogom használni), egy gyűrű mind felett ... mások egyszerűen nem illenek, és nem is, amíg a számítógép jól működik, nem érdekli őket, hogy az init X vagy Y dolgokat csinál-e, vagy a systemd-t használják. Erre, aki ír, hát ... mondjuk én inkább az initet, egyszerűbbnek találom
A cikket itt hagyom:
Mielőtt elkezdeném, el kell mondanom, hogy nem szeretem a Debian dolgának megváltoztatására vonatkozó döntést, de soha nem tervezem elhagyni szeretett spirálomat. Csak azt próbálom meg, hogy ha egy témát akarunk megvitatni, legalább a lehető legfelkészültebbé tegyük azt, bár én magam sem tartom magam rendszerszerűnek. A systemd demisztifikációjának eléréséhez egy olyan weboldalra fogok támaszkodni, ahol a fejlesztők megadják álláspontjukat amelyet egy olyan kollégám kapott a kezembe, aki úgy tűnik, hogy pro-systemd annak ellenére, hogy nem Debian felhasználó. Ezzel azt mondom, hogy továbbléphetek arra, hogy megpróbáljam lebontani a systemd-ről elmondottakat.
A systemd bináris alapú
Talán ez az egyik szempont, amely minket a legjobban megdöbbent, ha minden bináris alapú, hogyan figyeljük az általában naplókon keresztül végzett dolgokat? Fogalmam sincs, hogyan született ez a mítosz, de ez nem teljesen igaz.
A systemd szinte kizárólag egyszerű szöveges fájlokon keresztül van konfigurálva. Néhány olyan beállítás, amely a kernel parancssorával és környezeti változókon keresztül is módosítható. A konfigurációban nincs semmi bináris (még XML sem). Csak egy egyszerű, egyértelmű és könnyen olvasható szöveges fájl.
Ez a dolog monolitikus és mindent irányít
Mielőtt eljutnék a fent említett weboldalra, bevallom, hogy magam is így gondoltam, de miután elolvastam, amit a fejlesztői mondanak, a véleményem valamit megváltoztatott ...
Ha az összes konfigurációs opcióval engedélyezi a systemd-t, akkor épít 69 egyedi bináris fájl. Ezek a bináris fájlok különböző feladatokat szolgálnak, és számos okból gondosan el vannak különítve. Például a systemd-t a biztonságot szem előtt tartva tervezték, ezért a legtöbb démon a legkevesebb jogosultsággal fut (például a kernel képességeit használva), és csak nagyon specifikus feladatokért felel, hogy minimalizálják a lábnyomukat, a biztonságot és a hatást. Ezenkívül a systemd párhuzamai minden más megoldásnál jobban elindulnak. Ez a "párhuzamosság" a futással jön létre különféle folyamatok párhuzamosan. Ezért látható, hogy a systemd nagyon jól el van osztva sok bináris fájlra és ezért folyamatokra. Valójában ezek közül a bináris fájlok közül sok olyan jól elválik egymástól, hogy nagyon hasznosak a systemd-n kívül.
Egy csomag, amely 69 külön bináris fájlt tartalmazott, alig hívható monolitikus. Ami azonban különbözik a korábbi megoldásoktól, az az, hogy több összetevőt szállítunk egyetlen tárfájlba, és egyetlen adattárban láncolva tartjuk őket egységes kiadási ciklussal.
Ez nem hasonlít a Unix-ra
Ebben bizony van némi igazság. A systemd forrásfájlok nem tartalmaznak egyetlen kódsort sem az eredeti UNIX sorokból. Az inspiráció azonban a UNIX-ból származik, ezért sok UNIX található a systemd-ben. Példaként említhetjük a UNIX "minden fájl" ötletét, amely abban tükröződik, hogy a systemd-ben minden szolgáltatás futás közben van kitéve egy rendszermag fájlrendszerben, a cgroupfs. Tehát a UNIX egyik eredeti jellemzője a beépített terminál támogatásán alapuló többüléses támogatás volt. A systemd-vel ismét natívan hoztuk a többüléses támogatást, de ezúttal a mai hardver teljes támogatásával, amely grafikákat, egereket, hangot, webkamerákat és egyebeket takar. Valójában a systemd tervezése olyan integrált eszközöként, amelyek mindegyikének megvan a maga célja, de ha együtt használják, meghaladja az alkatrészek összegét, ami nagyjából a UNIX filozófiájának középpontjában áll. Tehát a projektünk kezelési módja (azaz az operációs rendszer kernjének nagy része egyetlen git tárhelyen tartása) sokkal közelebb áll a BSD modellhez (ami egy igazi UNIX, szemben a Linuxszal), hogy elvégezzük a dolgokat (ahol a legtöbb a központi operációs rendszert egyetlen CVS / SVN adattárban tárolják), ami Linuxon soha nem volt ilyen.
Végül nagyon kevéssé számít az a kérdés, hogy valami UNIX-e vagy sem. Mivel műszakilag kiváló, aligha jellemző a UNIX-ra. Számunkra a UNIX a fő hatás (valójában a legnagyobb), de vannak más hatásaink is. Ennélfogva egyes területeken a systemd nagyon UNIX, máshol pedig valamivel kevésbé lesz.
Ez nagyon összetett ...
Ebben bizony van némi igazság. A modern számítógépek összetett vadállatok, és a rajtuk futó operációs rendszer is nyilvánvalóan az lesz, tehát összetettnek kell lenniük. Azonban a systemd természetesen nem összetettebb, mint ugyanazon összetevők korábbi megvalósításai. Egyszerűbb és kevesebb a redundancia. Másrészt egy egyszerű systemd-alapú operációs rendszer felépítése sokkal kevesebb csomagot tartalmaz, mint a hagyományos Linux-alkalmazások. Kevesebb csomag megkönnyíti a rendszer felépítését, megszabadul az egymásrautaltságtól és az összes érintett komponens eltérő viselkedésétől.
Ez nem engedi, hogy shell szkripteket használjak
Ez teljesen valótlan. egyszerűen Nem használjuk őket a rendszerindítási folyamathoz, mert úgy gondoljuk, hogy nem a legjobb eszköz erre a konkrét célra, de ez nem jelenti azt, hogy a systemd nem volt kompatibilis velük. Könnyedén futtathatja a shell parancsfájlokat systemd szolgáltatásként vagy démonként, futtathatja a beírt szkripteket cualquier a nyelv mint systemd szolgáltatás, mivel a systemd a legkevésbé sem érdekli, hogy mi található a futtatható fájlban. Másrészt a shell szkripteket nagyrészt saját céljainkra használjuk, a systemd telepítéséhez, felépítéséhez, teszteléséhez. És beillesztheti a szkripteket a korai indítási folyamatba, normál szolgáltatásokhoz használják őket, az utolsó megállóban futtathatók, gyakorlatilag nincsenek korlátozások.
Ezen a ponton feltételezem, hogy néhány fő meggyőződés tisztázódhatott, annak ellenére, hogy nem éreztem magam a változás szószólójaként, és aggályaim voltak a „egy démon, aki mindet irányítani tudja"Úgy gondolom, hogy a végén senki sem meri azt mondani, hogy legalábbis nem működik, sőt ismerek néhány felhasználót, akik észreveszik, hogy a systemd-vel" a számítógép gyorsabban fut ", de ezek más dolgok is megvitathatók. Jelenleg csak az a kérdésem, hogy meghívlak benneteket, hogy itt vitassák meg a startup managerrel kapcsolatos nézeteit, amelyeket sok disztribúció fogadott el, bár most a legnagyobb reakciókat a Debian közösség látja, amely még egy új villa mindezzel. Akár tetszik, akár nem, mindenki dolga, a magam részéről csak annyit akarok tenni, hogy demistifikálom a systemd-t, amely végül jelen lesz Jessie-ben, a Debian következő stabil verziójában.
Láttam a cikket a GUTL-ben (amely viszont a FromAbreus)
Systemd áram?
Azok közé tartozom, akik nem olvasnak sok hírt, ha valami ennyire vitát vált ki, inkább a technikai részleteknél maradok. Az, hogy a…. néha úgy érzem, hogy bizonyos témák nem pusztán technikai viták vagy viták, és olyanokká válnak, mint a hírességek pletykái one
Először egy nyitott sort kell megadnia a felhasználó és a rendszer között systemd VS intelligencia, majd Linus Torvalds ezt mondta a systemd nem is olyan rossz hogyan festikés valamilyen ok, ha van), egy villát hívtak haszontalan … Nincsenek hozzászólások ... és végül Devuan.
Nem mondom, hogy ez olyan rossz, mint mondják, kevésbé rossz vagy rosszabb. A rendszer problémamentesen működik számomra, azonban személyes ízlésemnek inkább az initet választanám, mert a különböző dolgok (például a rönkök) rendezésének módját jobban szeretem, de hé, ha a systemd-t versenylónak hívják, és le kell cserélnie benne (A mi csomagoló öszvérünk lenne, amely mindent megtesz, csak lassan?) Nos ... ember, mindaddig, amíg a változás nem rendkívül hirtelen, a felhasználók sok probléma nélkül képesek alkalmazkodni, és a rendszer jobban működik (igen, jobban, nekem ez nem elég!), Üdvözlöm
Nagyon jó cikk, néhány napja használom a Linux Mint 17.1 Rebeccát a systemd-vel, és sokkal folyékonyabbnak érzem magam, mint a korábbi verzióknál, erről nem sokat tudok, mert gyakori felhasználó vagyok, aki tanul erről, de Vigyázni fogok, ez az első cikk, amit olvastam, amely nem beszél a systemD kártevőiről.
Valamiért ő lesz az első, akit olvastál, hogy nem beszél kártevőkről róla, másrészt mondd, használod-e szerverként a pénzverdádat?, És ezért nem zavar téged, nem Nem tetszik, de a systemd sem csesz el. Ha hibáid vannak, és emiatt komoly környezetben komoly problémáid vannak, az zavarni fog.
Haver, néhány Debian Stable alapú disztró, amit ajánlasz? Használhatnám a Debiant, de sok mindent be kell állítania a telepítés után, kodekeket stb. Melyiket ajánlja? köszönöm.
És hogyan sikerült a Linux Mint-be kerülnie a systemd-be? Meg akartam próbálni betenni, de nem tudom, hogy kell-e még valami kiegészítőt tennem (amihez elméletileg már hozza az Ubuntu), ha van valamilyen útmutatód az ügyben, vagy valami, amit át tudsz adni nekem, nagyon értékelné
Nagyon jó cikk. Lássuk, olvasta-e a tálibok System anti-anti (de kétlem)
Mindenesetre egy év múlva látni fogom őket a SystemD használatával, és tagadni fogják azt, amit egy évvel ezelőtt mondtak. Így vannak. Ellenáll a változásnak? Biztosan igen.
Talibánnak tartasz, amiért nem akarom elfogadni a Systemd-t, akkor tálibnak tartom, amiért nem akarod elfogadni, hogy nem akarom elfogadni a Systemd-t. Közel vagyunk 😉
Azonban, amint az a cikkek végén szerepel:
«elav: Személyes blog / Twitter / G+ / ArchLinux felhasználó. Informatikus, zeneszerető, blogger és webdesigner. adminisztrátora és alapítója DesdeLinux.háló. »
vagyis a SystemD által elfogadott első terjesztések egyikét használja.
Üdvözlet
OK, kölyök.
Szavak nélkül !!!!, játssz tovább, az élet rózsás.
Az olyan hozzászólásokhoz, mint a tiéd, kedves Giskard, ezért nem mondom el a SystemD-t, és mit képvisel.
És ha 20 év után használom és dolgozom a Linux-on és a Linux alatt, akkor tálib vagyok; Nos, legyen.
Egy év múlva beszélünk. És elav, nem említettem. Chacumbele néven ölted meg magad.
Lássuk, az emberek olvasnak és NEM olvasnak. Vannak vagy nincsenek tálibok a SystemD ellen? Vannak! És vannak a túloldalon azok, akik foggal-körömmel védik, mintha csodaszer lenne. Mik azok mind, akik? Nem! Egyáltalán nem! Vannak, akik szimpatizálnak egyikükkel vagy másikkal, és látják a sajátjaik és mások jójait és rosszjait egyaránt. Azokkal problémamentesen beszélgethet. De nem tagadják, hogy ott vannak a tálibok. És egyik oldalról a másikra. És ha valakit ez elcsípett anélkül, hogy megértette volna, hogy nagyon NEM lehet tálib, akkor az ügyemet nyugtatom, mert a bizonyítékok bűnössé teszik.
Ha valakivel párbeszédet folytatok a SystemD-ről, és kezdettől fogva az illető nem a nevén szólítja, hanem a Systemshit-en vagy hasonlóval, akkor őszintén szeretném, ha elmondanák nekem, hogy lehet-e beszélgetni egy ilyen személlyel, aki kezdetben kizárja a ellenfél. Nem lehet.
Egyébként olvasni kell. Lássuk, ha jövök és azt mondom, hogy "van-e olyan eschejfhduf (kitalált szó), aki megveri a gyerekeket, amikor elhagyják az iskolát", és néhányan azért jönnek, hogy megvédjék az "eschejfhduf" -t, nem az a gondolat, hogy ők maguk is azok?
Nos, ha valaki odakint (kérjük, ne a tálibok, és ne az eschejfhduf is) az init és a SystemD előnyeiről és hátrányairól akar beszélni (amelyeknek egyaránt vannak jó és rossz dolgai), akkor örömmel ott leszek.
Üdvözlet.
A tálib anti rendszer? és mondd meg, mi vagy? a rendszerpárti tálibok?, másrészt miért feltételezed, hogy nem olvasni, hanem közvetlenül kommentálni fogjuk? Ki az a zárt gondolkodású tálib, aki nem ismeri el a vitát és úgy beszél, mint az LP :: «Ez a legjobb, bízz bennem, tudom, mit csinálok ". ?
Elolvastam az egész cikket, és elmondhatom:
A Systemd bináris alapú: Igaz
A demisztifikáció: Hamis
Az LP félrevezeti az elhangzottakat, vagyis, hogy a systemd mag bináris, sok, túl sok a PID1-től való lógáshoz, erősen átlapoltak, olyannyira, hogy meghívlak benneteket, hogy nézzétek meg, hogy #devuan mennyibe kerül a tisztítás, például logind A systemd és a Debian többi csomagja, tekintve, hogy a PAM-ot helyettesítő naplózás mennyire kötődik a rendszerhez.
A konfiguráció tömör, és nem teszi lehetővé MINDENT, amit nem szeretnék, például deaktiválni a naplót, mivel nem lehet megölni a PID-t, nem lehet megállítani, vagy bármi, vagyis a modularitás?
===========
"Ez a dolog monolit és mindent irányít."
Azon túl, hogy 2 vagy 69 bináris fájlról van szó, összekapcsolódnak egymással a dbusszal és így az egész operációs rendszerrel, nem engedve, hogy könnyen kapcsolatba kerüljenek, a legegyértelműbb eset a journald, hogy nem lehet inaktiválni, , a démonok vagy szolgáltatások elindítása "egységeken" keresztül történik, amelyek szöveges fájlok, de nem más, mint a systemd és a voila elemzése, a szolgáltatásokon belül a létrehozottakon túl semmilyen módosítás vagy feltörés.
=======
"Nem úgy néz ki, mint UNIX"
Röviden válaszolok rá. Nem felel meg az LSB-nek, sem a POSIX-nak, ma pedig egy fedora fejlesztő, aki segít a #devuanban, azt mondta: «Igaz, hogy nem, nem számít, az a fontos, hogy olyan dolgokat tud futtatni, amelyek a POSIX, a pihenjen, biztosan nem érdekel, hogy milyen operációs rendszer vagy bármi más, mindaddig, amíg működik és jó tulajdonságokkal rendelkezik ». És miért kell UNIX-nak vagy UNIX-szerűnek lennie: Csináljon egyet és csináljon jól, valamit a systemd nem.
===========
Azonban a systemd természetesen nem összetettebb, mint ugyanazon összetevők korábbi megvalósításai. Ez egyszerűbb és kevésbé redundáns »
Kevesebb redundancia? Megkérnek, hogy telepítsen MÁSIK syslogot a sima szöveghez, és távoli naplózásra kérték, még mielőtt a systemd-journald-remote létezett volna, vagyis gyártásba helyezték anélkül, hogy az rsyslog függvényében távoli naplózást tudnának végezni , valami olyan alapvető, mint a központosított bejelentkezés. Ennek ellenére nem rendelkezik azzal a képességgel, egy egyszerű logikai értékkel, hogy jelezze, ha bináris vagy sima szövegben akarjuk a kimenetet, és ha binárisan fog használni, akkor miért nem valami berkeley DB néven, hogy olvasható legyen bármely UNIX vagy Linux rendszerről?
Egyszerű? nézd meg, mennyire egyszerű: http://wiki.gentoo.org/wiki/Comparison_of_init_systems
Nézze meg a kód- és fájlsorok mennyiségét.
=========================
"Ez nem engedi, hogy shell szkripteket használjak"
Ez hamis, de ismét félre van ábrázolva, nem kritizálják azért, mert nem engedélyezi a bash szkript használatát, hanem azért, mert nem használja őket a szolgáltatások elindításához, így nem módosítható, feltörhető és rugalmas, mint az upstart vagy a sysvinit. Hackelhető alatt pedig harcodolt értem.
============================
Még mindig azt gondolja, hogy:
1.- Nincs semmi okom
2.- Nem olvastam semmit és tálib vagyok?
Kíváncsi vagyok ... valóban bíznom kell abban, amit Lennart mond? Ha valaki semleges azt mondja nekem, bizonyos dolgokat figyelembe vehetek, de ez nekem ugyanolyan ízű, mint a Red Hat által közzétett valami a Systemd védelmében
Hú, amíg valaki a környéken nem mond valami ésszerűt, és nem csak félelmet és félretájékoztatást.
A cikk Lennart írásának spanyol fordítása.
Semmi sértés, de úgy tűnik, hogy a fordítást a Google Translator béta verziója készítette ... some Nehezen értettem néhány bekezdést; amúgy az információt értékelik.
@ Charlie-Brown, azért, mert Lennart nem tudja, hogyan fejezze ki magát angolul nagyon jól. Ez mennyire csúnya, ha elolvassa az eredetit.
A megadott okok helytállóak, azonban úgy gondolom, hogy egyesek további kérdéseket is felvethetnek. Mindenesetre ajánlom azoknak, akiknek lehetőségük van rá: keressék meg az információ eredeti forrását http://0pointer.net/blog/projects/the-biggest-myths.html (sajnos egyesek számára angolul), amely sokkal teljesebb és eljut egészen 30 okig, hogy miért tartják kedvezőnek a SistemD alkalmazását.
Az általad említett cikket a Systemd készítője írta. Nyilvánvaló, hogy nála senki sem védi meg a munkáját, azonban meghívom Önt, hogy nézze meg ezt a videót http://hackingthesystem4fun.blogspot.com/2014/12/systemd-journald-centos-7-totally.html és elmondják nekem a következtetéseiket. Nem mondok többet.
Az elav a naplózási naplók kérdése, amelyek bináris fájlban vannak, az egyik legtöbbet kritizált pont, még maga Linus is felvetette, amikor egy jelentésben elismerte, hogy a systemd nem is volt olyan rossz. Linus maga is elmagyarázta, hogy létrehozhat egy szkriptet a naplóadatok felvételéhez és egyszerű szövegbe helyezéséhez.
Szintén a systemd lehetővé teszi a napló bináris méretének konfigurálását, ezzel csökkentve az esetleges meghibásodás kockázatát.
Valójában az általad idézett művészet nagyon komolytalan, mivel nincs benne objektív tárgyi utalás, és még azon is elgondolkodtat, hogy az általa bemutatott hiba valós-e vagy hamis (kösd le a saját szoftvert, hogy ez adja a hibát).
az összes programban vannak hibák valamikor, de úgy tűnik, hogy mindig a macska ötödik lábát keresik, hogy valami hibát találjanak a systemd-ben.
Például: a debianban eldöntötték, hogy a systemd lesz az alapértelmezett init, de ez nem akadályozza meg a sysvinit vagy az openrc vagy az upstart használatát, és jól fogod mondani, hogy igen, de nem tudod teljesen eltávolítani a systemd-t, és a válaszom az lenne, ugyanaz, mint a debian wheezy-ben történt, ahol futtathatja az openrc-t, a systemd-t vagy az upstart-ot, de sysvinit alatt
PS: Nem akarom elképzelni, hogy milyen őrültek lesznek a kdbus-szal és annak integrációjával a systemd-vel a linux kernel szintjén http://kroah.com/log/blog/2014/01/15/kdbus-details/
Ha lehet. Továbbá azt tervezem, hogy hivatalosan kivonulok a Systemd-vel kapcsolatos megbeszélésekből. Bármi történjen 🙂
@rolo a kudarc dokumentálva van, több hibajelentéssel is előadták, bemutatnak neki egy videót, és most azt mondják, hogy be van csalva. Ha biztos akar lenni benne, kövesse a lépéseket, és nézze meg, mi történik. Most itt van további információ az ügyről, feltalált hibák? Nem hiszem.
https://bugzilla.redhat.com/show_bug.cgi?id=958321
https://bugzilla.redhat.com/show_bug.cgi?id=1054929
https://bugzilla.redhat.com/show_bug.cgi?id=1055570
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=74280
https://bugs.archlinux.org/task/32191
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=64116 (Lennart és nagyszerű magyarázatai)
https://bugzilla.redhat.com/show_bug.cgi?id=974132
https://bugzilla.redhat.com/show_bug.cgi?id=1157350
Amit a videó megemlít, az bizony kíváncsi. Fejlesztőként mindig azt mondják nekünk, hogy egy részletnek nem szabad kihatnia a teljes rendszerre / programra, például ha az adatbázisba történő lekérdezés meghiúsul, miért összeomlik a teljes program? Ugyanez a helyzet a SystemD-vel is, ha nem sikerül, mert mások megbuknak, nem tudom, mennyire sikerült. Nyilvánvaló, hogy vannak olyan esetek, amikor a meghibásodás gyakorlatilag a rendszer meghibásodása, de minél belsőleg izoláltabbak a program tulajdonságai, annál jobb lesz a termék.
A szoftverek gyenge oldaláról való támadás nem újkeletű, inkább egy nagyon gyakori gyakorlat, és hogy valójában minden programmal meg kell csinálni, tehát ha látjuk, hogy a SystemD beleesik a naplóba, az érvényes bizonyíték arra, hogy a SystemD nem az, ami mondta vagy elhitette vele.
Minél több dolog válik függővé a SystemD-től, annál rosszabb lesz a helyzet. Ha egy eszköz felszerelése előtt nem sikerült összeomlani a rendszert, akkor most nem biztos, hogy minden rendben van.
A SystemD nem rossz, nem utálom, de nem ezt hinnéd sokan. Vannak előnyei, de semmi olyan, amire az Upstartnak nem volt vagy lehetett volna, természetesen a Canonical nem volt érintett, és senki sem akart odafigyelni.
Üdvözlet.
de abban a videóban soha nem tudom, hogy a rendszer összeomlik. az a típus, amit csinál, a napló info bináris változatát módosítja a hiba generálásához, de a lényeg az, hogy minden alkalommal, amikor belép a systemd-be.
Megértésem szerint, ha korlátozza a napló bináris méretét, amikor eléri a határt, létrehoz egy másikat és így tovább. csökkentve az összes adat sérülésének lehetőségét.
Tisztázzuk ... Kinek jutna eszébe a naplófájl módosítása is? xD
@Jorgicio 4. december 2014, 6:03
Tisztázzuk ... Kinek jutna eszébe a naplófájl módosítása is? xD
Ha ironikusan mondtad ... rendben, megértettem :)), de ha valóban kérdezted, megadom a nézőpontomat.
Számomra egyértelmű, hogy ez nem hiba, hanem funkció !! Az elképzelés az, hogy ha a távoli hozzáférés során fokozódnak a jogosultságok, akkor azoknak, akik beleegyeznek a napló törlésébe, egyszerűen szerkesztéssel, hogy megrontják, és a systemd sérültként törölje, és így megszabaduljon a felismeréstől abban a távoli hozzáférésben.
Mondd paranoid módon, de nincs más gondolkodásmódom ... ez nem hiba, hanem jellemző, és ezért nem fogadják el a hiba kijavítását.
uff most minden linuxos blog 200 cikket tesz a systemd-ről, olyannyira, hogy már szinte az összes érvet ismerem az xD ellen és mellett.
és apránként meggyőztek néhány anti-sistemd érvet, amelyek közül láttam (ha valami baj van, kérlek, javíts ki)
Még egy cikket is láttam arról, hogyan lehet összeomlani az egész rendszert bináris napló szerkesztésekor, és hogy nem ad információt arról, hogy a fájl sérült.
a naplók egyértelműsége
egy fejlesztői csapat, amely gyakran figyelmen kívül hagyja a hibabejelentéseket
Az, hogy ekkora és annyi mindent tartalmaz egy init belsejében, sokkal instabilabbá teszi a rendszert, és ha olyan hibákat adunk hozzá, mint a fent említett, akkor a rendszert olyan stabilitás nélkül teszi meg, amelyet a linux annyira jellemez.
modulárisnak mondják, de egyes részei nem működhetnek ugyanazon rendszer más részei nélküld
egy olyan fejlesztés, amely hosszú távon függőségeket generál a programozás során, így a gnome-hoz hasonló szoftverek alig hordozhatók a systemd nélküli rendszerek felé.
lecseréli azokat az alkatrészeket (networkd, logind stb.), amelyek évek óta dolgoznak és kapnak karbantartást, és új szükségletek nélkül cserélgetik azokat, anélkül, hogy sokkal több hibát tartalmazna.
Attól kezdve, hogy Arch-alapú disztribúciókat (Manjaro, Bridge Linux, Antergos) használok, amelyek nyilvánvalóan a systemd-t használják, azt kell mondanom, hogy nincs panaszom a használatával és kezelésével kapcsolatban. A szolgáltatások elindítása egyszerű - még inkább a Bridge-ben, ahol a bluetooth vagy a modemager alapértelmezés szerint le van tiltva. A hwdb.bin (https://bbs.archlinux.org/viewtopic.php?id=189536) Nem sok problémám volt. Nyilván nem hiszem, hogy mindenki véleménye lenne, de személy szerint nincs panaszom 🙂
Nem tetszik az ötlet, hogy az NSA-val (hátsó ajtók és amerikai irányítás) való együttműködéssel vádolt vállalat (Red Hat) olyan rendszert hoz létre, amellyel mindent ellenőriznek. Gyűrű mindannyiuk irányítására, a sötétben való megkötésre, ha szükséges ..
Másrészt el kell ismernem, hogy az Intel IRIS PRO 5200 jobban működik számomra, és szinte soha, ha már nem, a grafikus rendszerem nem szakad meg, amikor elindítom az openSUSE 13.1-et. És igen, minden jobb, sokkal gyorsabban indul és leáll. Hogy egy egyszerű felhasználó profitált nekem.
Kiemelem a fontos részt
Ha valaki kábítószer-eladással vádol, ön automatikusan drogkereskedő?
@juanfgs
Kábítószer-kereskedő nem .... cinkos igen.
Istenem ... megsértettelek, de a saját szavaid teszik helyetted.
Csak tisztázza, hogy a systemd meg van írva, és ezt kell megtenni.
Helyesírás
Igen, ez a systemd, nem pedig a D vagy a D rendszer, vagy akár a SystemD. És ez sem a d rendszer. Miért? Mivel ez egy rendszer démon, és Unix / Linux alatt ezek kisbetűvel vannak ellátva, és kis d betűvel vannak ellátva. És mivel a systemd kezeli a rendszert, rendszernek hívják. Ez ennyire egyszerű. De még egyszer, ha mindez túl egyszerűnek tűnik számodra, hívd (de soha ne írd!) Ötszázas rendszernek, mivel D az 500-as római szám (ez is tisztázza az V rendszerrel való kapcsolatot, igaz?). Az egyetlen helyzet, ahol megfelelőnek találjuk a név nagybetűjének használatát (de ez sem tetszik), ha egy mondatot a systemd-vel kezdünk. Magas ünnepeken azt is megírhatja, hogy sÿstëmd. De még egyszer: a Système D nem elfogadható helyesírás és valami egészen más (bár kissé illő).
http://freedesktop.org/wiki/Software/systemd/
Itt is? Ezt betetted a GUTL-be .. de ember, mindenki a Linuxot mondja, és nem a GNU / Linuxot, tehát a SystemD-nél is.
Azt mondom, hogy nem szükséges használni a naplózási rendszert vagy a cront, amelyet a systemD biztosít, ehhez vagy más alternatívához kövesse a syslog-ng és a cronie
Amióta aur voltam, a systemD-t használom az ArchLinuxban, és egyszerűbbnek tűnik a kezelése, mint a debian és a redhat származtatott formája, rengeteg konzolparancssal rendelkezik, amelyek megmentenek a szövegfájlok szerkesztésétől és egyszerűbbé teszik a parancsfájlok összeállítását. hogy az arch-ban mindent konzol telepít)
És nem utolsósorban a rendszer gyorsan indul, az arch-ban párhuzamosan indíthatta a szolgáltatásokat a rendszer indításakor, de kockázatos volt
Nekem az tűnik hibásnak a kérdésben, hogy a legtöbben pártolnak, vagy Ön pro-systemd vagy anti-systemd, és azt hiszem, hogy vannak jó és rossz dolgai, én felhasználó vagyok, és elkezdtem egy kicsit játszani a systemd-vel, valóban A jó dolog az, hogy az indítás gyorsabb és kevésbé bonyolult, mint a többi init, bár a folyóirat kiadása engem is nagyon zavar.
Megértem, hogy azok, akik valóban meg tudják mondani, hogy ez jó vagy rossz, a rendszergazdák vagy a téma szakértői, de számomra úgy tűnik, hogy a rendszerszintű felhajtás egy ideje ezelőtt abbahagyta valami technikát, és valami "show-stop" lett. részemről egy kicsit ellen vagyok, de nem tartom magam sem ellenzőnek, sem profinak
@KZKG_Gara
Úgy látom, hogy az itt kommentáltak nagy része megegyezik azzal, amit Lennart közzétett a blogján, pontosabban ebben a bejegyzésben: http://0pointer.de/blog/projects/the-biggest-myths.html.
Természetesen a bejegyzésnek bizonyos "pontosításai" vannak, és elhagyott bizonyos technikai tartalmakat annak érdekében, hogy könnyen emészthető legyen az információ azok számára, akik el fogják olvasni, de mi komolyak és őszinték leszünk, még akkor is, ha az igazság fáj: a systemd-nek sok olyan dolga van, amit Lennart tagad, hogy nincs, és még sok minden más. Ebben az értelemben részben elmagyarázom.
1.- Lennart azt mondja, hogy nem dagadt és nincs magas NIH-szindróma (itt nem találták meg). Ha igen, kérem, magyarázza el nekem: Miért kell az initnek hálózati vezérlést (systemd-networkd), dns (systemd-networkd), m-dns (systemd-networkd), naplókat (journaln), coredumps (systemd -coredump), hibakereséseket (systemd-coredump és journald), acpi (logind), privilégium eszkaláció (logind), az ntp vezérlése (systemd-timesyncd), a dev ellenőrzése (a systemd átvette az udev összes funkcióját), / dev / random (véletlenszám) vezérlése generátor) és a legújabb kontroll a TTY felett (systemd-consoled)? Nem léteztek olyan eszközök, amelyek ilyen célokra lettek létrehozva, hogy a systemd most hozzáadja a sajátját, kizárólagos hozzáféréssel (journald case)? Milyen logikus és elfogadható magyarázatot ad arra, hogy az init képes megtörni a kernel debugot és a cmdline-t? Adja hozzá a kdbus vezérléséhez, a következő IPC-hez, amelyet integrálnak a kernelbe. Biztosan itt fogják mondani nekem: «De telepíthet egy másik eszközt mindezek ellenőrzésére». És ha igaz, de sok ilyen eszköz csak a systemd által dobott adatfolyamot kapja meg, mint például a syslog és az rsyslog esetében, amelyek csatlakoznak egy olyan adathoz / adatfolyamhoz, amelyet a napló ad, hogy más eszközök LÁTHATÁK, hogy milyen naplóhajtót hajtanak végre , ez végül csak azt jelenti, hogy két eszközöd van, amelyek ugyanazt csinálják, és az egyik egy pandora doboza. (Kérjük, ne mondja el, hogy a kód ellenőrizhető, mert meghívok valakit, hogy "dohányozza" a napló kódját és annak keretrendszerét a systemd és egyéb kapcsolódó eszközökkel)
2.- Lennart azt is elmondja nekünk, hogy a systemd támogatja a SysV és LSB szkripteket. Ez úgyszólván "félig igaz" és "fehér hazugság", mert az az igazság, hogy a systemd-214 nem kínál támogatást a bash szkriptekhez, a SysV vagy az LSB-hez, és ez összefügg az adott verzió kiadási megjegyzéseivel.
3.- Milyen systemd nem hordozható? Ez egy másik vitatott kérdés. A BSD-ben ez nem működik jól, a BSD-ben nincsenek olyan csoportok a többi eszköz között, amelyeket a systemd-nek futtatnia kell. De ez egy systemd tervezési okból fakad, nem azért, mert nem hordozható. Amíg a BSD kernel nem éri el a támogatásához szükséges minimumot, a systemd nem fog működni ezen a platformon, és ez nem senki hibája, csak az, hogy a BSD nem érdekli, és Lennart sem. Ez ilyen egyszerű. A többi C könyvtár támogatása egy másik dolog, köztudottan a glibc problémák (csak készítsen egy kernelt kézzel, hogy lássa, milyen lehetőségek és megkerülő megoldások történtek e részletek elkerülése érdekében, különösen a glibc 2.3, 2.5 és 2.11 esetében. , többek között a glibc az évek során elhúzódott hibák között), de ezzel nem ér véget, nem ér véget, maga Lennart azt mondta, hogy ő inkább saját libc könyvtárat hozott létre, mert sokkal gyorsabb csoportja számára mint a már létrehozott (és mellesleg dokumentált) kód olvasása, de ez nem áll meg itt, azt tervezik, hogy eltávolítják a glibc-t, és a libc-jüket nem csak a systemd-hez, hanem a Fedorához is használják, ezáltal szabványossá téve a összes csomagjuk felépítése. NIH Hol? Úgy tűnik, hogy a jó öreg Lennart szeret trollkodni és nagyokat.
4.- Ez a systemd nem monolitikus, mert 69 binárisra van felosztva. Igen, ez vitatható. A systemd-nek 69 bináris fájlja van, amelyek különböző feladatokat hajtanak végre, de ezek a bináris fájlok továbbítják a feladataikat a systemd-nek, így ha valaki nem sikerül, akkor a rendszer megszakításának esélye meglehetősen drámai módon megnő. Ez jól dokumentált, a hibabejelentések bővelkednek ilyen problémákban és még egyszerűbb problémákban, valójában ostobán egyszerűek. A systemd több száz bináris fájlra bontható, de mindaddig, amíg a rendszermagja irányítja, a törés kockázata folytatódik és növekszik, és ha nem hisz nekem, olvassa el a hibabejelentéseket és érezzen jól.
Ne feledje, hogy itt nem kommentáltam semmit, ami a systemd szemét, csupán pusztán "technikai" megjegyzéseket tettem (nyilvánvalóan a technikai dolgokról való beszéd nagyon összetetté válik) és érvényesek, amelyeket az interneten könnyen hozzáférhető információk támasztanak alá. Most: Mire van szüksége a Linuxnak egy standard initre? Igen, minden bizonnyal valami nagy értéket jelentene a közösség számára. Milyen systemd a megoldás? Nem, bár közel van, minden bizonnyal sok pozitív dologgal rendelkezik, de vírusos elterjedése és számos dolog növeli annak a kockázatát, hogy mi lehet rossz, és végül káros lehet a közösségre.
PS: Olyan anyagot hagyok ott, ahol megerősítheti, amit mondok, elolvassa, elég szemléletes lesz, és látom, hogy nem tartalmazok blogokat vagy ilyesmi, tiszta személyes és alapos kritika. Üdvözlet.
http://lists.freedesktop.org/archives/systemd-devel/2014-June/019925.html
http://cgit.freedesktop.org/systemd/systemd/commit/?id=ce7b9f50c3fadbad22feeb28e4429ad9bee02bcc
http://lists.freedesktop.org/archives/systemd-devel/2013-November/014808.html
https://bugzilla.redhat.com/show_bug.cgi?id=1057883 (@elav talán úgy érzi, hogy azonosulsz)
https://code.google.com/p/d-bus/source/browse/kdbus.txt
https://github.com/gregkh/kdbus
http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html
Ámen testvér .. ámen ..
Még mindig nem látok érvényes okokat arra, hogy ne fogadjam el a systemd-t. Egyszerűen félelemmel értelmezi a látottakat, ami túlzásokhoz vezet. Sem egyértelmű és jól körülhatárolható előnyök, sem hátrányok.
Ezen felül az integráció lehetővé teszi a szabványosítást, amelyről még beszélt is. Nemcsak a Red Hat működik a systemd-n, hanem különböző cégek és önkéntesek más disztribúciókból.
Szerintem az a hiba, hogy a systemd működését nem tanulmányozzák megfelelően.
Megalapozott okokat látok Yukiteru elemzésében. Figyelje meg, hogy a félelem helyett szigorúságot, precizitást és egyértelműséget látok. Biztosan szemorvosi kérdés.
Ez nem a félelem (nem félek egy darab kódtól) és ezek sem túlzások (mindaz, amit itt mondtam, dokumentálva van, és elegendő információt adtam át, amely ezt alátámasztja, olyan információ, amely mellesleg kikerül a listákból és az elme / hang Lennart saját kézírása, és nem egy blogger megjegyzései alapján), ez a VALÓSÁG.
A systemd mindent megtesz és még sok minden mást, és ez valami GONDOS (más koncepció, mint a félelem), mert minden bizonnyal hozzárendeléseket igényel, és olyan dolgokat végez, amelyeket jelenleg más eszközökkel is meg lehet valósítani, és amelyek egyébként jobban működnek és stabilabbak . A systemd nagyon Windows-szerű, és ezt nem lehet elrejteni, csak tudja, mit csinál a userinit.exe, svchost.exe, smss.exe és más függőségek, és hasonlítsa össze őket a systemd-vel, a hasonlóság olyan nagy, hogy rossz ötlet. Most bizonyára a systemd jobb minőségű lehet, mint a Windows-os megfelelője (vagy ennek az ellenkezője történhet, senki sem tudja, hacsak nem a Microsoft számára programozol), de nem vádolhatsz engem TÚLHATÁLT és FÉLHETŐSÉGGEL, ha elolvasod magad Lennartot. egy teljesen új C könyvtár létrehozása, mert eleged van Glibc-ből, és napózni, dobja be a kis és jelentéktelen tippet, hogy az a libc használható az összes Fedora-csomag felépítésére. És ha úgy gondolja, hogy ez hazugság és túlzó vagyok, akkor hagyom neked az üzenetet ezen a linken: http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html (angolul)
Most mondd meg, hogy túlzás-e mindezek előtt azt mondani, hogy ha egyszer Linus úgy dönt, hogy a CONFIG_VT, ahogy van, akkor ki kell lépnie a kernelből (sokáig fennálló helyzet) és át kell adnia a felhasználói térnek, ne történjen olyan őrült dolog, mint ha a systemd-consoled szinte minden Linux telepítés erős függősége lenne (valaminek kezelnie kell a virtuális gépeket, nem gondolod?), ez nem tenné a figyelem középpontjába a különböző, nem systemd disztrókat. egy kapcsoló. Ha úgy gondolja, hogy ez egy szakasz, hadd mondjam el, hogy fogalma sincs arról, mire képes és mit csinál Lennart, mivel legújabb változásai befolyásolják az udev villa, a Gentoo eudev fejlődését, és fenyegetéseivel továbbra is ezt fogja tenni az asztal alatt (később panaszkodni, mint a Google+ szolgáltatásban)
@xiep többet nem tudok egyetérteni a kommenteddel.
Che Yukiteru, hosszú megnyilatkozása mellőzi azt a tényt, hogy a libc-hez linkelt e-mail április hülye vicc, nézze meg a lábjegyzetet és nézze meg a dátumot (március 31., valószínűleg Lennart időzónájában április 1.)
Gyakorold az angol-fu-t, mert vizes és megkérdőjelezi az összes "kutatásodat".
@juanfgs úgy tűnik, te vagy az egyetlen, aki olvas, legalábbis tapsolok neked ezért, de el kell olvasnod valami nagyon fontosat, ami a kommentemben szerepel, nem baj, hogy ide teszem:
»NIH Hol? Úgy tűnik, hogy a jó öreg Lennart szeret trollkodni és nagyokat. "
Nem hiszem, hogy ártatlan okból írta, tisztában volt azzal a ténnyel, hogy ez egy újabb Lennart-vicc volt az áprilisi bolondnapra (rossz hangulat), valamint a /, / stb stb. Linux. 🙂
PS: Köszönöm, de nem kell gyakorolnom az angolt, 6 éves korom óta használom a nyelvet
aaahh és minden más igaz, igazold 🙂
Ez egyenesen szenzációhajhászás, azt mondod, hogy tényeken alapszik, de a valóságban követed a sejtésedet, miszerint a srác rossz, és el akarja venni a világot, és a tényeket elcsavarod, hogy tükrözzék a beszédedet. Ez engem nagyon zavar a rendszerellenes embereknél, nem vagdalkoznak szavakkal, amikor a tények elforgatásáról és féligazságokról van szó, természetesen a véleményükkel terhelve.
Az én "ökölszabályom" ezekben az esetekben egyszerűen a következő logikai bontás, abból indul ki, hogy
- Webfejlesztő / asztali alkalmazás vagy kli vagyok
- Még soha nem írtam init rendszert.
- Nem vagyok a disztró fenntartója.
ellenőrizze, hogy a beszélgetőpartner rendelkezik-e:
- létrehozott egy init rendszert
- a disztribúció init rendszerének aktív fenntartója
és a valóság az, hogy a legtöbb anti-systemd nem teljesíti ezt a tesztet, mégis egy maroknyi emberről van szó, akik valamilyen oknál fogva többet tudnak, mint a mögöttük álló emberek: Debian, Fedora, Archlinux, a Linux kernel, az egész GNOME projekt, valószínűleg a A KDE projekt is, mivel nem panaszkodtak a systemd, SUSE és sokáig stb.
Ennek ellenére a mérgező és vitriolos beszéde az egyetlen dolog, amit elér, az a széthúzás, a problémák és mások előidézése. Ilyen az a pont, hogy alig várom, hogy végre átálljanak a BSD-re, mivel fenyegetőztek már az Xorg, a NetworkManager, a PulseAudio részéről, és nem tudom, puszta technikai tudatlanság miatt, vagy azért, mert nem panaszkodnának emiatt.
@juanfgs, kifejezetten erről a szaváról fogadom:
«És a valóság az, hogy az anti-systemd legtöbb nem felel meg ezen a teszten, így is van egy maroknyi ember, aki valamilyen oknál fogva TÖBBET TUD, mint a mögöttük álló emberek: Debian, Fedora, Archlinux, a Linux kernel, az egész GNOME projekt Valószínűleg a KDE projekt is, mivel nem panaszkodtak a systemd, a SUSE és sokáig.
Ennek ellenére a mérgező és vitriolos beszéde az egyetlen dolog, amit elér, az a széthúzás, a problémák és mások előidézése. Ilyen az a pont, hogy alig várom, hogy végre áttérjenek a BSD-re, mivel már az Xorg, a NetworkManager, a PulseAudio részéről fenyegetőztek, és nem tudom, puszta technikai tudatlanság miatt, vagy azért, mert nem panaszkodnának emiatt. "
Tehát Nektek SZERINT, mindannyian rendszerellenesek vagyunk mérgezőek és vitriolosak, hogy az egyetlen dolog, amit elérünk, a széthúzás, a problémák és így tovább. Hadd mondjam el, hogy ez a legnagyobb felháborodás, amit itt elolvastam. Nem tudom, miért zavarja a pro-systemd, amikor egy rendszer strukturális problémái felmerülnek, amelyek nyilvánvalóan egy bizonyos ponton hatással lesznek rájuk, mert lehet, hogy most velük nem történt semmi, de valamikor mégis megteszik. majd néhány anti-systemd emlékezteti őket a sokszor mondott szavakra, és senki sem állította meg őket, és talán más anti-systemd megadja nekik a kezüket.
Én személy szerint nem szeretem a systemd-et, de ez nem azt jelenti, hogy nem használok init-et, muszáj, mert pontosan a munkám során, ha hozzá kell érnem egy géphez azzal az inittel, ismernem kell a kezelését. azt. Személy szerint én is használom, amióta az Archlinuxhoz kerültem, sőt még Debianban és Gentooban is, szóval ne mondd, hogy a látásmódom elfogult, ha nem használom a systemd-t, én is használtam, és tudom, milyen béna. , és ha segítenem kell valakinek itt a fórumon DesdeLinux vagy az IRC-n vagy a Debian listán (ez az a disztró, ahol a leghosszabb ideig voltam, és a mai napig használom a munkámban) szívesen csinálom, mert pontosan ha tetszik valami a Linux közösségben, az az, hogy annak ellenére, hogy a különbség mindig segítség.
Most, hogy BSD-re váltsak, lehetséges, de csak akkor fogom megtenni, ha a systemd annyira virulenssé válik, hogy nem teszi lehetővé más lehetőségek használatát, addig is maradok a Linuxon, letiltva az összes őrületet, beleértve a sokat is. Csoportosítja a dolgokat.
!=
Ismét csavarja a szavakat, hogy megfeleljenek a beszédének. Nagyon jó anyag egy politikus / újságíró számára.
Tisztázom, a problémám nem az, hogy a Systemd technikai problémáit emlegetik, a lényeg az, hogy sokszor hazugságokkal töltik fel beszédüket, nevezetesen:
Ha a systemd arra kényszerít, hogy használjon egy mikrohttpd szervert (ami egy opcionális modul, amelyet alapértelmezés szerint NEM telepítettek), akkor ha a systemd egyetlen bináris, akkor a systemd bezárásra kerül, mert a lennart a Microsoft fizeti, hogy a bináris naplók Ezek kötelezőek. Senki sem akarja a rendszert, és annak elfogadását politikai lobbi végzi.
Ez sokkolja a hazugságokat. Ha ésszerű vita lenne, megéri, de ez csak a jó FUD.
Hogy nem tetszik, nekem tökéletesnek tűnik, nem szeretem a sok szoftvert, még a programozási nyelveket, a disztribúciókat és másokat sem, de nem találok ki ilyesmit, és nem is vagyok hajlandó olvasni, amit olvasni akarok, és személyes érzéseimmel terhelem állításaimat, hogy ezzel károsítsam az azt fejlesztő emberek imázsát.
@juanfgs sajnálom, de nem én nevezek bizonyos embercsoportot "mérgezőnek és vitriolosnak" egyszerűen azért, mert nem szeretik a szoftvert.
Ismét csavarja a mondatokat, hogy áldozat legyen.
@juanfgs ismét mondom neked, amit te mondtál, ellenőrizd a szavaidat, nem tévesztem el a szavaidat, csak készítettem egy másolatot / beillesztést a szavaidból az 59. megjegyzésben.
Idézem a szöveges megjegyzésemet, amit újra el kell olvasnod, te vagy, mert nem akarod megérteni, vagy nem tudsz vitatkozni. Kiveszed a dolgokat a kontextusból, és úgy értelmezed őket, ahogyan neked éneklik. Tehát, ha úgy dönt, hogy egy olyan világban szeretne élni, ahol sértettnek érzi magát, mert vitatják az érveit, Lennart, a Red Hat és a Microsoft üldöz, akkor ez azért van, mert Ön ezt hiszi.
Röviden itt, mert rájövök, hogy nem vagy ésszerű ember, mert nem akarsz megérteni, hanem a saját belátásod szerint akarod értelmezni a dolgokat.
Ha sértődni akarsz, sértődj meg, de ez a te problémád, nem a világ többi része.
@juanfgs Engem nem zavarnak a kommentjeid, tényleg nem látok okot, vitatkozunk, civilizált emberek vitatkoznak anélkül, hogy emiatt kellene bajlódniuk (ezt gondolom).
Most, ha szeretnél címkézni, előítéletet mondani (vagy bárhogy is nevezheted) az embereknek beszédeikért vagy cselekedeteikért (talán el kellene olvasnod a 64. számú megjegyzésemet, és meg kell mérned annak szélességét), akkor ez a problémád, korlátozd magad ezekre a cselekedetekre magad felé, és hagyj ki másokat abból a táskából.
Üdvözlet.
"A legtöbb anti-systemd", "szinte az összes", "minden", "a rendszer-ellenes" valamilyen része "... letérünk, Mariano, letérünk. Jelen esetben: Sehol nem látom, hogy Yukiteru szenzációs beszédet mondott volna sejtelmekre alapozva (elemzésére ily módon hivatkozva valóban van valami csavarodva), éppen ellenkezőleg, szilárd érveket dolgozott ki a systemd hátrányairól a a levelezőlistákból és a hibajelzésekből vett megfelelő kérdések és anyagok (valamint udvarias és civilizált módon). Valószínűleg emiatt irritál néhányat, és az első megjegyzéskor megtámadják, hogy hiteltelenné tegyék és diszkvalifikálják (ezúttal mérgező módon).
Ha azt látja, hogy a legtöbb anti-systemd diskurzus mérgező és vitriolos, amit néhány rendszerpárti diskurzusban látok (nem tudom, hogy többség vagy kisebbség-e), azok hisztériája és üldözése, pontosan megalapozott érveket hoznak fel a zajok közepette. Hogy az én országomban zaklató ellenvéleménynek nevezzük.
Jól megy neked a systemd? Remek, nekem nagyszerűnek tűnik, de azok, akik nem gondolják ugyanezt, hadd fejezzék ki fenntartásaikat (lehet, hogy az operációs rendszer nem ugyanúgy működik).
Üdvözlet
Ó, mellesleg, miért robbantanak ki bármelyik systemd hibát az egész alkatrész elpazarlásáig, de másokat, például a GCC-t, a glibc-t vagy akár a kernelt sok hibájuk miatt nem kritizálták eddig?
Te magad mondtad, glibc már régóta húzza a problémákat. Az Llvm idővel bebizonyosodott, hogy előnyei vannak a GCC-vel szemben. És itt nem ugyanazt a kritikát látom.
Miért ne tenné ugyanezt más projektekkel?
Ez egyszerűen kollektív és irracionális félelem számomra.
A Glibc hibáit senki sem rejtheti el, vannak hatalmas Glibc hibák, amelyek befolyásolják a kernelt és a futtatható fájlok százait. A különbség a Glibc és a systemd között az, hogy az előbbi egy olyan bázis, amelyből ezrek szoftverprojektek átalakíthatók bináris fájlokká, míg a systemd egy init, amelynek célja egy stabil, bevált és gyakorlatilag tévedhetetlen darab. Nem csak, hogy a Glibc-nek alkalmazkodnia kell több száz különböző hardverarchitektúrához (CPU), a különböző optimalizálási jelzőkhöz és a CPU egyedi jellemzőihez, a szoftveroptimalizálás különböző formáihoz, ami sokkal nehezebb és nehezebb munka, mint a systemd-nél. Nem igazán látom a két, azonos léptékű projekt összehasonlításának bemutatását.
Ugyanez vonatkozik a GCC-re is, a GCC egy olyan fordító, amely egyébként sok nyelvet támogat (összesen 13 a nem hivatalos nyelveket számolva), és nagyon hasonló tulajdonságokkal rendelkezik, mint a Glibc, sok architektúrát támogat (70 architektúra a 4.9 verzióhoz), bináris optimalizálás zászlók, CPU optimalizálási zászlók és sok más szolgáltatás. Most ugyanazon a nehézségi fokon vannak, egy fordító egy init-szel. A válasz több mint nyilvánvaló, kezdve azzal, hogy a systemd C-ben van, és sok GCC-kód az assemblerben található, vagy az assemblert kell használnia ahhoz, hogy a dolgok binárisan működjenek, ami kissé „nehéz”.
Mik a GCC és a Glibc hibák? Biztos. Még Linus is megadta nekik a támadását, de a GCC-ben és a Glibc-ben van valami pozitívum, hogy a systemd-ben gyakran elfelejtik őket, vagyis hibát jelentettek, hibát láttak, hibát javítottak.
- kérem, magyarázza el nekem: Miért kell az initnek irányítania:
hálózatok (systemd-networkd),
dns (systemd-networkd),
m-dns (systemd-networkd), l
ogs (journaln),
coredump (systemd-coredump),
hibakeresés (systemd-coredump és journald),
acpi (logind), privilégium eszkaláció (logind),
ntp (systemd-timesyncd),
dev (a systemd átvette az udev összes funkcióját),
de / dev / random (véletlenszám-generátor)
TTY (rendszer-konzolos)?
Egy 100000 téma megismétlődik és megismétlődik, amit el kell mondanod, hogy a systemd nélkülük is képes működni, valójában a debianban ők sem fele azoknak, akiket megemlítesz
hasonlóképpen csak tág megközelítésének jellemzője
lennart: Nos, a systemd sok különböző összetevőre osztja a tennivalóit (manapság 90+ bináris fájl). Mindegyik a lehető legkevesebb kiváltsággal fut.
Úgy képzelem, hogy ez nem túl sok különbség a coreutils esetében, amelynek szintén nagy része van egy csomagban. És a coreutils valószínűleg az egyik nagy projekt, amely miatt a Linux UNIX-szerű operációs rendszernek érzi magát, igaz?
De igen, a systemd összetettebb, mint a sysvinit, nem kérdés. Az elmúlt 40 évben a számítástechnika sok minden megváltozott, és sokuknak valójában egy bizonyos szintű bonyolultságra van szükség ahhoz, hogy megbirkózzanak ... Ezt nagyon kevéssé lehet megkerülni.
Mert nem érti ezt a kompromisszumot a freebsd, amely pontosan ugyanazt csinálja, de eszközeivel és anélkül, hogy engedélyezné mások használatát, ami a systemd esetében nincs.
- Nem léteztek már SOK olyan eszközök, amelyek ilyen célokra lettek létrehozva, hogy a systemd most hozzáadja a sajátját, némelyikük kizárólagos hozzáféréssel rendelkezik (case journal)?
Nem fogom tagadni, hogy a naplótéma bináris fájlba menti az információkat, amit a leggyengébb védeni, de ez még nem a világ vége, hanem egyszerű szövegben is elmenthetők
- Milyen logikus és elfogadható magyarázatot ad arra, hogy egy init képes megszakítani a kernel debug-ját és a cmdline-t?
Hmmmmmmmmmm …………………. törje meg a kernelt ... 5000000 dolog megtörheti a kernelt
- Adja hozzá a kdbus vezérléséhez, a következő IPC-hez, amelyet integrálnak a kernelbe.
Lennart szerint ennek pozitív kapcsolata van a fejlesztők számára, és a systemd eszközöket fog hozni a dbus megnyitására az adminisztrátorok számára, napló- és networkd bus interfészeket is ad
- Biztosan itt fogják mondani nekem: "De telepíthet egy másik eszközt mindezek ellenőrzésére." És ha igaz, de ezek közül az eszközök közül sok csak a systemd által dobott adatfolyamot kapja meg, mint például a syslog és az rsyslog esetében, ... .. ez csak azt jelenti, hogy két eszköze van, amelyek ugyanazt teszik, és az egyikük az egyik Pandora ládája. (Kérem, ne mondja meg, hogy a kód ellenőrizhető, mert meghívok valakit, hogy "dohányozza" a napló kódját és annak keretrendszerét a systemd és egyéb kapcsolódó eszközökkel)
itt lépünk be az összeesküvés elméletbe !!!!! sovány ingyenes szoftver, semmi nincs rejtve
3.- Milyen systemd nem hordozható? Ez egy másik vitatott kérdés. A BSD-ben ez nem működik jól, a BSD-ben nincsenek olyan csoportok a többi eszköz között, amelyeket a systemd-nek futtatnia kell. De ez egy systemd tervezési okból fakad, nem azért, mert nem hordozható. Amíg a BSD kernel nem teljesíti a támogatásához szükséges minimumot, addig a systemd nem fog működni ezen a platformon, és ez nem senki hibája, csak az, hogy a BSD-nek nincs érdeke, és Lennartnak sem.
Nos, ez nem teljesen helyes, a bsd fejlesztői valami hasonlót tesznek a systemd-hez, amelyet Lennart maga is kiemelt a g + fiókjában
https://plus.google.com/115547683951727699051/posts/g78piqXsbKG
https://www.youtube.com/watch?v=Mri66Uz6-8Y
4.- Ez a systemd nem monolitikus, mert 69 binárisra van felosztva. Igen, ez vitatható. A systemd-nek 69 bináris fájlja van, amelyek különböző feladatokat hajtanak végre, de ezek a bináris fájlok továbbítják a feladataikat a systemd-nek, így ha valaki nem sikerül, akkor a rendszer megszakításának esélye meglehetősen drámai módon megnő. Ez jól dokumentált, a hibabejelentések bővelkednek ilyen problémákban és még egyszerűbb problémákban, valójában ostobán egyszerűek. A systemd több száz bináris fájlra bontható, de mindaddig, amíg a rendszermagja irányítja, a törés kockázata folytatódik és növekszik, és ha nem hisz nekem, olvassa el a hibabejelentéseket és érezzen jól.
Ha sysvinit programot használ, és a TTY dev acpi ntp-je megszakítja a rendszer hibáit is, ne legyen rémisztő.
A monolit ingyenes, és nem mond semmit
@rolo
Most sorolja fel, melyek azok a disztrók, amelyek a systemd-t vették és külön csomagokban hozták létre azt a 90 bináris fájlt, ez 91 csomag lenne a systemd-vel.
És a systemd telepítésekor nem kér tőlem a 90 csomag egyikét sem függőségként.
Komolyan, és ismét ragaszkodom ... Kérjük, adja át a –configure-help opcióit, hogy 91 csomagot szeretnék készíteni kézzel, make-el.
Nincs rosszabb vak, mint az, aki nem akar látni ... fiúk ez a víz és az olaj, úgy tűnik, még mindig vannak makacs emberek, akik nem látják a valóságot annak, ami utána van redhat.
@rolo Azt akarom, hogy telepítsd a systemd-t, távolítsd el a journald, systemd-udev és coredump programot, és használd az olyan opciókat, mint az eudev és a syslog, hogy megtudd, tudsz-e.
Ez a megjegyzés nem tudott komolyabban megnevettetni, meghalok. 😀
Komolyan mondom, hogy tényleg azzal a problémával küzdenek, hogy egy kicsit elolvasnak, ahelyett, hogy a gerendával a szemükben ragaszkodnának.
Ezenkívül senki sem felejti el, hogy Kay Sievers nemcsak megszakította a kernel cmdline-ját, hanem le is akarta zárni, elvégre "generic is generic".
Más szavakkal, ön szerint az a tény, hogy két folyamat továbbítja az információt, annyira összekapcsolja őket, hogy az a tény, hogy az egyik kudarcot vall, a másikat nagy valószínűséggel meghiúsítja ... melyik szoftverfejlesztési elméletről kapta ezt? Egyetértek @pamp-szel, hogy irracionális és elfogult félelemtől beszélsz.
És a másik nagy kérdésed, miért kell a systemd-nek ennyi mindent irányítania? Egyszerű válasz: mivel a sysvinit és a Linux kernelben nemrégiben bevezetett összes többi init előnye pazarolódik, mindaddig, amíg senki nem helyezi őket felhasználásra a felhasználói térben, addig "fel vannak dühítve" (ahogy Kubában mondjuk ... nos , pazarlás) senki nélkül használom őket, és nagyon jó előnyökkel járnak a hardver erőforrások (CPU, RAM, I / O stb.) hatékony felhasználásában, beleértve a csoportokat is. Pontosan az, hogy a systemd mit tesz, a Linux kerneljének ezeket a jó szolgáltatásait a felhasználó szolgálatába állítja, de ehhez neki kell elindítania ezeket a démonokat.
Azt hiszem, rosszul olvastál és elemeztél (fontos az elemzés), vagy csak esélyt sem adtál erre. Az, hogy két folyamat átadja az információkat, nem okozza a rendszer megszakadását, azonban ha olyan bináris fájljaink vannak, amelyek dinamikusan működnek, például hálózati vezérléssel, naplókkal vagy coredumpokkal, közvetlenül az init felé továbbítják az információkat, akkor a dolgok rosszul alakulhatnak, és rosszul is fognak működni, mert Ha a bináris fájlok egy része megszakad, akkor sokkal nagyobb az esélye a többiek megtörésének, és ez meglehetősen reális, és megtörtént, a kernel cmdline nemrég összeomlott, az Nvidia devs által okozott acpi problémák a systemd-212-nek köszönhetően, ami csak egy minta, amit mondok.
@Dariem
Ha nem tudja ezeket a bináris fájlokat egyes csomagokba összeállítani, akkor arra kényszerít, hogy mivel telepíteni akar egyet, telepítenie kell mindet, telepítésükkor kiderül, hogy olyan csomagokra lép, amelyek nem telepíthetők, mert az alkatrészek A systemd csoportjai elfoglalják azokat a helyeket.
Mi értelme van egy nagy futtatható fájlt több kisebb futtathatóra felosztani, ha a végén nincs mindegyikhez olyan csomag, amely lehetővé tenné külön-külön telepítést.
Visszatérek, hogy általános kérést küldjek minden haladó systemd felhasználónak, hogy elmondjam, hogyan állítsam össze azt a 90 modult, és hozzak létre 90 csomagot, amelyeket ha kedvet kapok telepíteni, és különben az általam használt programokat használom.
Nagyon rossz tej mindez ... úgy tűnik, hogy a rendszer emberei szerint az összes gnu / linux felhasználó bolond.
A nyilvántartáshoz használom a gentoo tesztelést, és néhány hónappal ezelőtt átálltam a systemd-re, és nem tudtam a journald-szal, ez gyorsabban visszatért az openrc-be, mint amennyi a systemd-re váltáshoz kellett.
Ahhoz, hogy továbbra is láthassam, hogy mennek a dolgok a systemd-vel, van egy archlinuxom egy notebookon, amely hamarosan megjelenik a gentoo-nál ... biztosan stabil.
@ névtelen, csak azt szeretném látni, hogy a TTY kérdés hogyan fog alakulni a Linuxban. Amikor megjelenik a CONFIG_VT kód, a VT két jól differenciált részre (kernelspace és userspace) történő felosztása érdekében szükségünk lesz valamilyen eszközre a VT-k felhasználói terekről történő vezérléséhez, és ott a systemd-consoled erős függőségként játszhat, amely a többit húzza a disztribúciókat annak szükségességére, hogy telepíteni kell a systemd összetevőket, csak a rendszer működésének lehetővé tétele érdekében. Amit mondok, az nem túlzás, nagyon-nagyon nagy lehetőség, és valóban aggasztó. Vannak más projektek is, például a KMSCon, de ha a legtöbb asztali számítógép és disztró a systemd mellett áll, akkor a KMSConhoz hasonló dolgok gyorsabban meghalhatnak, mint sokan gondolják.
@Yukiteru 3. december 2014, 8:49
Nem félek ettől, Mr. Linus nem fogja eltávolítani az alapértelmezett beállításokat egyik verzióról a másikra, hanem az új rendszert ÚJként állítja be, és lehetővé teszi, hogy válasszon a régi és az új között.
A userspace részt illetően készíthet olyan csomagot, amely ezt függetlenül csinálja, ha a systemd csinálja, akkor miért nem tehetné meg még 50 további ember? Sőt, ennek különböző módjai arra késztetik a különböző terminálokat, hogy a USE-kkel különböző módon alkalmazzák aktiválni és inaktiválni szokásunk szerint.
Ugyanez vonatkozik a kdbusra is, hogy Linus a 3.19-ben beismeri, amint mondja, ez nem jelenti azt, hogy aktívnak kell lennie igen vagy igen.
Nagyon örülök az openbox + compton-nak, az asztali számítógépek számomra eltűnhetnek, hogy a legkevésbé sem fognak rám hatni.
@ anonim az a kérdés, hogy a CONFIG_VT eltávolítása valami, ami végül teljes lesz (abból, amit olvastam), vagyis a kernelben csak a primitívek maradnak meg, míg a többi eszköz a felhasználói térben lesz, ez nem rossz, éppen ellenkezőleg, sok régi kódot eltávolít a kernelből, megkönnyíti a karbantartást és sokkal konfigurálhatóbb (teljes KMS / DRM támogatás a konzolhoz). Az elején természetesen mindkét rendszer létezik, de hosszú távon (15-20 kiadás) kiléphet a kernelből, vagy még hamarabb, sok eszköz már nem támogatja az ilyen kódot az újabb és jobban támogatott kódok helyett.
Most azt mondod, hogy ha a systemd megcsinálja, mert még 50-en nem tudják megtenni (elképzelem, hogy további 50 alkalmazás van). Nos, ha látjuk a KMSCon (ilyen értelemben a legrégebbi projekt) erős függőségeit, akkor ezek libudev (kód, amely hamarosan csatlakozik a systemd-hez, akkor ez nem lesz támogatott és ütközni fog a systemd-vel, ha önmagában működik), libdrm , a libxkbcommon, a libtsm és maga a systemd is a többüléses kezelést végzi, így amikor ezt látja, rájön, hogyan alakulnak a dolgok, amikor maguknak vesznek el sok olyan eszközt, amely egy GNU / Linux operációs rendszer problémamentes működéséhez szükséges.
@Yukiteru 3. december 2014, 9:46
Itt a gentoo libudev egy virtuális sys-fs / eudev-re mutat, tehát a gentoo-tagok gondoskodni fognak az eudev módosításáról, hogy az megfeleljen az új kernelrendszer által diktált API-nak.
Tehát azt gondolom, hogy a systemd-n kívüli disztrók (hello devuan) igen vagy igen eudev-t fognak használni.
Ami az eredeti udev-vel történt, az meg fog történni, a systemd felkapta, de itt a mag az, amelyet az API diktál, hogy a DRM / KMS-t használó konzolokkal kapcsolódjon ... Már szerettem volna látni egy urxvt-t ezzel ... hehe
Amit elfogadok, az, hogy aki a systemd-t használja, annak nem lesz lehetősége semmit megváltoztatni ... teljes és kemény kiszabás, és ahogy már korábban mondtam ... sírni a temetőbe.
@ anonim minden bizonnyal a másik lehetőség, amit mondasz, az eudev ebben a tekintetben nagyobb erőre kap, és nyitva tartja a lehetőségeket a különböző eszközök kiválasztására.
PS: Ahogy mondod, érdekes lenne látni, hogy a virtuális gépek miként veszik igénybe a KMS / DRM előnyeit az fbdevdel együtt 😀
Pontosan megismételte azt a koncepciót, amelyet kritizáltam, mert soha nem a rendszerről beszéltem, hanem a folyamatok közötti kommunikációról beszéltem, és megismétlem, hogy ezt honnan veszitek, mert két folyamat kommunikál, az egyik halála ezt jelenti a másiknak sok lehetősége van meghalni? Magyarázza el nekem, hogy két külön memóriaterekben elhelyezkedő folyamat kölcsönösen befolyásolhatja egymás belső viselkedését. Lássuk, elmagyarázom-e magam, e folyamatok egyikének szempontjából csak egy IPC-mechanizmushoz való hozzáférésről van szó (bármi is legyen az, amelyet a rendszerd folyamatokkal való kommunikáció céljából definiáltak). Ha a programozó olyan rosszul tudta, hogy nem tartalmazott olyan kódot, amely képes kezelni a váratlan bemenetet és kimenetet, az valami más, de ennek semmi köze nincs ahhoz, hogy az egyik folyamat befolyásolja a másik belsejét. Ha a systemd-networkd összeomlik, akkor nem kell megölnie a journaldot vagy a systemd-t, mivel a régi sysvinit esetében az a tény, hogy az inetd összeomlások nem befolyásolhatják, külön folyamatok.
@dariem egyszerű módon elmagyarázta, hogy megkapja-e az ötletet:
Amit mondasz, az a viselkedés, amelyet mindig elvárnak a moduláris programoktól és folyamatoktól. Erre a célra valósították meg a modularitást, két folyamat szétválasztását és a saját memóriaterületük elfoglalását, valamint azt, hogy valamilyen eszközzel (IPC stb.) Kommunikáljanak, így ha valami elromlik, akkor semmi rossz nem történik. a rendszer megszakítás nélkül tovább működhet. Egy olyan elmélet, amely bizonyosan nagy támogatottságot kapott potenciálja és a jelenlegi számítástechnika számára biztosított hatalmas megbízhatósági határ miatt. Ez nem mindig igaz (az élet nem mindig szép), és úgy gondolom, hogy Ön biztosan áldozatául esett ezeknek az eseményeknek egyik vagy másik alkalommal (ez biztosan mindenki számára érvényes, függetlenül az Ön által használt operációs rendszertől), és megadom pár példa.
Az első az Xorg-mal megy (ami egy moduláris folyamat, akárcsak a systemd), amely néha megőrül egy illesztőprogrammal, és csak összeomlik és grafika nélkül hagyja Önt, míg a rendszer többi része továbbra is a várt módon működik (Blessed modularity 😀). Eddig nagyon jó elméletünk, miszerint a moduláris folyamatoknak nem kell feltörniük a rendszert, jól működik. De (mindig van ilyen, de van), néha az Xorg mást ad, mint az őrület, és valami furcsa oknál fogva (ami az egér vezérlésétől a grafikus illesztőprogramig terjedhet) nemcsak az Xorg összeomlik, hanem a kernel pánikjainak legszebbjét is ( és egy graffiti a monitoron, mint Picasso), amit el tudsz képzelni, majd rájössz, hogy bármennyire is moduláris, ha egy folyamat kommunikál és információt / adatot cserél egy másikkal, és az egyikben valami elromlik, és valamilyen okból kifolyólag a hibát nem lehet helyesen kezelni, megnő az esélye, hogy a kérdéses folyamatokat befolyásolják, mert az az egyszerű tény, hogy az adatok hibásak vagy egyszerűen sérültek, és ekkor következik a katasztrófa.
Ha úgy gondolja, hogy ez nem történhet meg, hagyok néhány hibajelentést (az egyik az enyém a Debianban, és van pár fényképe) egy régi hibáról, amely az Xorg, a mesa, a nouveau és a kern drm / kms illesztőprogramjában található, és amelyek feldolgozása ellenére külön futnak és modulárisak **, együtt nem nagyon boldogulnak, legalábbis nem adott körülmények között.
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
Most a másik példát fogom megadni a systemd-vel. Régi Sysvinitünknek volt egy sajátossága, hogy annak ellenére, hogy régi volt, nagyon megbízható volt, olyannyira, hogy ha az / etc / fstab fájljában volt egy partíció bejegyzés (a rendszer számára nem fontos, értsen meg egy / mnt / Disk160GB-t), és nem tudta Valamilyen oknál fogva nem lehet csatlakoztatni, a csatlakoztatást egyszerűen kihagyták, figyelmeztető üzenetet adott és folytatta a rendszerindítási folyamatot. Most, a systemd egy másik történet, annak modularitása ellenére, ha van egy bejegyzésed az / etc / fstab fájlban, és a systemd valamilyen oknál fogva úgy látja, hogy lehetetlen felcsatolni, akkor nem csak arra vár, hogy a partíció elérhető legyen (a normál programozott viselkedés) ) az összeszereléséhez, de ha az idő lejár, a rendszer leáll, és nem tehet mást, mint belép a helyreállítási módba, és eltávolítja ezt a sort az / etc / fstab fájlból, ami valójában nem sikerül. Ez a kis részlet már nem történik meg a rendszerindítóban az automatikus felszerelés során, és az egész folyamat leáll, először (systemd-) az apró részlet csúnyább volt, mert a dump éppen megjelent, és újra kellett indítania. Valaki elmondta neked, aki átélte a részleteket.
Egy másik példa, amelyet megadhatok, a cordumpd a systemd-ben. Alapértelmezés szerint a coredumpd az összes információt átadja a journalnald-nak, hogy utóbbi a rögzített információkat lemezre írja, eddig nagyon jó, a systemd modularitását használjuk előnyünkre. De előfordul néha, amikor a magok nagyon nagyok, csak olyan nagyok, hogy több GB-ot is el tudnak tölteni, és az információ továbbításakor a coredump-ról a journaln-re, majd a lemezre furcsa dolgok történnek, például az Xorg leáll, sőt a kernel is pánik. Ez természetesen nem csak a systemd-vel történik, de a megtervezése növeli a meghibásodási tényezőt és egyéb kellemetlen részleteket hoz létre (többek között megnövekedett memóriafelhasználást, naplózási sérülést, hiányos szemétlerakat), bárkinek is kellett dolgoznia A KDE coredump-tal biztosan több ilyen epizódot átélt, és megértette annak fontosságát, hogy a szinkronizálási lehetőség legyen az / etc / fstab fájlban a dump partíción, és biztosan utálni fogja azt a tényt, hogy nem használhat más lehetőséget a dumpok kezelésére, ha telepítve van a systemd. Példa arra, hogy mi történhet a systemd-coredumpd alkalmazással.
https://bugs.archlinux.org/task/41728
Most, hogy befejezzem:
Nem állítólag ezek moduláris programok és folyamatok? Igen, modulárisak. A kernel az egyetlen monolit dolog, amiről itt beszéltem, de elfogadja a modulokat (LKM) is, tehát egyfajta hibrid kernel lenne, bár az alaptervezési formáját nem az ilyen típusú szerkezetekben tervezték, és ez teszi bizonyos körülmények között kissé instabil.
Ez a modularitás nem engedheti meg, hogy megakadályozzam a folyamataim és rendszerem összeomlását, ha valami rosszul sül el? Igaz, a modularitás egy olyan intézkedés, amelyet a stabilitás és a megbízhatóság magas fokának elérésére terveztek, de ez nem 100% -ban tévedhetetlen mérték, mert ha valami elromolhat, akkor egyszerűen rosszul fog menni, függetlenül attól, hogy mennyire moduláris, ez egy valóság.
Melyik systemd-nek kell mindent kontrollálnia ahhoz, hogy lehetővé tegye a cgroupok és a kernelhez hozzáadott egyéb opciók használatát? Teljesen hamis. Ez egyáltalán nem szükséges, a systemd-nek maradhatott volna egy interfésze a c-csoportok indításának és hozzárendelésének vezérléséhez a rendszerben lévő folyamatokhoz és démonokhoz anélkül, hogy át kellene vennie a mostani szolgáltatások számát, és a erre a legjobb példa; hogy az OpenRC képes a csoportok használatára is, és nem emiatt támadják meg ezt a feladatot.
Mi vagyok elfogult és félő, amikor a systemd-ről beszélek? Fogalmam sincs, honnan veszi ezt, mert ahogy látja a válaszomat, nem félek ettől, csak olyan szempontokról beszélek, amelyek nem tetszenek a systemd-ben, és máris, anélkül, hogy harmadik felek véleményére támaszkodnék.
Végül azt mondja: "Ha a programozó olyan rosszul tudta, hogy nem adott be olyan kódot, amely képes kezelni a váratlan be- és kimenetet, az valami más ..."
Minden bizonnyal azt állítom, hogy a programozó, hogy nem tartalmaz olyan kódot, amely az összes lehetséges módot kezeli, amellyel a programja hibás adatbevitel miatt megszakadhat, ROSSZ, számomra felháborodásnak tűnik. Bármennyire is jó programozó, az ember nem képes megalkotni egy tévedhetetlen és hibamentes programot, MINDIG lesz kudarc, amely így vagy úgy kiderül, és amikor megtörténik, annak köszönheti véletlenszerű meghibásodás a használat során, egy hacker vagy cracker által, amely kihasználja a sebezhetőséget, kódellenőrzéssel és -ellenőrzéssel vagy bármilyen más eszközzel, amelyre a programozó számíthat. Jobb megmérni a szavakat, mielőtt ilyesmit mondana.
Üdvözlet.
Az Xorg által adott példa a legkevésbé megfelelő, mert mindenki, aki átment a KMS / DRM-re, tudja, hogy a problémát a kernelmodul hibái okozzák a KMS vezérlésére, amelyeket az Xorg illesztőprogramok fejlesztői biztosítanak. A KMS modul hibája megegyezik a rendszermag pánikjával, ennek semmi köze nincs a folyamatok közötti kommunikációhoz, mert ebben az esetben az Xorg rendszerhívást (syscall) hajt végre úgy, hogy a kern megváltoztassa a képernyő módját, vagyis ott csak egy folyamat (Xorg) foglalja magában a kernel hívását, semmi köze ahhoz, amivel itt foglalkozunk.
A systemd jelenlegi viselkedése, amikor nem találja meg a csatlakozási pontot, lényegtelen, függetlenül attól, hogy ez egy olyan tulajdonság, amely valakinek esetleg nem tetszik, és azzal oldódik meg, hogy kéri, hogy támogassa a másik viselkedést, a figyelmen kívül hagyott csatlakoztatás figyelmen kívül hagyását. A korábban bekövetkezett coredump oka lehet más, csak feltételezhető okok, de az a tény, hogy a végrehajtás nem folytatódott, egy kívánt viselkedésnek tudható be, mivel Ön azt mondja, hogy azt újra kellett indítani, nem pedig azt, hogy volt kernel pánik vagy automatikus újraindítás. Mivel még nem éltem át, nem tudok véleményt mondani.
A systemd-coredumpd és a hibajelentés linkjével kapcsolatos probléma kapcsán minden azt jelzi, hogy ez a probléma az Arch Linux rendszerben annak a tömörítésnek volt köszönhető, amelyet engedélyeztek a systemd számára, amikor összeállították az adott terjesztéshez. Inkább a tömörítési algoritmus problémájának tűnik, mint magának a systemd-nek. Az operációs rendszer nem összeomlik, inkább a coredumpok tárolására használt tömörítési algoritmus tűnik kiüríteni a rendszert, és ez az Arch Linux fejlesztők hibája, akik összeállították a systemd-t. Azonban a systemd rendelkezik olyan beállításokkal, amelyek korlátozzák az erőforrás-felhasználást, és lehetővé teszik / letiltják a rendszermag által jelentett összes coredump rögzítését. Lehet, hogy az Arch rendszergazdáknak és a KDE-t használóknak meg kellene nézniük.
Azt mondod, hogy az OpenRC a c-csoportokat is használja, anélkül, hogy invazív lenne. A probléma a következő: hogyan ismeri fel az OpenRC a démon futtatható fájlok nevét, hogy pontosan tudja, melyik erőforrás-allokáció a legmegfelelőbb? Nem igazán vagyok biztos benne, hogy ez az egyik oka annak, hogy a systemd ennyi mindenről gondoskodik, és a futtatható fájloknak jól ismert nevet ad, de gyanítom, hogy a dolog így megy. Ezenkívül a futtatható fájlok közvetlen meghívásával kiküszöböli azt a terhet, amely középpontban van ezen szolgáltatások futtatásához.
Nem tagadom, hogy a systemd-nek sok hibája lehet, de onnantól kezdve, hogy mindegyiket a fogantatásnak tulajdonítsam, nem hiszem. A sysvinit esetében szuper stabil volt, kiforrott szoftver, a systemd még csak most indul.
https://www.reddit.com/r/LinuxActionShow/comments/2nv4hp/ask_lennart_poettering_a_question/
Hogyan robbantanak golyókat systemD, xD-vel Ha annyira utálod, készítsd el saját disztródat, erre szolgál az é_é ingyenes szoftver
Nem a gyűlöletről szól, hanem a közösség védelméről.
Egyébként, ha vannak disztribúciók Független "underground":
http://gutl.jovenclub.cu/neonatox-un-linux-iconoclasta
Tisztelet
mert hasonlítson össze mindent a microsoft-tal, hogy úgy viselkedik, mint egy Windows .. ha a dolgok jól működnek, és a linux fejlesztéséhez és fejlesztéséhez szolgál, mi a probléma ... az elején minden projektben lehetnek változtatási hibák, ha a szoftverek stb. tökéletesek lennének , Emberek vagyunk, de ezért vannak hibáink.
hogy ha a systemd nem sikerül, akkor a rendszer összeomlik .. és ha a kernel, az xorg, a grub meghibásodik ... van, aki frissíti a kernelt a számítógépén vagy laptopján, elveszíti a rendszert ... akkor azért, mert ragaszkodnak a valami ...
mintha egyetlen kijött rendszerben sem hibái, sem valami hibája lenne a kezdeteiben vagy akár az érettségében
A Systemd-t szabványként vezették be a piszkos játékkal, ez sok csomag számára kötelező függőség, mert sok programot elnyelt a systemd vagy azért, mert fenntartották őket, vagy azért, mert lassan megszüntették őket, mivel már nem voltak relevánsak, mert a systemd már nyújtott valami hasonlót.
Ez korlátozza a választás szabadságát, vagyis a disztribútorok nem választhatják, hogy NEM használják a systemd-t, megpróbálhatnak ellenállni, mint a gentoo, de ez inkább egy átmeneti megoldás a systemd-re, az openrc csak egy sysv által támogatott szolgáltatáskezelő az init és a disztró initscripts számára. , a systemd több funkcionalitást nyújt, mint az openrc, és minden nap új funkciókkal rendelkezik. Az új szoftver támogatja a systemd-t, és valami hasonló megvalósítását igényli, aminek eredményeként a többi inits összetettebbé és hasonlóbbá válik a systemd-hez, amire nem vágysz.
A Systemd sok mindent megtesz a régi inithez képest, amely egyszerűen felolvas pár sort az / etc / inittab fájlból, majd betölti az egyes initskripteket és azok konfigurációit a futási szintnek megfelelően. A régi megközelítés sokkal egyszerűbb és függetlenebb volt. Átmeneti szakaszban vagyunk a homogenitás új korszaka felé, nincs megoldás, megállíthatatlan az érvényesülés módja.
Néhány év múlva gyakorlatilag nem lesz különbség a debian, az arch vagy a fedora használata között, az egyes disztribútorok identitása elvész, ha így folytatjuk, és a systemd minden nap egyre tolakodóbbá válik, hogy akár a rendszer nevének is része lesz (systemd / gnu / linux)
LOL
A templomhoz sírni>: D
Mit mond Don KZKG, ezt hagyom neked: https://blog.desdelinux.net/systemd-vs-inteligencia/#comment-127648
A probléma az, hogy argentin vagy (én is), de az a kifejezésmód, amely szerintem az argentin linuxerek nagy része, amelyeket olvastam, valóban aggasztó, bár azt is mondják, hogy a szabad szoftverek világa vonz bizonyos embereket. Amit megmentek, az az, hogy nem feltételezi, hogy argentin lenne, de sajnos bajnokságokat mutat.
uyyuyy .. az a fiú nehéz tüzérséggel esett el ..
erős komment !!
Juju .. ..pochoclos .. xD
Ebből a cikkből az következik, hogy mindössze annyit tesznek, hogy "rákényszerítenek" egy rendszert. Nem azért megyek be, hogy felmérjem, jobb-e (ami nem), vagy rosszabb. Amit mondok, megismétlem, hangsúlyozom és hangsúlyozom, hogy nem igazán akarom, hogy bármit is rám kényszerítsenek.
Olyan mondatok: "Csak nem használjuk őket az indítási folyamathoz, mert úgy gondoljuk, hogy nem a legjobb eszköz erre a konkrét célra."
És te ki vagy, aki elmondja nekem, ha ezt vagy azt az eszközt akarom használni?
Ott mindegyik. Csak nem használom, pont, és amíg nem tudok, nem is fogok.
Aláírva. Egy tálib.
(Az, hogy szórakoztatnak a bohóckodás)
gyakran fejfájás azzal a témával !!!! X_X
Szervereket kezeltem a Centos 6-tal, és 7-re menni a systemd-vel nem került semmibe, ne sírj, az élet megy tovább.
Elnézést, de sok olyan dolgot olvasok, amely emlékeztet a klasszikus "Windows Server - Certified Man VS linux szerver - OpenSource Man" diskurzusra.
1. - Meglátja, ha hibát erőltet, akkor normális, hogy kudarcot vall. Az általam látott videók mindegyike kényszerített hiba. Olyan, mintha olyan programot készítenék, amely kulcsszavakat tölt be a syslog naplóba, és egyúttal megpróbálok futtatni egy grep-alapú parancsfájlt, hogy információkat nyerjek ki a naplóból. ... természetesen kudarcot vall, én okoztam.
Ez olyan, mintha cukrot öntenének egy dízelmotorba, és azt mondanák: "Nézd ... jobb a benzin !!!" vagy akárcsak a Windows, írjon rosszul egy konfigurációs fájlt, és panaszkodjon arra, hogy a démon nem kezdi azt mondani, hogy "Windows-mal ez nem történik meg".
2. - Ez a systemd sok olyan dolgot tartalmaz, amelyet nem használhat? Nos mi a probléma? Ugyanaz az üres érv, amelyet a Windows a Linuxokkal szemben használ ... "Miért akarom, hogy egy sima szöveg ezer és egy opciót tegyen, amikor nem fogja használni?"
Még mindig hallom, hogy az IBM srácok monilit programjaikkal évekkel ezelőtt ugattak a mysql-ről, amikor olvastam néhány dolgot. Köszönöm és tapsolok a GNU / Linux és közösségének sokféleségének. Ha 50 módot adsz valamire, akkor minden pillanatban kiválasztom azt, amelyik nekem a legjobban megfelel, vagy amely megfelel nekem. Tényleg problémát lát ebben?
3. - A beszélgetések szintje alapján arra a következtetésre jutok, hogy elegendő szintje van ahhoz, hogy bármilyen terjesztéssel dolgozzon, vagy beállítsa sajátját, és maga is fenntartsa. Miért akarja feltenni a systemd-t és eltávolítani belőle a dolgokat? Nem egyszerűbb folytatni az init vagy az openRC-t?
Azoknak az embereknek, akik arra kértek, hogy tanítsam meg nekik a linux alapjait, mindig ugyanazt mondom ... A GNU / LINUX nem WINDOWS, ne próbálkozzon ugyanazokkal a dolgokkal, vagy gondolkodjon úgy, mintha lenne. Miért asszimilálja, hogy a sistemd megegyezik az initd-vel, vagy hogy ugyanúgy működik? Nem könnyebb asszimilálni a systemd működését és kihasználni a benne rejlő lehetőségeket, mint megpróbálni olyan funkciókat létrehozni, mint az init vagy az OpenRC? Normális, hogy nem szereted.
4. - Mi a bonyolultság? Biztosan emlékszel még arra, amikor lineáris programozást adtál, és hogy valamikor biztosan azt mondtad ... "És miért akarok megtanulni dolgozni tárgyakon, ha most mindent megtehetek, és mást engedtek használni?" ... (a pár hónappal későbbi arckezelés remek, ha xD)
Tisztázzuk. A jelenlegi initnek (és a systemd-t is) sok hiányossága van, amelyeket csak a bonyolultság hozzáadásával lehet pótolni. Nincs más, mivel egy összekapcsolt rendszer növekedéséhez komplexitásban kell növekednie, annak a kockázatával, hogy gyenge része van, de jobb, mint stagnálni.
Hosszú utat kell megtenni, és ha… a sistemd nem mindenre jelent megoldást. De egyik sem marad a SysVinitnél.
PS: Figyelje meg azt az iróniát, hogy a kollégám PC-jét "belekapaszkodom a Windows-server defenderbe" használtam, hogy mellesleg el tudja olvasni. xD
Csak egy dolog, a többi INIT védőinek, akik technikai adatokat és linkeket adnak ... CHAPO !!! Szeretek ilyen érveket és adatokat látni. Csak egy megjegyzés: a 2014. októbere előtti adatok csupán történelmi adatok.
Sok megvitatott dolgot már kijavítottak, és a 2013-ban megjelent számos teszttermet már felülvizsgálták.
@rolo
Ha ez igaz, ha látta a videót, amit NEM csinált, akkor látja, hogy a napló 8 MB, semmi több és így tovább, és minden megsérül, mellesleg, elküldheti a napló kimenetét syslogba sima szöveg? Igen, de még akkor is, ha megérinted a journald által létrehozott naplókat, ez megtörténik, a rendszer lefagy, és érthető módon, lássuk, a napló lóg a PID1-en olyan bonyolult dolgokkal együtt, mint a systemd, nem sikerül, úgy tűnik, hogy nincsenek a kód egy része, amely nem teszi lehetővé a szerkesztést ugyanazon a naplón kívüli PID-n kívül, és nem képes tovább írni a naplón túl, sérült, ami azt mutatja, hogy a Windows módban való gondolkodás mellett az LP rossz programozó .
Ne mondd, hogy ez csak centekben lesz, a disztribúció legstabilabb változata, amely a systemd-t, az RHEL7 klónját használja, és én nem jelentem és nem tervezem jelenteni a hibát.
Az az igazság, hogy minél többet olvasom a pro systemd megjegyzéseket, rájövök, hogy azok valóban olyanok, mint egy vallás, vagy te támogatod, vagy te vagy az ellenség, de ezeknek az ISIL-típusú vallásoknak, az iszlám államnak, teljesen szélsőséges, sőt, tapasztalatból tudom, a systemd szerelmesei, ők így gondolják, vagy te vagy velük, vagy te vagy az ellenség. Lennart ezt hirdeti arroganciájával, és kérlek, ne rohadj meg azzal, hogy Linus támogatja őt, a systemd nem ez volt, NEM volt NEM, a systemd-t használtam, amint megjelent a Fedora 15-ben, és ez csak egy gyorsabb init volt, ez nem váltotta fel a GNU / Linux modularitást.
Ha megölöm az rsyslogot, megrontom a naplóit vagy lecserélem egy rajzra, akkor semmi más, csak annyi, hogy elfogyott a naplóm, semmi sem lóg, a rendszer nem érinti.
@Rafael Mardojai
Ezt teszi Devuan, ezt tette a Void Linux és mások, akik távol maradnak a systemd-től.
@Yukiteru
Bizonyára senki sem olvas téged, amint azt mondják nekem a táliboknak, nem azért olvasnak, mert te Windows-t használsz, vagy te kommenteltél belőle, és mert úgy gondolom, hogy a rendszer szerelmesei közül kevesen értik, amit mondasz, és ebben benne rejlik a probléma.
======
Az igazság az, hogy továbbra is azt gondolom, hogy egy 2006-ban ismert személynek igaza volt valamiben:
"Nem akarom, hogy az emberek Linuxot használjanak vagy ismerjék, ezeknek az Ubuntu srácoknak tele vannak a golyóim"
- Miért?
"Amikor valami ismertté válik, és a tömegek számára megcsap, kibaszik, és rengeteg minta van belőle"
Én- "mint melyik?"
"Nézze meg, mi történt a Debiannal, most van egy buta fia, akit Ubuntu-nak hívnak, és ne feledje, néhány év múlva lesznek" hackereink "és" geekjeink ", akik elszívták az Ubuntut, és nem fogják tudni, hogyan lehet megkülönböztetni az Ext3-ot az NTFS-től"
Valami rendben volt…. A rendszer győzedelmeskedik azok között, akik tudják, ahogy Allan McRae mondja, mert nem érdekli, hogyan indul el a gépe, számára ez a gomb, a mágia, és van egy gyors üzenetem. Azok között, akiket nem érdekel más, mint a "szép munka", a szerverek használatához, az LFS, a Gentoo vagy a BSD, és azok, akik szeretik, mert gyorsabban kapcsolják be a számítógépüket színes fényekkel, gyönyörű hangokkal és szerencsejátékokkal , de nem tudják, mi az a syscall.
@SynFlag, ha nem olvassák el, saját döntésük alapján történik, mint az általam használt operációs rendszer esetében, ha a munkámban vagyok és egy Windows PC-ről nyilatkozom, az azért van, mert csak ez a kezemben van, kivéve a szervert ez a Debian Wheezy-ben található, és nyilvánvalóan a szerverről nem tudok itt nyilatkozni.
Még otthon is kénytelen voltam használni a nővérem PC-jét, mert a PC-m meghalt (az MB és az áramforrás összeesküdtek ellenem), és még akkor is, amikor van időm, csatlakoztatok egy LiveCD-t, és a Sabayont (OpenRC-vel) használom a hozzászóláshoz. itt, miközben éppen ezeket a szavakat írom.
Most, ha azt mondják nekem, vagy azt hiszik, hogy rendszerellenes tálibok vagyok, nem érdekel. Mint mondtam, a systemd-t használtam, és tudom, hogy ez nem csak sántít, általában sokat olvasom a systemd listát, hogy megismerjem az új verziókban megjelenő dolgokat, és hogy tisztában legyek a végrehajtott változásokkal és az ott zajló megbeszélések. Most, ha bármelyik systemd-szerető megérti a technikai szempontokat, amiről beszélek, és felteszem a linkjeimet (a systemd git repo linkjei főleg), és még így sem képes meglátni a valóságot, az csak azt engedi gondolni, hogy eladok ez a szemükben és a szélsőségesség a látás / gondolkodás / érzés / szeretet / dicsőítés / dicséret / imádat módjában olyan nagy, hogy nem számít, ha még maga Linus is kirúgja a rendszert, akkor még mindig bele kell gyökereznie elképzeléseikbe, hogy helyesek.
Szia! Nem vagyok túl szakértő, és szeretném tudni, hogy mire szolgál ez a "rendszer", és miért beszélnek ennyit, mi a probléma és milyen alternatíva van? köszönöm
A SynFlag megjegyzés! A "geeks", a "geeks" és a "pro linuxeros" kategóriáktól kezdve egészen ugyanazokig vagyok.
És ez a jövő vár ránk; Ubuntu még a levesben is; Linux laptopok a Steamhez való hozzáféréshez és a legfrissebb játékok játékához. És kis geekek légiói, akik nem tudják, miről szól a hüvely.
Utóirat: a systemd háttérfogalma szar.
az ADK és a fórum gombok nem láthatók a főoldalon
Tehát a @SynFlag szerint most mindenki, aki nem anti-systemd, n00b, szélsőséges vallási fanatikus és a GNU / Linuxot megrontó pestis. Ilyen szűk vélemény mellett nem tudom, érdemes-e vitatkozni erről a témáról. Jobb, ha hagyja, hogy a víz folyjon, és hosszú távon megtörténik, aminek történnie kell.
Igaz, jön egy pont, amelyet már nem lehet megvitatni. Csak az idő fogja megmondani, hogy a sytemd valami pozitívum lesz-e a szabad szoftverek világában, vagy sem.
Azt az ötletet is felveti bennem, hogy ha ez a debian alapú disztribúció, amely nem fogja használni a systemd-t, megvalósul, akkor ez segít megnyugtatni azok kedvét, akik nem akarnak semmit sem tudni a systemd-ről.
mint amikor a gnome 3 megjelent, és óriási ellenállás alakult ki, amíg a „villa” fahéj és egység megjelent, lehetővé téve a gnome alkalmazások további használatát egy olyan asztalon, amely több konfigurációval és kialakítással jobban átgondolt volt a pc-nél, és nem annyira az érintésnél
Talán ez, Rolo (Devuan megjelenése) lehet a konszenzus pontja. Azt hiszem, mindannyiunknak szüksége van arra, hogy polarizált és hangos vita légkört teremtsen. A devuán teret jelent a cselekvés megteremtésének és folytonosságának, és ez segít megnyugtatni a szellemeket. A Debianban megélt folyamat fájdalmas volt, azonban szembe kell néznünk a helyzettel, nincs más választás, mint elfogadni a különválást. Ez végül kicsit olyan, mint a válások. Ez a villa lehet egy békeszerződés átirata és annak egy része. Voltak alternatívák, természetesen Slackware, Gentoo, Funtoo, Crux, PCLinux OS, most Manjaro (hogy csak néhányat említsünk) ... de a "deb" jelenethez alternatíva kellett a systemd nélkül. Világosnak tűnik, hogy senki sem fog meggyőzni senkit, az érvek terítéken vannak, és nincs konszenzus (annak ellenére, hogy a systemd-nek vannak jó ötletei, és nyilvánvalóak azok a veszélyek, amelyeket ez a szoftver magában hordoz). Ideje elágazni és megszerezni a felhasználó szabadságát (mert itt a Szabad Szoftverről van szó, igaz?).
Az egyik tényező, amely befolyásolta a folyamatot, a "csalódás" érzése volt néhányunk részéről, akik bizalmat vetünk a Debianra. Ezért a devuánt villaként és nem származékként mutatják be. Feszültség van, mert senki sem szereti a történteket; sem a pro-systemd (ezért bizonyos dühödt támadások próbálnak rágalmazni), sem az anti-systemd (akik a villát választották). A környezetben van a "mennyi tehetséget veszíthetünk?", Egyrészt, másrészt.
Az összes Debian-felhasználó bizonyos módon "egy" módon nézi a terjesztést (ez más disztribúciókra is alkalmazható). Vannak, akik csodálják technikai minőségét, mások társadalmi szerződését, befolyását a Linux világban, az évek során megszerzett tiszteletet, stabilitását a kritikus gyártási környezetekben ... Néhány felhasználóban ez a felfogás megváltozott, csalódás látszik . Csalódás, elkeseredés, hívd, amire vágysz. Onnan a szétválásig csak egy kis lépés van.
A Debian válása hasonló ahhoz, ami a NetBSD-vel és az OpenBSD-vel történt. Bár az idő megmondja. Nagyon sok elvárást látok a villában, és ez arra késztet, hogy azt gondoljam, hogy nem lesz röpke és steril elosztás. Éppen a gnóm csapat egyik tagja kommentálta Devuan levelezőlistáját (annak ellenére, hogy ezt kínosan tette), ez véleményem szerint arra utal, hogy Devuan érdeklődést vált ki, és valamilyen módon párbeszédet akar.
Egyébként jó hétvégét.
@rolo
Ha azt akarom mondani, hogy a videó becsapható, vagy a szoftver teljes tévedés és sértés, akkor a PU ** életemben elcsaltam valamit, hogy mítoszt teremtsek, soha nem, azzal dicsekedem, hogy ezt a kudarcot az én eszközeimmel, nem pedig a trükkjeimmel láttam. Mindannyian a **** -ba mennek, mint a ***** -ba, és nem fogok többet belemenni a rendszer vitáiba, mert ez teljesen a fing, senki sem akar semmit megérteni, és olyan, mint egy vallás, ami, Utálom, mert minden a hit dogmája alapján történik. Legyen elégedett a systemd-vel.
@SynFlag erőszak hazudik
Amit ez a videó bizonyít, az az állítás téves állítása, miszerint ha az egyik systemd modul tönkremegy, az a rendszerd összeomlását okozza, mivel nyilvánvalóan abból, amit a videód mutat, ami nem történt meg, az xddddd és egyébként a folyóirat rootként fut, ezért ha egy harmadik fél belép és rosszindulatúan feltölti a napló napló bináris számát, akkor nem a systemd miatt aggódnék, hanem a számítógép biztonságáért. xdddddd. Végül a videó témájához ismételjük meg a megjelenítetteket, ha nanóval szerkesztjük a /var/log/journal/24f02f5b2b16758b820ea6a751ed6efb/system.journal fájlt, és amikor újraindítjuk, azt találjuk, hogy van egy új system.journal és egy system @@ 24f02f5b2b16758 @@ 820f6f751bXNUMXbXNUMX. Napló, amely a sérült bináris fájl.
Vagyis a napló rájön, hogy a fájl sérült, ezért nem nevezi át, és újra újat hoz létre, nem látom, mi a probléma ebben ?, Ugyanaz, mintha a system.journal fájlt törölnék, napló visszaadja létrehozni.
Kíváncsi vagyok, mi történne, ha egy egyszerű szöveges naplófájlt tönkretennék egy hexadecimális szerkesztővel, egészen addig, amíg rájössz, hogy a fájl sérült, az összes adat megsemmisül
Beszéljünk egy kicsit a naplóról, amely az egyik leggyakoribb kritika a systemd ellen.
A journal egy nagyon fontos eleme a systemd-nek, amely rögzíti a Syslog üzeneteket, a kernel naplóüzeneteket, a RAM-ot és a kezdeti indítási üzeneteket, valamint az STDOUT / TDERR-ben írt üzeneteket, és mindezeket az információkat elérhetővé teszi a felhasználó számára.
De ami a legfontosabb, a napló párhuzamosan, vagy egy hagyományos syslog démon, például az rsyslog vagy a syslog-ng helyettesítésére használható, ezért az óvatos sysadmin második lekérdezési eszközként az rsyslog vagy a syslog-ng lehet, a napló átalakításán kívül. rögzíti egyszerű szöveggé, ha a bináris fájl megsérül
Egy másik fontos tény a naplóval kapcsolatban, hogy ha a / var / log / journal mappa nem jön létre, akkor az információk csak ideiglenesen kerülnek mentésre, ami minden újraindításkor elvész.
Például amikor beléptem a systemd fájlba a debianban, a napló perzisztenciája nem volt aktív, ezért manuálisan kellett létrehoznom a napló mappát
http://0pointer.net/blog/projects/journalctl.html
Azok, akik tudnak angolul, nem hagyhatják ki azokat a beszélgetéseket, amelyek többek között a devuan, a jaromil dimkr max2344 fejlesztői között zajlanak a #devuan freenode IRC csatornán.
Nagyon jó szórakozás a systemd kód vizsgálataival, mivel szándékosan terjesztették a fertőzés (felesleges függőségek létrehozása) érdekében.
A Systemd idegesít ... egyenesen előre ... nehéz. Kevés a dokumentáció, vagy a rohadtul vékony, csak a KDM-et vagy a gdm-et futtatja, és egy könnyű rendszerben azt akarom, hogy a karcsú lxdm ne támogassa vagy összeállítsa ... Komolyan, hogy már korábban is ... elégedett voltam velük. Az az igazság, hogy elkezdtem használni az openrc-t, ahogy mondják a gentoo-ban, és ez segített…. Sokkal
@rolo
Ön egy durva és rossz hírű ember, aki ezt mondja. A legsúlyosabb sértés, ha azt mondod nekem, hogy hazudok vagy hamisítok adatokat, nagyon undorít, hogy valami védelme érdekében olyan embereket támadsz meg, akik olyan komoly PoC-t csinálnak, mint én. A napló sérült, a rendszer összeomlik, a szolgáltatás újraindítása nem működik, így nincs más lehetőség, mint újraindítani a gépet, ami nem a legjobb egy feltört szerveren, azt fogja mondani nekem, hogy ha a biztonság sérült, a legjobb az újrakezdés vagy újratelepítés, és ez az egyetlen dolog, ami miatt aggódnom kellene, mivel a rendszer azt mondja, hogy felmentik magukat, és nem végeznek forró elemzést arról, MI TÖRTÉNT? hogy eljussak erre a pontra? Nyilvánvalóan Ön még egy termék az új sysadmin-ről, ha eljut az ubuntu segítségével felvetetthez, és a DOS 5.0 biztonságával rendelkezik a számítógépén, szóval amit mondasz, úgy veszem, mint akitől származik, zavar, hogy te kétely is te vagy az, aki hamisít, te válaszoltál ugyanarra az operációs rendszerre aznapi frissítésekkel? Milyen kapacitáshiányod van, menj dolgozni taxisofőrrel többé, mint hogy kétlem, hogy ez ad neked, hagyd abba a linuxos játékot, és nézz tovább pr0n
Lássuk galambot (synflag), apa megmutatja, hogyan lehet a naplót tovább dolgozni, miután valamilyen okból megsérült a bináris naplófájlunk anélkül, hogy újra kellett volna indítania a számítógépet.
Ebben a példában a debian 8 jessie alap telepítéséből indulunk ki.
alapértelmezés szerint a systemd-journal.service a "storage = auto" funkcióval érkezik, ezért a naplók tartós nyilvántartása érdekében a fájlt a / var / log / journal / korábban könyvtárban kell létrehozni.
# mkdir -p / var / log / napló /
Ahhoz, hogy a napló elkezdhesse írni a naplókat, NEM kell újraindítania a számítógépet, csak tegye a következőket:
# systemctl töltse be újra a systemd-journal.service fájlt
o
# systemctl force-reload systemd-journal.service
### most azt fogjuk szimulálni, hogy a napló bináris naplója sérült ###
# cd / var / log / napló
#ls
24f02f5b2b19808b820ea0a980ed6efb
# cd 24f02f5b2b19808b820ea0a980ed6efb
# nano rendszer.napló
### most a fájl egyes sorait módosítjuk, hogy szimuláljuk, hogy sérültek
# Journalctl
### a várakozásoknak megfelelően semmi sem történik
#### újra kell-e indítani a számítógépet a naplóhoz egy új bináris fájl létrehozásához? NEM
# systemctl force-reload systemd-journal.service
#ls
system@24f02f5b2b19808b820ea0a980ed6efb-0000000000000001-0005069a53abf581.journal
rendszer.napló
# Journalctl
### Mint láthatjuk, a napló új bináris naplófájlt hoz létre, és most újra hozzáférhetünk az információkhoz anélkül, hogy bármikor újra kellene indítanunk a számítógépet
https://www.youtube.com/watch?v=hEagyMdkN4A&feature=youtu.be
következtetés: synflag, vagy tudatlan vagy, vagy fabler
hadd díszítse véges
gépelési hiba, valamint a másolás és beillesztés visszaélése miatt írtam a systemd-journal.service-t, amikor a valóságban a szolgáltatás neve systemd-journald.service
Pichon?, ... mennyire tévedsz, sovány vagy, komolyan .. Ezt már tudtam, jelentsd a piros sapkás hibát, hogy lássák, mit mondtak, eltalálom a választ, hátha elkapod:
Ha eltávolítja a kimeneti fájlt, vagy felülírja a fájl egyes részeit, a démon nem igazán tehet erről: ha a támadónak engedélyei vannak a kimeneti fájl módosítására, akkor már nyert. A démon ellenőrizhetné ezeket a dolgokat, de ez meglehetősen nem hatékony és semmire sem igazán hasznos. Ha akarja, beállíthat egy periodikus kriptográfiai aláírást a 'journalctl –setup-keys' segítségével. Lásd a journalctl kézikönyv oldalát.
A Journalctl az rsyslog-tól függ, nem indul automatikusan újra a napló hibája esetén, amire az rsyslognak nincs szüksége, összesen, a fordward használatával kell elküldeni az rsyslogba, és így minden ellenére meg van írva, és a naplónapló regenerálódott, a journalnald hibája, ha nem akarod látni, fújj le.
@rolo
A videóban (nem tudom, hogy te csináltad-e) azt látom, hogy a 2:11 percben ls van használva, és nem ls -l, ami lehetővé tenné a system.journal fájl eredetileg meglévő méretének megtekintését, majd szerkesztenék nanóval, és adjuk hozzá az Üres sorokat, indítsuk újra kézzel a szolgáltatást, és a 3: 15-ös percben újra ls-t csinálnak, és nem ls -l-t, majd a 3: 20-as percnél meglátják a naplót a journalctl-vel, ez mutatja az aktuális naplót, ami rendben van.
Most jöjjenek a kérdéseim:
1 - mert az ls-t használják, nem pedig az ls -l-t, annak érdekében, hogy szerkesztés előtt megnézzük a napló eredeti méretét
2 - mi történt a régi rönkkel? hova tette a systemd a korrupt bináris naplóba?
3 - melyik systemd paranccsal javíthatja meg a sérült bináris naplót ... amelyet nem szabad törölnie
Üdvözlet
@névtelen
Most jöjjenek a kérdéseim:
1 - mert az ls-t használják, nem pedig az ls -l-t, annak érdekében, hogy szerkesztés előtt megnézzük a napló eredeti méretét
2 - mi történt a régi rönkkel? hova tette a systemd a korrupt bináris naplóba?
3 - melyik systemd paranccsal javíthatja meg a sérült bináris naplót ... amelyet nem szabad törölnie
1 az az igazság, hogy nem gondoltam rá, csak használja az ls-t, hogy megnézze, milyen fájlok voltak a könyvtárban, de ha érdekel, megismételheti, az eljárás részletes, és én a virtualbox-ban csinálom (a debian bázis telepítése egy szelet tortát)
2 a régi napló ugyanabban a könyvtárban marad, csak a systemd nevezi át egy csomó számmal és betűvel (a videón látható)
3 Mindenesetre megpróbálhat harmadik féltől származó alkalmazásokat igénybe venni (feltételezem, hogy valamilyen hexaszerkesztőt), mivel ha a systemd meg tudná javítani a sérült fájlt, nem nevezné át, és nem hozna létre újat. Mindenesetre, és amint ezt a bejegyzésben már máskor is említettem, egy óvatos sysadmin használhatja az rsyslog vagy a syslog-ng második lekérdező eszközként, eltekintve attól, hogy a naplóbejegyzéseket egyszerű szöveggé alakítja, ha a bináris fájl megsérül.
Úgy értem, nem az a gondolat, hogy bárkit is meggyőzzünk a systemd használatáról (még azt is nagyon szeretném, ha a debian telepítőben lehetősége lenne az int választására). de nem fogok elhallgatni, amikor tudatlanokat vagy mesés embereket olvasok, akik folyton hazudoznak a rendszerről, mivel létezik egy blog, amikor az ember látja, hogy ezek a mondások nem esnek egybe a valósággal. és ahogy Arisztotelész mondta, az egyetlen igazság a valóság 😉
@rolo
Újra megnéztem a videót, és ha ott fel volt sorolva, csak annyi volt, hogy a numerikus név olyan hosszú volt, hogy láttam, azt hittem, hogy ez a könyvtár .... Szuverén név.
A bináris javításával kapcsolatban igen, logikus, amit mondasz ... ha meg tudnám javítani, akkor nem hoznék létre újat.
Végül megmaradtam, hogy ne legyen bináris, hogy ez ne történjen meg, és hogy a journalctl segítségével speciális eszközök nélkül láthassam ... Még mindig nem értem, mi vezetett bináris formátum használatához.
Üdvözlet és köszönet a válaszadásért
Rolo, szentelje magát valaminek:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393
Anélkül is tudtam, hogy tudtam volna…. Hogyan lehet észrevenni a különbséget az egyik között, aki megpróbálja a dolgokat, és a másik között, aki csak fing videókat készít
Zárni kezdem az ocote de Rolo-t, a hibámról, amelyet a PoC-ben láttam, beszámoltunk, ezért zárjuk be az ocote pichont:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393
Lássuk mesés:
1 Ön kijelentette, hogy a napló a probléma megoldásához újra kell indítani a számítógépet, mint a Windows alatt, TOTALY FALSE
Megmutattam neked, hogy ez hazugság volt, és abban a videóban, amelyet soha nem tettél, használod a systemctl force-reload systemd-journald.service parancsot, mert ha használnád, az argumentum összeomlik (vagy nem tudtad a parancsot , ami azt mutatná, hogy tudatlan vagy szándékosan nem használta, ami azt mutatná, hogy mesemondó vagy)
2 Azt mondod, hogy vannak hibabejelentések, egyrészt ez teljesen lényegtelen, mivel általában az emberek sok hülyeséget jelentenek hibaként (azért, hogy megértsd, nem minden hibajelentés egy igazi hiba), még az az ötlet is felmerül bennem, hogy maga is beszámolt róla. Másrészt az összes program tartalmaz hibákat (a sysvinit hány jelentett hibát tartalmaz (kb. 20 éves program)), és a jelentésben az a jó, hogy segít a fejlesztőknek felfedezni és megoldani a problémákat (néhányat gyorsabban , mások lassabban)
3 Azt mondja, hogy azzal a hibával, amelyet a naplóban generált, a rendszer újraindításakor összeomlik, mivel a videóban látható, hogy erőteljesen újra kell indítania a virtuális dobozt. TELJESEN HAMIS
Az az igazság, hogy a systemd nem ütközik össze, mivel a rendszer tökéletesen elindul (ha nem indítja el a systemd-t, akkor kernelpánikot okoz, és helyreállítási módba kell lépnie)
Veled az történik, hogy a rendszert ellenőrzik, amikor megpróbálsz binárisat szerkeszteni egy szövegszerkesztővel, és a tényezők sokak lehetnek, például a lefoglalt memória, az operációs rendszer állapota (a videóban a rendszer hosszú időt vesz igénybe) a rendszerindításhoz és kikapcsoláshoz, ami arra enged következtetni, hogy ez nem a 0 tiszta telepítése (ami az ilyen típusú esetekhez ajánlott)) stb. Csak azt tudom mondani, hogy a bináris fájlt, amelyet körülbelül 10 vagy 20 alkalommal szerkesztettem, és soha nem ellenőrizték. Ez azt is mutatja, hogy vagy tudatlan vagy mesemondó.
4 Most azt mondod, hogy a napló az rsyslogtól függ TOTALY FALSE, az a tény, hogy bárki ellenőrizheti az rsyslog telepítésével vagy eltávolításával, és láthatja, hogy a napló tökéletesen működik
Nagyra értékelném, ha elhagynád ezt az egészségtelen megszállottságot velem, nem az én hibám, hogy tudatlan vagy mesés
Következtetés:
Nem akarod használni a systemd-t, szerintem nagyszerű, most már nem kell hazugsággal terjesztenie a rettegést, hogy hívei lehessenek a rendszerellenes keresztes hadjáratának. Éltem és hagytam élni, hogy mindenki számára van hely a szabad szoftverek világában 😉
a 3. pont pontosítása, valaki azt mondaná nekem, hogy mivel a systemd a pid1-ben van, a gép összeomlása azt a rendszerd sisakot jelentené. Két dolog, itt először azt állítottuk, hogy a systemd összeomlott a naplóhiba miatt, de a valóságban van egy bináris (amelyet valós időben használnak) szövegszerkesztővel történő beírásának ellenőrzése, azt is tisztázom, hogy az összes az általam elvégzett tesztek soha nem ellenőrizték a virtuális gépet. Másodszor, senki ésszel nem állíthatja, hogy a linuxot nem címkézik xddd-vel,
Fabler?, Sovány, tartson vissza egy kicsit, fabler az öregasszony, aki azt mondja, hogy dobom a gumimat, amikor nem érintem meg bottal, visszatérek a tisztelethez:
1.- Újra kell indítania vagy kényszerítenie kell a szolgáltatás újraindítását, ami nem ideális, és a CentOS 7-ben, amikor megpróbáltam a szolgáltatás újraindítását, nem tett semmit, ne felejtsük el, hogy ez a 208-as verzió, nem az új 217 vagy 216 a Fedora.
2.- Irreleváns és azok, akik hibákat jelentenek? ... idióta vagy, nem is válaszolok neked
3.- UNHAPPY, az a verzió, amelyet aznap kipróbáltam a videóból, amit láthatsz, az egész operációs rendszer összeomlott, miért gondolod, hogy az orto boldogtalan hazugság? Nem vagyok hazug majom, menj cindor pajerót venni.
4.- Függetlenül attól, hogy önregenerálja magát, nem magától csinálja, valójában azt javasoltam a systemd devs-nek, mint funkciót, hogy a naplózás leállítása nélkül regenerálja önmagát, hacsak a szolgáltatást nem indítják újra, úgy vették, mint amit hozzá kell adni, szóval szívja meg a farkam, és mondja meg, köszönöm apu, hogy együttműködtek, miközben pornót nézek.
Chau sovány, elegem lett a majmokkal való beszélgetésből, ezért inkább az állatkertbe megyek, amikor a végbélnyílásom szintjén állunk, és beszélgetünk.
@SynFlag elnézést kérek, nem tudtam, hogy beteg vagy, tényleg azt hittem, hogy mesés és tudatlan vagy, de azzal, amit most írtál, rájövök, hogy valójában téveszme vagy.
hát semmi, remélem, hogy jobban elvégzi a gyógyszeres kezelést, és visszatér a valóságba, erő! tudsz!!!
Olvastam, olvastam és újraolvastam, de nem értek semmit, csak azt tudom, hogy amióta a Xubuntu 14.04.1 napvilágot látott, nem volt problémám a noteszgépemmel, vagy a hp 1102 lézernyomtatómmal, nem tudom egyáltalán bármi, felhasználó vagyok, és nem tudom, hogy a systemd rosszabb-e, vagy nem alkalmas-e az init-re, de megismétlem, hogy nincs problémám az xubuntuval. 🙂
Olvastam, olvastam és újraolvastam, és csak tudom, hogy egy régi témát élek át. XD