Vsak dan so naši računalniki pomembnejši del našega življenja, če imajo kakšne težave, to vpliva na naše razpoloženje, naš humor, hehe. Seveda so uporabniki sistema Windows bolj nagnjeni k napadom panike, kot če bi virusi (naj živi linux!), kaj če defragmentiramo trdi disk, kaj če poiščemo in namestimo Clean Master za osebni računalnik (čeprav moramo v Linuxu še vedno očistiti sistem, je BleachBit ena najprimernejših možnosti). V zadnjem času imajo uporabniki Linuxa (nekatere) določen glavobol, imenovan: sistemd
No, do točke, prebrala sem zanimiv članek o sistemd, kar se zdi, da je že dolgo v modi.
SystemD, kar se nekaterim zdi (in uporabil bom besede prijatelja), en prstan, ki bo vladal vsem ... drugi preprosto niti ne ustrezajo niti jim ni, dokler računalnik dobro deluje, jim je vseeno, ali init počne X ali Y ali če se uporablja systemd. Temu, ki piše, no ... recimo, da imam raje init, se mi zdi bolj preprosto 🙂
Članek pustim tukaj:
Pred začetkom moram reči, da mi ni všeč odločitev, da spremenim stvari v Debianu, vendar v nobenem trenutku ne nameravam zapustiti svoje ljubljene spirale. Samo poskušam, da če bomo razpravljali o neki temi, jo bomo vsaj čim bolj pripravili, čeprav se ne štejem za prosistemskega. Da bi dosegel demistifikacijo systemd, se bom zanesel na spletno stran, kjer razvijalci podajo svoje stališče do katerega mi je prišel kolega, za katerega se zdi, da je prosistemski, čeprav ni uporabnik Debiana. Kljub temu mislim, da lahko nadaljujem s poskusom demistifikacije tega, kar se govori o systemd.
systemd temelji na binarni datoteki
Morda je to eden izmed vidikov, ki nas najbolj šokira, če pa vse temelji na binarnosti, kako nadzirati stvari, ki jih običajno počnemo prek dnevnikov? Pojma nimam, kako se je rodil ta mit, vendar ni povsem resničen.
systemd je konfiguriran skoraj izključno prek navadnih besedilnih datotek. Nekatere nastavitve, ki jih je mogoče spremeniti tudi z ukazno vrstico jedra in s spremenljivkami okolja. V vaši konfiguraciji ni nič binarnega (niti XML). Preprosta, preprosta in lahko berljiva besedilna datoteka.
Ta stvar je monolitna in nadzoruje vse
Preden sem prišel na zgoraj omenjeno spletno stran, priznam, da sem tudi sam razmišljal tako, toda po branju tega, kar pravijo njegovi razvijalci, je moje mnenje nekaj spremenilo ...
Če gradite systemd z vsemi možnostmi konfiguracije, boste gradili 69 posameznih binarnih datotek. Ti binarni programi služijo različnim nalogam in so iz več razlogov skrbno ločeni. Na primer, systemd je bil zasnovan z mislijo na varnost, zato večina demonov deluje z najmanj privilegiji (na primer z zmogljivostmi jedra) in je odgovorna za zelo natančne naloge, da zmanjša njihov odtis. Varnost in vpliv. Poleg tega se sistemske vzporednice zaženejo več kot katera koli prejšnja rešitev. Ta "paralelizacija" se ustvari s tekom različne procese vzporedno. Zato je razvidno, da je systemd zelo dobro razdeljen na številne binarne datoteke in s tem procesi. Pravzaprav se mnogi od teh binarnih datotek ločijo tako dobro, da so zelo koristni zunaj systemd.
Paketa, ki je vključeval 69 posameznih binarnih datotek, skoraj ni bilo mogoče poklicati monolitna. Vendar se razlikuje od prejšnjih rešitev, da pošljemo več komponent v enem tarbol in jih držimo v enem skladišču z enotnim ciklom sprostitve.
To ni videti kot Unix
V tem je gotovo nekaj resnice. Izvorne datoteke systemd ne vsebujejo niti ene vrstice kode iz prvotnih vrstic UNIX. Vendar navdih izhaja iz UNIX-a, zato je v sistemu UNIX veliko UNIX-a. Primer bi lahko bila ideja UNIX "vse je datoteka", ki se odraža v tem, da so v sistemu systemd vse storitve izpostavljene med izvajanjem v datotečnem sistemu jedra, cgroupfs. Ena od prvotnih lastnosti UNIX-a je bila torej podpora za več sedežev, ki temelji na vgrajeni podpori terminalov. S sistemom systemd smo znova vgradili podporo za več sedežev, a tokrat s popolno podporo za današnjo strojno opremo, ki zajema grafiko, miši, zvok, spletne kamere in še več. Dejansko je zasnova systemd kot zbirke integriranih orodij, ki imajo vsak svoj namen, vendar kadar se uporabljajo skupaj, več kot vsota delov, kar je bolj ali manj v središču filozofije UNIX. Način ravnanja z našim projektom (tj. Ohranjanje večine jedra OS v enem samem git-repozitoriju) je veliko bližje modelu BSD (ki je pravi UNIX, v nasprotju z Linuxom), da se stvari opravijo (kjer je večina jedra operacijski sistem je shranjen v enem skladišču CVS / SVN), kar v Linuxu ni bilo nikoli.
Na koncu je vprašanje, ali je nekaj UNIX ali ne, zelo malo. Ker je tehnično odličen, je komaj edinstven za UNIX. Za nas ima UNIX velik vpliv (pravzaprav največji), imamo pa tudi druge vplive. Zato bo na nekaterih področjih systemd zelo UNIX, na drugih pa malo manj.
To je zelo zapleteno ...
V tem je gotovo nekaj resnice. Sodobni računalniki so zapletene zveri in operacijski sistem, ki deluje na njih, bo očitno preveč, zato morajo biti zapleteni. Vendar systemd zagotovo ni nič bolj zapleten kot prejšnje izvedbe istih komponent. Je preprostejša in ima manj odvečnosti. Po drugi strani pa bo gradnja preprostega sistemskega operacijskega sistema vključevala veliko manj paketov kot običajna uporaba Linuxa. Manj paketov olajša gradnjo vašega sistema, znebi se soodvisnosti in večjega števila različnih vedenj vseh vpletenih komponent.
To mi ne dovoljuje uporabe skriptov lupine
To je popolnoma neresnično. Preprosto Ne uporabljamo jih za postopek zagona, ker menimo, da niso najboljše orodje za ta poseben namen, vendar to ne pomeni, da je bil systemd z njimi nezdružljiv. Skripte lupine lahko enostavno zaženete kot sistemske storitve ali demone, skripte lahko zaženete v koli jezik kot sistemske storitve, saj sistemd niti najmanj ne zanima, kaj je znotraj njegove izvršljive datoteke. Po drugi strani pa skripte lupine v veliki meri uporabljamo za svoje namene, za namestitev, izdelavo, testiranje systemd. In skripte lahko prilepite v postopku zgodnjega zagona, uporabljajo se za običajne storitve, lahko jih zaženete na zadnji postaji, praktično ni omejitev.
Na tej točki domnevam, da so bila nekatera glavna prepričanja morda razjasnjena, kljub temu, da se nisem počutil kot zagovornik sprememb in sem imel svoje pomisleke glede »demon, ki jih bo nadziral"Mislim, da si na koncu nihče ne bo upal trditi, da vsaj ne deluje, celo poznam nekatere uporabnike, ki opazijo, da s sistemom" računalnik teče hitreje ", a to bi bile druge stvari, o katerih bi lahko razpravljali. Trenutno vas moram le še povabiti, da tukaj razpravljate o stališčih glede zagonskega upravitelja, ki so jih sprejele številne distribucije, čeprav so zdaj največji odzivi opaženi v skupnosti Debian, ki je celo rodila novo vilice z vsem tem. Če vam je všeč ali ne, je stvar vsakogar, jaz pa želim samo narediti svoj del pri demistifikaciji systemd, ki bo sčasoma prisoten v Jessie, naslednji stabilni različici Debiana.
Članek sem videl v GUTL (ki je bil povzet iz FromAbreus)
Sistemski tok?
Sem eden tistih, ki ne bere veliko novic, ko nekaj ustvari toliko polemike, raje ostajam pri več tehničnih podrobnostih. Je to ... Včasih čutim, da določene teme prenehajo biti zgolj tehnična razprava ali debata, in postanem kot ena izmed tistih tračev o slavnih 🙁
Najprej se odpre odprta vrstica od uporabnika do sistema inteligenca VS, potem Linus Torvalds to govori systemd ni tako slab kako ga slikajoin razlog, če je), imenovana vilica neuporabend ... Brez komentarjev ... in končno Devuan.
Ne bom rekel, ali je tako slabo, kot pravijo, manj slabo ali slabše. Sistem deluje zame brez težav, vendar bi za osebni okus raje uporabil init, ker je njegov način organiziranja različnih stvari (na primer hlodov na primer) bolj všeč, ampak hej, če se systemd imenuje dirkalni konj in ga mora zamenjati začeti (Bi bila naša mula, ki počne vse prej kot počasi?) No ... človek, če sprememba ni skrajno nenadna, se lahko uporabniki prilagodijo brez večjih težav in sistem deluje bolje (ja, bolje, zame ni dovolj!), Dobrodošli 😀
Zelo dober članek, nekaj dni sem z Linuxom Mint 17.1 Rebecca s sistemom in se počutim veliko bolj tekoče kot v prejšnjih različicah, o tem ne vem veliko, ker sem pogost uporabnik, ki o tem izvem, vendar se bom zavedal, to je prvi članek, ki sem ga prebral, ne govori o škodljivcih sistema systemD.
Za nekaj bo prvi, ki ga boste prebrali in ne govori škodljivcev o njem, po drugi strani pa mi povejte, ali uporabljate svojo kovnico kot strežnik? Mislim, ne bi vas motilo, če ima napako od časa do časa, ne? Zato uporabljate Mint in zato vas ne moti, vam ni všeč, pa tudi sistemski sistem vas ne zajeba. Ko imate napake in imate zaradi tega resne težave v resnih okoljih, vas bo to motilo.
Stari, kakšen distro na osnovi Debiana, ki ga priporočaš? Lahko bi uporabil Debian, vendar morate po namestitvi konfigurirati veliko stvari, kodeke itd ... Katero priporočate? hvala.
In kako vam je uspelo sistemsko vnesti v Linux Mint? Želel sem ga poskusiti vstaviti, vendar ne vem, ali moram narediti kaj dodatnega (k temu, kar teoretično že prinaša Ubuntu), če imate kakšno vodilo v zvezi s tem ali nekaj, kar mi lahko posredujete naprej, bi ga zelo cenil
Zelo dober članek. Poglejmo, ali so ga prebrali talibanski anti-SystemD (vendar dvomim)
Vsekakor pa jih bom čez leto dni videl, kako bodo uporabljali SystemD, in bodo zanikali, kar so govorili pred letom dni. Tako so tudi. Odporen na spremembe? Zagotovo ja.
Štejete me za talibana, ker nisem hotel sprejeti Systemda, potem pa vas imam za talibana, ker nisem hotel sprejeti, da ne želim sprejeti Systemda. Smo pri roki 😉
Vendar, kot piše na koncu vaših člankov:
«elav: osebni blog / Twitter / G+ / uporabnik ArchLinux. Računalničar, ljubitelj glasbe, bloger in spletni oblikovalec. Skrbnik in ustanovitelj DesdeLinux.mreža. »
to pomeni, da uporabljate eno prvih distribucij, ki jo je sprejel SystemD.
pozdrav
OK, otrok.
Brez besed !!!!, nadaljujte z igranjem, da je življenje rožnato.
Za komentarje, kakršen je vaš, dragi Giskard, zato zavračam SystemD in njegovo oznako.
In če sem po 20 letih uporabe in dela z Linuxom in za njega, jaz taliban; Pa naj bo.
Čez eno leto se pogovarjava. In elav, nisem te omenil. Ubil si se kot Chacumbele.
Poglejmo, ljudje berejo in NE berejo. Ali obstajajo ali ne obstajajo talibani proti SystemD? Obstajajo! In na drugi strani so drugi, tisti, ki ga branijo zob in nohte, kot da bi bil to zdravilo. Kaj so vsi, ki so? Ne! Sploh ne! Obstajajo tisti, ki sočustvujejo z enim ali drugim in vidijo dobro in slabo tako svojih kot drugih. S tistimi se lahko brez težav pogovarjate. A ne bodo zanikali, da obstajajo talibani. In od strani do strani. In če je nekoga to zabodlo, ne da bi razumel, da v resnici NE more biti taliban, potem utemeljim svoj primer, ker dokazi pomenijo krivdo.
Če se z nekom pogovorim o SystemD in ga ta oseba že od začetka ne pokliče po imenu, temveč Systemshit ali kaj podobnega, bi iskreno želel, da mi povedo, ali je možen pogovor s takšno osebo, ki sprva diskvalificira nasprotnik. Ne more.
Kakorkoli že, brati moraš. Poglejmo, če pridem in rečem "ali obstajajo nekateri eschejfhduf (izmišljena beseda), ki otroke tepejo, ko zapustijo šolanje", nekaj pa jih pride braniti "eschejfhduf", ali ni zato, da bi mislili, da so tudi sami?
No, če se kdo tam zunaj (ne talibani, prosim in tudi ne eschejfhduf) želi pogovoriti o prednostih in slabostih init in SystemD (ki imata dobre in slabe strani), bom z veseljem zraven.
Lep pozdrav.
Talibanski protisistem? in povej mi, kaj si prosistemski talibani? na drugi strani, ker predvidevate, da ne bomo brali, ampak komentirali neposredno?, kdo je taliban zaprtega duha, ki ne prizna diskusije in govori kot LP :: «je najboljše, verjemite mi Vem, kaj počnem ". ?
Prebral sem celoten članek in vam lahko rečem:
Systemd temelji na binarni osnovi: True
Demistifikacija: napačno
LP napačno predstavlja to, kar je rečeno, to je, da so jedro systemd dvojiški, mnogi, preveč, da bi lahko viseli s PID1, med seboj močno prepleteni, tako da vas vabim, da si ogledate #devuan, kako stane čiščenje na primer prijava systemd in ostalih paketov v Debianu, glede na to, kako je dnevnik, ki nadomešča PAM, povezan s sistemom.
Konfiguracija je jedrnata in ne dovoljuje VSEH, česar ne bi želel, na primer, deaktivirati dnevnik, saj ne morete niti ubiti PID-a niti ga ustaviti ali kar koli drugega, to je modularnost?
===========
"Ta stvar je monolitna in nadzoruje vse."
Ne glede na to, da sta 2 ali 69 binarnih datotek, se med seboj prepletajo z dbusom in s tem s celotnim OS, ne da bi jih bilo mogoče zlahka povezati, najbolj jasen primer je journald, da ga tudi ne morete deaktivirati, začetek demonov ali storitev se izvede z "enotami", ki so besedilne datoteke, vendar nič drugega kot to, razčlenjeno po systemd in voila, brez sprememb ali vdorov v storitve, ki presegajo določeno.
=======
"Ne izgleda kot UNIX"
Na kratko bom odgovoril. Ni v skladu z LSB, niti s POSIX-om. Danes je razvijalec Fedore, ki pomaga v #devuan, dejal: "Res je, ni, ni pomembno, pomembno je, da lahko poganja stvari, ki so POSIX, počitek, vsekakor me ne zanima, kateri operacijski sistem ali kaj drugega, če deluje in ima dobre lastnosti ». In zakaj bi moral biti UNIX ali UNIX podoben: naredite eno stvar in to dobro, nekaj, kar systemd ne.
===========
»Vendar systemd zagotovo ni nič bolj zapleten kot prejšnje izvedbe istih komponent. Je preprostejše in ima manj odvečnosti »
Manj odvečnosti? Zahtevajo, da namestite še en syslog za navadno besedilo, in so ga prosili za oddaljeno beleženje, preden je prišlo do systemd-journald-remote, to pomeni, da so ga dali v proizvodnjo, ne da bi lahko opravili oddaljeno beleženje, ne da bi bili odvisni od rsyslog , nekaj osnovnega, kot je centralizirana prijava. Kljub temu nima zmožnosti, preprosto logično ime, da bi označil, ali želimo izhod v binarnem ali navadnem besedilu, in tudi, če bi uporabljal binarni, zakaj ne nekaj, kar je znano kot berkeley DB, da ga lahko beremo iz katerega koli sistema UNIX ali Linux?
Preprosto?, Res? poglejte, kako preprosto je: http://wiki.gentoo.org/wiki/Comparison_of_init_systems
Poglejte količino vrstic kode in datotek.
=========================
"To mi ne dovoljuje uporabe skriptov lupine"
To je napačno, vendar je spet napačno predstavljeno, ne kritizirajo ga, ker ne dovoljuje uporabe bash skripta, ampak ker jih ne uporablja za zagon storitev, zato ga ni mogoče spreminjati, vdrti in prilagodljiv kot upstart ali sysvinit. In pod hackable mislim kodiran.
============================
Še vedno mislite, da:
1. - Sploh nimam razloga
2. - Nisem nič prebral in sem taliban?
Sprašujem se ... ali res moram zaupati temu, kar Lennart pravi? Če mi nekdo nevtralen reče, da lahko nekatere stvari upoštevam, ampak to je zame enak okus, saj Red Hat objavi nekaj za obrambo Systemda
Joj, dokler nekdo tukaj ne reče nekaj razumnega in ne samo strahu in napačnih informacij.
Članek je španski prevod tega, kar je napisal Lennart.
Brez zamere, vendar je videti, da je prevod naredil Google Translator beta različica ... 🙁 Nekatere odstavke sem težko razumel; vseeno so informacije cenjene.
@ Charlie-Brown, ker Lennart se ne zna zelo dobro izraziti v angleščini. Tako neprijetno je z branjem izvirnika.
Navedeni razlogi so resnični, vendar menim, da lahko nekateri ustvarijo več vprašanj. Vsekakor pa priporočam tistim, ki imajo priložnost: pojdite na prvotni vir informacij http://0pointer.net/blog/projects/the-biggest-myths.html (na žalost je za nekatere v angleščini), ki je veliko bolj popoln in gre tako daleč, da utemeljuje do 30 razlogov, zaradi katerih se uporaba SistemD šteje za ugodno.
Ta članek, ki ga omenjate, je napisal ustvarjalec Systemd. Očitno nihče boljši od njega ne brani svojega dela, vendar vas vabim, da si ogledate ta video http://hackingthesystem4fun.blogspot.com/2014/12/systemd-journald-centos-7-totally.html in mi bodo povedali svoje zaključke o tem. Ne rečem več.
elav je vprašanje dnevnikov, ki so v binarni datoteki, ena najbolj kritiziranih točk, celo sam Linus jo je sprožil, ko je v poročilu priznal, da systemd ni bil tako slab. Linus je tudi sam razložil, da lahko ustvarite skript, ki bo vzel podatke dnevnika in jih postavil v navadno besedilo.
Tudi systemd vam omogoča, da konfigurirate velikost binarnega dnevnika, kar zmanjša tveganje za morebitno okvaro.
Pravzaprav je umetnost, ki jo citirate, zelo neresna, saj nima niti kančka objektivnosti in me celo sprašuje, ali je napaka, ki jo kaže, resnična ali je ponarejena (zajebi lastniško programsko opremo, da povzroči napako).
vsi programi imajo v določenem trenutku napake, vendar se zdi, da bodo vedno iskali peto nogo mačke, da bi našli kaj narobe s systemd.
Na primer: v debianu je bilo odločeno, da bo systemd privzeti init, vendar ne preprečuje uporabe sysvinit ali openrc ali upstart in mi boste dobro rekli, da, vendar ne morete popolnoma odstraniti systemd, in moj odgovor bi bil, da je enako kot se je zgodilo v debian wheezy, kjer lahko zaženete openrc, systemd ali upstart, vendar pod sysvinit
PS: Ne želim si predstavljati, kako nori bodo postali s kdbusom in njegovo integracijo s sistemom na ravni jedra linux http://kroah.com/log/blog/2014/01/15/kdbus-details/
Če je lahko. Poleg tega se nameravam uradno umakniti iz razprav o Systemdu. Karkoli se mora zgoditi 🙂
@rolo je napaka dokumentirana, predstavljeno mu je bilo več poročil o napakah, predstavili so mu video in zdaj pravijo, da je nameščen. Če želite biti prepričani, sledite korakom in poglejte, kaj se bo zgodilo. Zdaj je tu več informacij o tej zadevi, izumljenih napakah? Jaz pa ne mislim tako.
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 in njegove odlične razlage)
https://bugzilla.redhat.com/show_bug.cgi?id=974132
https://bugzilla.redhat.com/show_bug.cgi?id=1157350
Vse, kar omenja video, je vsekakor radovedno. Kot razvijalec nam vedno govorijo, da ena podrobnost ne bi smela vplivati na celoten sistem / program, na primer, če izbrana poizvedba v zbirki podatkov ne uspe, zakaj bi se celoten program zrušil? Enako je s sistemom SystemD, če ne uspe, ker drugi ne, ne vem, kako dobro je narejeno. Očitno obstajajo primeri, ko je okvara praktično okvara sistema, toda bolj kot so notranje izolirane lastnosti programa, boljši bo izdelek.
Zdaj napad na programsko opremo s šibke strani ni nov, je precej pogosta praksa in v resnici bi jo bilo treba izvajati z vsakim programom, zato je, ko SystemD pade na revijo, veljaven dokaz, da SystemD še vedno ni se reče ali vodi k temu, da verjamejo.
Bolj ko bodo stvari soodvisne od SystemD, poslabšale se bodo stvari. Če namestitev naprave prej ni zrušila sistema, zdaj stvari morda ne bodo videti tako dobro.
SystemD ni slab, ne sovražim ga, vendar ni tisto, kar bi mnogi verjeli. Ima prednosti, vendar nič, česar Upstart ni imel ali bi lahko imel, seveda ni bil vpleten v Canonical in nihče ni hotel biti pozoren.
Lep pozdrav.
toda v tem videu v nobenem trenutku ne vem, da sistem zruši. tip, ki ga naredi, je, da spremeni binarno informacijo dnevnika, da ustvari napako, vendar je bistvo v tem, da vsakič, ko vstopi v sistemd.
Kolikor razumem, če omejite velikost binarnega dnevnika, ko doseže mejo, ustvari novo in tako naprej. zmanjšuje možnost kvarjenja vseh podatkov.
Bodimo jasni ... Kdo bi si mislil spremeniti tudi dnevniško datoteko? xD
@Jorgicio 4. decembra 2014 6:03
Bodimo jasni ... Kdo bi si mislil spremeniti tudi dnevniško datoteko? xD
Če ste to povedali na ironičen način ... vse dobro, sem razumel :)), če pa ste res vprašali, podajam svoje stališče.
Zame je jasno, da to ni napaka, ampak lastnost !! Ideja je v tem, da bi bilo v primeru stopnjevanja privilegijev v oddaljenem dostopu zelo enostavno tistim, ki se strinjajo z izbrisom dnevnika, preprosto tako, da ga urejajo, da ga pokvari, sistemd pa da ga izbriše kot pokvarjenega in se tako reši zaznavanja v tem oddaljenem dostopu.
Povejte mi, paranoičen, ampak drugače ne razmišljam ... To ni napaka, to je značilnost in zato te napake ne sprejmejo.
uff zdaj vsi dnevniki linux naredijo 200 člankov o systemd do te mere, da že poznam skoraj vse argumente proti in za xD.
in malo po malo so me prepričali nekateri argumenti proti sistems in med tistimi, ki sem jih videl (če je kaj narobe, me prosim popravite)
Tam sem celo videl članek o tem, kako zrušiti celoten sistem pri urejanju binarnega dnevnika in da ne vsebuje nobenih informacij, da je datoteka poškodovana.
pomanjkanje jasnosti v dnevnikih
razvojna skupina, ki pogosto prezre poročila o napakah
Ker je tako velik in vključuje toliko stvari v init, je sistem veliko bolj nestabilen in če dodamo napake, kot je zgoraj omenjena, sistem postane brez stabilnosti, ki jo linux tako zelo označuje.
rečeno je modularno, vendar njegovi deli ne morejo delovati brez drugih delov istega sistemad
razvoj, ki dolgoročno ustvarja odvisnosti pri programiranju, zaradi česar je programska oprema, kot je gnome, težko prenosljiva na sisteme brez systemd.
nadomešča dele (networkd, prijava itd.), ki že leta delajo in prejemajo vzdrževanje, ter jih zamenja za nove, ne da bi pri tem potrebovali veliko več napak.
Od takrat, ko uporabljam distribucijske sisteme na osnovi Arch (Manjaro, Bridge Linux, Antergos), ki očitno uporabljajo systemd, moram reči, da nimam nobenih pritožb glede njegove uporabe in ravnanja. Zagon storitev je preprost - še bolj v Bridge, kjer sta bluetooth ali modemmanager privzeto onemogočena. Poleg napake, povezane s hwdb.bin (https://bbs.archlinux.org/viewtopic.php?id=189536) Nisem imel veliko težav. Očitno mislim, da to ni mnenje vseh, vendar osebno nimam pritožb 🙂
Ni mi všeč ideja, da podjetje (Red Hat), obtoženo sodelovanja z NSA (zadnja vrata in nadzor ZDA), naredi sistem, s katerim je vse nadzorovano. Prstan za nadzor nad vsemi, ki jih po potrebi vežejo v temo ..
Po drugi strani pa moram priznati, da mi Intel IRIS PRO 5200 deluje bolje in skoraj nikoli, če ne že več, se moj grafični sistem pokvari, ko zaženem openSUSE 13.1. In ja, vse je bolje, začne se in ugasne veliko hitreje. Kako mi je koristil preprost uporabnik.
Izpostavljam pomemben del
Če vam nekdo očita prodajo mamil, ali ste samodejno trgovec z drogami?
@juanfgs
Trgovec z mamili ne .... sokrivec da.
Bog ... Žalil bi te, toda tvoje besede to storijo namesto tebe.
Samo pojasnite, da je systemd napisan, in tako je treba to storiti.
Črkovanje
Da, zapisano je systemd, ne sistem D ali System D ali celo SystemD. In tudi sistem d ni. Zakaj? Ker gre za sistemski demon, pri Unixu / Linuxu pa so ti z malimi črkami in se priponijo z malimi črkami d. In ker systemd upravlja sistem, se imenuje systemd. Tako preprosto je. Potem pa, če se vam vse to zdi preveč preprosto, ga pokličite (vendar ga nikoli ne črkujte!) System Five Hundred, saj je D rimska številka za 500 (to tudi razjasni odnos do sistema V, kajne?). Edina situacija, v kateri se nam zdi v redu, če v imenu uporabimo veliko črko (pa tudi ne maram), je, če stavek začnete s sistemom. Ob visokih praznikih ga lahko tudi črkujete sÿstëmd. Toda spet Système D ni sprejemljiv črkovanje in nekaj povsem drugega (čeprav se nekako prilega).
http://freedesktop.org/wiki/Software/systemd/
Tudi tukaj? To daste v GUTL .. ampak človek, vsi pravijo Linux in ne GNU / Linux, tako da je pri SystemD enako.
Povem vam, da ni treba uporabljati dnevnika ali cron, ki ga ponuja systemD, za to ali druge možnosti lahko sledite syslog-ng in cronie
Odkar sem bil v aurju, v ArchLinuxu uporabljam systemD in zdi se, da je z njim preprosteje ravnati kot z izpeljanko za debian in redhat, ima veliko ukazov konzole, ki vam rešijo urejanje besedilnih datotek in poenostavijo sestavljanje namestitvene konfiguracije skriptov (ne pozabite, da v arku je vse nameščeno s konzolo)
In nenazadnje se sistem začne hitro, v Archu bi lahko ob zagonu sistema vzporedno vzpostavili storitve, vendar je bilo tvegano
Kar se mi zdi napačno pri tej težavi, je, da večina zavzame stran ali pa ste prosistemski ali protisistemski in mislim, da ima svoje dobre in slabe stvari, jaz sem uporabnik in sem se začel malo igrati s systemd, res Dobre stvari so, zagon je hitrejši in manj zapleten kot preostali del init, čeprav me tudi številka revije zelo moti.
Razumem, da tisti, ki resnično lahko rečejo, ali je dobro ali slabo, so sysadmini ali strokovnjaki za to temo, vendar se mi zdi, da je sistemski špor pred časom prenehal biti nekaj tehničnega in je postal nekaj bolj "show-stopping". malo proti, vendar se nimam za proti ali zagovornika
@KZKG_Gaara
Vidim, da je veliko tega, kar tukaj komentirate, enako, kot ga je Lennart objavil na svojem blogu, natančneje v tem prispevku: http://0pointer.de/blog/projects/the-biggest-myths.html.
Objava je seveda imela določena "pojasnila" in je pustila ob strani določeno tehnično vsebino, da bo lahko prebavljiva informacija tistim, ki jo bodo brali, vendar bomo resni in iskreni, četudi resnica boli: systemd ima veliko stvari, za katere Lennart zanika, da jih nima, to in še veliko več pravzaprav. In v tem smislu razlagam po delih.
1. - Lennart pravi, da ni napihnjen in da nima sindroma z visokim NIH (sindrom ni izumljen tukaj). Če je odgovor pritrdilen, naj mi nekdo razloži: Zakaj mora imeti init nadzor nad omrežjem (systemd-networkd), dns (systemd-networkd), m-dns (systemd-networkd), dnevniki (journald), coredumps (systemd -coredump), odpravljanjem napak (systemd-coredump in journald), acpi (prijava), stopnjevanje pravic (prijava), nadzor nad ntp (systemd-timesyncd), nadzor nad razvijalcem (systemd je prevzel vse funkcije udev), nadzor nad / dev / random (generator naključnih števil) in najnovejši nadzor nad TTY (sistemsko konsolidiran)? Ali ni bilo VELIKO orodij, ustvarjenih za takšne namene, ki bi jih systemd zdaj dodal svojega, nekatera z ekskluzivnim dostopom (case journald)? Kakšno logično in sprejemljivo razlago mi dajete za init, da lahko prekine odpravljanje napak jedra in cmdline? Temu dodajte nadzor nad kdbus, naslednji IPC, ki bo integriran v jedro. Zagotovo mi bodo tukaj rekli: «Lahko pa namestiš drugo orodje za nadzor nad vsem tem». In če je res, toda mnoga od teh orodij prejmejo samo tok podatkov, ki jih vrže systemd, kot v primeru syslog in rsyslog, ki se povežeta s podatki / tokom, ki jih ponuja journald, da lahko druga orodja VIDIJO, kaj journald pogon, na koncu to samo pomeni, da imate dve orodji, ki počneta isto stvar, in eno izmed njih je pandorina škatla. (Prosim, ne govorite mi, da je kodo mogoče revidirati, ker vabim nekoga, da "pokadi" kodo journald in njen okvir s sistemom in drugimi povezanimi orodji
2. - Lennart nam tudi pove, da systemd ponuja podporo za skripte SysV in LSB. To je tako rekoč "polovična resnica", "bela laž", saj je resnica, da systemd-214 ne ponuja podpore za bash skripte, SysV ali LSB, kar je povezano z opombami k izdaji za to različico.
3. - Kateri systemd ni prenosljiv? To je še ena sporna točka. V BSD ne deluje dobro, v BSD med drugimi orodji, ki bi jih sistemd moral zagnati, ni skupin. Ampak to je zaradi sistemsko zasnovanega razloga, ne zato, ker ni prenosljiv. Dokler jedro BSD ne izpolni minimalnih zahtev za njegovo podporo, systemd ne bo deloval na tej platformi in to ni nihče kriv, le da BSD ne zanima in tudi Lennart ne. Tako preprosto je. Zdaj je podpora za druge knjižnice C druga stvar, dobro znane so težave z glibc (samo ročno naredite jedro, da vidite količino možnosti in rešitev, ki so bile narejene, da bi se izognili tem podrobnostim, zlasti za glibc 2.3, 2.5 in 2.11, med drugimi napakami, ki jih je glibc vlekel v preteklih letih), vendar se tam ne konča, ne konča, je Lennart sam dejal, da je raje ustvaril svojo knjižnico libc, ker je za njegovo skupino to veliko hitrejše Če bi to storili tako, kot da bi brali že ustvarjeno kodo (in mimogrede dokumentirano), vendar se to ne ustavi, nameravajo odstraniti glibc in uporabiti svoj libc ne samo za systemd, temveč tudi za Fedoro, zaradi česar je standard za izdelavo vseh njihovih paketov. NIH Kje? Zdi se, da dobri stari Lennart rad trolira in velik.
4. - Ta systemd ni monoliten, ker je razdeljen na 69 binarnih datotek. Da, to je sporno. systemd ima 69 binarnih datotek, ki opravljajo različne naloge, vendar ti binarni podatki posredujejo informacije o svojih nalogah systemd-u, zato se v primeru neuspešnosti možnosti dramatičnega povečanja precej povečajo. To je dobro dokumentirano, poročila o napakah vsebujejo številne težave, kot so te, in celo preprostejše težave, pravzaprav neumno preproste. systemd lahko razbijete na stotine binarnih datotek, toda dokler je vaše jedro pod nadzorom, se nevarnost zloma nadaljuje in povečuje, in če mi ne verjamete, preberite poročila o napakah in se zabavajte.
Upoštevajte, da tukaj nisem komentiral ničesar, kar bi bilo sistemsko smeti, dajal sem samo pripombe, ki so zgolj "tehnične" (očitno je govorjenje o tehničnih stvareh zelo zapleteno) in veljavne, podprte z informacijami, ki so lahko dostopne v internetu. Zdaj: Kateri Linux potrebuje standardni init? Da, zagotovo bi bilo to za skupnost zelo dragoceno. Kakšna systemd je rešitev? Ne, čeprav je blizu, ima zagotovo veliko pozitivnih lastnosti, vendar njegovo virusno širjenje in število stvari, ki jih počne, povečajo tveganje, da bi lahko šlo narobe in na koncu škodovalo skupnosti.
PS: Gradivo, kjer lahko potrdite, kar rečem, puščam, beri, da bo zelo ilustrativno in vidim, da ne vključujem blogov ali česar koli podobnega, čisto osebno kritiko. S spoštovanjem.
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 se morda počutite identificirani)
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
Amen bratec .. amin ..
Še vedno ne vidim nobenih utemeljenih razlogov, da ne bi sprejeli sistemad. To, kar vidite, si preprosto razlagate s strahom, kar ima za posledico pretiravanje. Niti jasne in natančno opredeljene prednosti niti slabosti.
Poleg tega ta integracija omogoča standardizacijo, o kateri ste celo govorili. Ne samo Red Hat deluje na systemd, ampak tudi različna podjetja in prostovoljci iz drugih distribucij.
Mislim, da je napaka v tem, da delovanje systemd ni pravilno preučeno.
V Yukiterujevi analizi vidim utemeljene razloge. Opazite, da namesto strahu vidim strogost, natančnost in jasnost. To mora biti vprašanje očesnega zdravnika.
To ni strah (ne bojim se kosa kode) in tudi ne pretiravanja (vse, kar sem rekel tukaj, je dokumentirano in posredoval sem veliko informacij, ki to potrjujejo, informacije, ki mimogrede pridejo s seznamov in iz uma / glasu Lennartova lastna pisava in ne iz komentarjev blogerja), to je RESNIČNOST.
systemd počne vse to in še veliko več, in to je nekaj ZASEBLJUJOČEGA (drugačen koncept kot strah), ker vsekakor potrebuje atribucije in počne stvari, ki jih je trenutno mogoče storiti z drugimi sredstvi in ki mimogrede delujejo bolje in so bolj stabilne. systemd je zelo podoben sistemu Windows in tega ni mogoče skriti, samo vedite, kaj delajo userinit.exe, svchost.exe, smss.exe in druge odvisnosti, in jih primerjajte s systemd, podobnost je tako velika, da je slaba ideja. Zdaj ima zagotovo sistem systemd boljšo kakovost od njegovega kolega v sistemu Windows (ali pa se lahko zgodi ravno nasprotno, nihče ne ve, razen če ne programirate za Microsoft), vendar me ne morete obtožiti, da sem preobremenjen in ZNAŠLJIV, ko berem Lennarta samega Na seznamu, ko smo že pri ustvarjanju povsem nove knjižnice C, ker je sit Glibca, in ñapa, ki mu je vrgel majhen in nepomemben namig, lahko ta libc uporabimo za izdelavo vseh paketov Fedora. In če mislite, da je laž in da pretiravam, vam na tej povezavi pustim sporočilo: http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html (v angleščini)
Zdaj mi povejte, če je pretirano reči pred vsemi temi, da ko se Linus odloči, da je CONFIG_VT takšen, kot je, mora zapustiti jedro (situacija, ki obstaja že dolgo časa) in ga posredovati v uporabniški prostor, ne zgodi se nora stvar, kot je za sistemsko konzolo, ki je močna odvisnost skoraj za vsako namestitev Linuxa (nekaj se mora ukvarjati z VT, se vam ne zdi?), to ne bi postavilo različnih ne-sistemskih distribucij v središče pozornosti, da bi prisililo stikalo. Če menite, da je to težava, naj vam povem, da sploh ne veste, česa je Lennart sposoben in kaj počne, saj njegove najnovejše spremembe vplivajo na razvoj vilic udev, Gentoo eudev, in to bo še naprej počel s svojimi grožnjami s pod mizo (da bi se kasneje pritožil kot v storitvi Google+)
@xiep Ne morem se več strinjati z vašim komentarjem.
Che Yukiteru, vaša dolga izjava izpusti dejstvo, da je e-pošta, ki ste jo povezali na libc, aprilska šala, poglejte opombo in si oglejte datum (31. marec, verjetno 1. april v časovnem pasu Lennart)
Vadite angleško fu, ker je voden in postavlja pod vprašaj vse vaše "raziskave".
@juanfgs se zdi, da si edini, ki bere, vsaj jaz vam za to pozdravljam, vendar morate prebrati nekaj zelo pomembnega, kar je v mojem komentarju, ni pomembno, da bom to postavil sem:
»NIH Kje? Zdi se, da dobri stari Lennart rad trolira in velik. "
Mislim, da je ni napisal iz nedolžnega razloga, zavedal se je dejstva, da gre za še eno Lennartovo šalo za aprilski dan norcev (slabe volje), pa tudi svoje strasti do obračanja /, / itd in vsega drugega v / Linux. 🙂
PS: Hvala, vendar mi ni treba vaditi angleščine, jezik uporabljam od svojega 6. leta
aaahh in vse ostalo je res, preveri 🙂
To je naravnost senzacionalizem, češ da temeljiš na dejstvih, v resnici pa slediš svoji slutnji, da je fant slab in hoče prevzeti svet, dejstva pa zasukaš tako, da odražajo tvoj govor. To je tisto, kar me zelo moti pri protisistemskih ljudeh, ne zmešajo se besed, ko gre za zvijanje dejstev in povedati polresnice, seveda nabito s svojim mnenjem.
Moje "palčno pravilo" v teh primerih je preprosto naslednja logična razčlenitev, ki izhaja iz predpostavke, da
- Sem spletni razvijalec / namizne aplikacije ali cli
- Nikoli nisem napisal sistema init.
- Nisem vzdrževalec distribucije.
preverite, ali ima sogovornik:
- ustvaril sistem init
- je aktiven vzdrževalec sistema init distro
v resnici pa je, da večina sistemov, ki ne delujejo na sistemu, ne uspe na tem testu, kljub temu pa gre za peščico ljudi, ki iz neznanega razloga VEČ VEČ kot ljudje zadaj: Debian, Fedora, Archlinux, jedro Linuxa, celoten projekt GNOME, verjetno tudi projekt KDE, ker se niso pritoževali nad systemd, SUSE in dolgim itd.
Kljub temu je njegov strupeni in vitriolični govor edino, kar doseže, ustvariti neenotnost, težave in druge. Takšna je točka, da komaj čakam, da končno preidejo na BSD, saj so grozili s strani Xorg, NetworkManager, PulseAudio in ne vem, ali zaradi čiste tehnične nevednosti ali ker se zaradi tega ne bi pritoževali.
@juanfgs, verjamem vam na besedo posebej glede tega:
«In resničnost je taka, da večina protisistemskih ne prestane tega testa, kljub temu obstaja peščica ljudi, ki iz neznanega razloga VEDE VEČ kot ljudje zadaj: Debian, Fedora, Archlinux, jedro Linuxa, celoten GNOME verjetno tudi projekt KDE, ker se niso pritoževali nad systemd, SUSE in dolgim itd.
Kljub temu je njegov strupeni in vitriolični govor edino, kar doseže, ustvariti neenotnost, težave in druge. Takšna je točka, da komaj čakam, da končno preklopijo na BSD, kot so grozili s strani Xorg, NetworkManager, PulseAudio, in ne vem, ali zaradi čiste tehnične nevednosti ali ker se zaradi tega ne bi pritoževali. "
Torej PO VAMI smo vsi protisistemski strupeni in vitriolični, da edino, kar dosežemo, je neenotnost, težave itd. Naj vam povem, da je to največje ogorčenje, ki sem ga tukaj lahko prebral. Ne vem, zakaj se prosistemski motijo, ko se pojavljajo strukturni problemi sistema, ki bodo očitno v določenem trenutku vplivali nanje, ker se jim morda zdaj ni zgodilo nič, v nekem trenutku pa se bodo. se bo, nato pa jih bodo nekateri protisistemi spomnili na besede, ki so jih večkrat izrekli, in jih nihče ni ustavil, morda pa jim bo kakšen protisistemski roko pomagal.
Osebno ne maram systemd-a, vendar to ne pomeni, da ne uporabljam init-a, ampak ga moram, ker točno v svojem delu, če se moram dotakniti stroja s tem initom, moram imeti znanje, kako ravnati to. Osebno sem ga prav tako uporabljal, odkar sem prišel v Archlinux in celo v Debian in Gentoo, zato mi ne recite, da je moja vizija pristranska, ker ne uporabljam systemd, uporabljal sem ga in vem, kako slaboten je. , in če moram komu pomagati tukaj na forumu DesdeLinux ali na IRC ali na seznamu Debian (to je distro, kjer sem bil najdlje in ga še vedno uporabljam pri svojem delu), bom to z veseljem naredil, kajti če mi je kaj všeč v skupnosti Linux, je to, da kljub razlika je vedno pomoč.
Zdaj je mogoče preklopiti na BSD, vendar bom to storil le, če bo systemd postal tako virulenten, da mi ne bo dovolil uporabiti nobene druge možnosti, medtem pa ostajam v Linuxu in onemogočim vso to norost, vključno z mnogimi Skupine stvari.
!=
Besede spet zasukate tako, da ustrezajo vašemu govoru. Ste zelo dober material za politika / novinarja.
Pojasnjujem, moj problem ni v tem, da omenjajo tehnične težave Systemda, bistvo je, da velikokrat svoj govor nalagajo z lažmi, in sicer:
Da če vas bo systemd prisilil, da uporabite strežnik microhttpd (ki je neobvezen modul, ki NI nameščen privzeto), če bo systemd en binarni sistem, bo sistemd zaprt, ker lennart plača Microsoft, binarni dnevniki So obvezni. Nihče si ne želi sistemskega, njegovo sprejemanje pa je v političnem lobiju.
To so šoki, laži. Če bi šlo za razumno razpravo, bi se splačalo, ampak to je le dobra FUD.
To, da vam ni všeč, se mi zdi popolno, ne maram veliko programske opreme, tudi programskih jezikov, distrojev in drugih, vendar si stvari o tem ne izmišljujem, niti ne berem pozorno, kar želim prebrati, in nalagam svoje izjave z osebnimi občutki, da bi poškodoval sliko ljudi, ki ga razvijejo.
@juanfgs oprosti, toda jaz nisem tisti, ki določeno skupino ljudi imenuje "strupeni in vitriolični" preprosto zato, ker jim ni všeč del programske opreme.
Spet zvijanje stavkov, da ostanemo žrtev.
@juanfgs spet vam povem, da ste to povedali vi, preverite svoje besede, vaših besed ne predstavljam napačno, pravkar sem naredil kopijo / prilepitev vaših besed v komentarju 59.
Navajam svoj besedilni komentar, tisti, ki ga morate znova prebrati, ste vi, ker nočete razumeti ali ne veste, kako debatirati. Stvari vzamete iz konteksta in si jih razlagate tako, kot so vam zapete. Če se torej želite odločiti za življenje v svetu, kjer se počutite užaljene, ker so vaši argumenti izpodbijani, vas Lennart, Red Hat in Microsoft preganjajo, je to zato, ker se odločite temu verjeti.
Tukaj na kratko, ker se zavedam, da niste razumna oseba, ker nočete razumeti, hočete stvari razlagati, kot se vam zdi primerno.
Če želite biti užaljeni, se zamerite, vendar je to vaš problem, ne preostali svet.
@juanfgs me ne motijo vaši komentarji, resnica je, da ne vidim razloga, prepiramo se, civilizirani ljudje se prepirajo, ne da bi se morali truditi glede tega (to mislim).
Zdaj, če želite ljudi označevati, jim prigovarjati (ali kakor koli že želite, da jih imenujete) za njihove govore ali dejanja (morda bi morali prebrati moj komentar št. 64 in izmeriti njegovo širino), je to vaš problem, omejite se na tiste dejanja do sebe in druge pustite zunaj te vrečke.
Lep pozdrav.
"Večina protisistemskih", "skoraj vsi", "vsi", "neki del protisistemskih" ... odstopamo, Mariano, odstopamo. V konkretnem primeru: nikjer ne vidim, da je Yukiteru izvedel senzacionalen govor, ki temelji na slutnjah (sklicevanje na njegovo analizo na ta način ima nekaj zvitega), nasprotno, razvil je trdne argumente o slabostih sistematiziran na podlagi ustreznih vprašanj in gradiva s poštnih seznamov in sledi napak (pa tudi na vljuden in civiliziran način). Mogoče iz tega razloga nekatere razdraži in ga že ob prvem komentarju napadejo, da bi ga diskreditirali in diskvalificirali (tokrat na strupen način).
Če vidite, da je diskurz večine protisistemskih strupenih in vitrioličnih, je to, kar vidim v diskurzu nekaterih prosistemskih (ne vem, ali so večinska ali manjšinska), histerija in preganjanje tistih, ki med vsem hrupom trdno argumentirajo. Da v moji deželi rečemo nadlegovanje drugačnega mnenja.
Ali systemd dobro deluje za vas? Super, zdi se mi super, toda tisti, ki ne mislijo enako, naj izrazijo svoje zadržke (operacijski sistem morda ne bo deloval na enak način).
pozdrav
Oh, mimogrede, zakaj je kakršna koli sistemska napaka razstreljena do te mere, da zapravi celotno komponento, drugi, kot so GCC, glibc ali celo jedro, pa do tega trenutka niso bili kritizirani za številne njihove napake?
Sami ste rekli, glibc je že dolgo v težavah. Llvm je sčasoma dokazal, da ima prednosti pred GCC. In tu ne vidim iste kritike.
Zakaj ne bi storili enako z drugimi projekti?
Zame je preprosto kolektivni in iracionalen strah.
Glibc ima svoje napake, ki jih nihče ne more skriti, obstaja ogromno napak Glibc, ki vplivajo na jedro in na stotine izvršljivih datotek. Razlika med Glibc in systemd je v tem, da je prvi osnova, iz katere je TISOČE programskih projektov mogoče pretvoriti v binarne datoteke, medtem ko je systemd init, katerega namen je biti stabilen, preizkušen in praktično nezmotljiv del. Ne samo to, Glibc se mora prilagoditi na stotine različnih arhitektur strojne arhitekture (CPU), različnim zastavicam za optimizacijo in edinstvenim značilnostim CPU, različnim oblikam optimizacije programske opreme, veliko bolj napornemu in težkemu delu kot delo sistema systemd. V resnici ne vidim nobenega načina, da bi predstavili primerjavo med obema projektoma v istem obsegu.
Enako velja za GCC, GCC je prevajalnik, ki mimogrede podpira številne jezike (skupaj 13 šteje neuradne) in ima značilnosti, ki so zelo podobne Glibcu, podpira številne arhitekture (70 arhitektur za različico 4.9), binarne zastavice za optimizacijo , Zastavice za optimizacijo procesorja in številne druge funkcije. Zdaj so na isti stopnji težavnosti, prevajalnik z init. Odgovor je več kot očiten, začenši s tem, da je systemd v jeziku C in da je veliko kode GCC v asemblerju ali pa moraš uporabiti asembler, da stvari delujejo v binarni obliki, kar je malo "težko narediti".
Kaj so pomanjkljivosti GCC in Glibc? Jasno. Tudi Linus jim je dal svoj napad, toda v GCC in Glibc imajo nekaj pozitivnega, da so v systemd-u večkrat pozabljeni, to je, poročali so o napaki, opazili napako in odpravili napako.
- prosim, da mi nekdo razloži: Zakaj bi moral init imeti nadzor nad:
omrežja (systemd-networkd),
dns (systemd-networkd),
m-dns (systemd-networkd), l
ogs (dnevnik),
koredumpi (systemd-coredump),
odpravljanje napak (systemd-coredump in journald),
acpi (prijava), stopnjevanje pravic (prijava),
ntp(systemd-timesyncd),
dev (systemd je vse funkcije prevzel od udev),
de / dev / naključno (generator naključnih števil)
TTY (sistemsko konzoliran)?
Tema 100000 ponavljana in ponavljana, kar morate povedati, je, da lahko systemd deluje brez njih, v resnici v debianu niso niti polovice tistih, ki jih omenjate
je tudi značilnost njegovega širokega pristopa
lennart: No, systemd razdeli, kaj mora storiti, na veliko različnih komponent (danes več kot 90 binarnih datotek). Vsak teče z najmanj možnimi privilegiji.
Mislim, da to ni prevelika razlika v coreutilsu, ki ima v enem paketu tudi veliko število komponent. In coreutils je verjetno eden večjih projektov, zaradi katerih se Linux počuti kot UNIX podoben operacijski sistem, kajne?
Ampak ja, systemd je bolj zapleten kot sysvinit, ni dvoma. V zadnjih 40 letih računalništva se je veliko spremenilo in mnogi med njimi dejansko zahtevajo določeno stopnjo zapletenosti, da bi se lahko spopadli z njimi ... Zelo malo je tega mogoče.
Ker pri freebsdju ne dobite tistega brezkompromisnega, ki počne popolnoma isto stvar, vendar s svojimi orodji in ne dovoli uporabe drugih, kar pa ne velja za systemd.
- Ali ni bilo VELIKO orodij, ustvarjenih za take namene, ki bi jih systemd zdaj dodal svojega, nekatera z ekskluzivnim dostopom (primer Donalda)?
Ne bom zanikal, da tema revije shrani informacije v binarno datoteko, je najšibkejša stvar, ki jo je mogoče zagovarjati, vendar to ni konec sveta, lahko jih shranite v navadnem besedilu
- Kakšno logično in sprejemljivo razlago mi dajete, da je init sposoben razbiti odpravljanje napak jedra in cmdline?
Mmmmmmmmmmm …………………. razbiti jedro ……. 5000000 stvari lahko zlomi jedro
- Temu dodajte nadzor nad kdbus, naslednji IPC, ki bo integriran v jedro.
Po mnenju lennarta To ima pozitiven odnos za razvijalce in systemd bo skrbnikom prinesel orodja za odpiranje dbusa, dal bo tudi vmesnike dnevnika in omrežnega vodila.
- Tu mi bodo zagotovo rekli: "Lahko pa namestiš drugo orodje za nadzor vsega tega." In če je res, toda mnoga od teh orodij prejmejo samo podatkovni tok, ki ga vrže systemd, kot v primeru syslog in rsyslog, ... .. to pomeni samo, da imate dve orodji, ki delata enako, in eno od njih je eno Pandorina škatla. (Prosim, ne govorite mi, da je kodo mogoče revidirati, ker vabim nekoga, da "pokadi" kodo journald in njeno ogrodje s sistemom in drugimi povezanimi orodji.)
tu vstopimo v teorijo zarote !!!!! je suha brezplačna programska oprema, nič ni skrito
3. - Kateri systemd ni prenosljiv? To je še ena sporna točka. V BSD ne deluje dobro, v BSD med drugimi orodji, ki bi jih sistemd moral zagnati, ni skupin. Ampak to je zaradi sistemsko zasnovanega razloga, ne zato, ker ni prenosljiv. Dokler jedro BSD ne bo zadostilo minimumu za njegovo podporo, systemd ne bo deloval na tej platformi in to ni nihče kriv, le da BSD nima interesa, niti Lennart.
No, to ni povsem pravilno, razvijalci bsd naredijo nekaj podobnega kot systemd, kar je Lennart sam poudaril v svojem računu g +
https://plus.google.com/115547683951727699051/posts/g78piqXsbKG
https://www.youtube.com/watch?v=Mri66Uz6-8Y
4. - Ta systemd ni monoliten, ker je razdeljen na 69 binarnih datotek. Da, to je sporno. systemd ima 69 binarnih datotek, ki opravljajo različne naloge, vendar ti binarni podatki posredujejo informacije o svojih nalogah systemd-u, zato se v primeru neuspešnosti možnosti dramatičnega povečanja precej povečajo. To je dobro dokumentirano, poročila o napakah vsebujejo številne težave, kot so te, in celo preprostejše težave, pravzaprav neumno preproste. systemd lahko razbijete na stotine binarnih datotek, toda dokler je vaše jedro pod nadzorom, se nevarnost zloma nadaljuje in povečuje, in če mi ne verjamete, preberite poročila o napakah in se zabavajte.
Če uporabljate sysvinit in vaš TTY dev acpi ntp pokvari tudi vaše sistemske okvare, ne bodite grozljivi.
Monolit je freebsd in nič ne rečeš
@rolo
Zdaj mi naštejte, kateri distribucijski sistem je vzel systemd in ustvaril teh 90 binarnih datotek v ločenih paketih, to bi bilo 91 paketov s systemd.
In pri namestitvi systemd me ne zahteva nobenega od teh 90 paketov kot odvisnosti.
Resno in še enkrat vztrajam ... prosim, prosim, posredujte mi možnosti pomoči za konfiguriranje, da želim narediti 91 paketov, ki jih ročno sestavljam z znamko.
Ni hujšega slepega od tistega, ki noče videti ... fantje, to je voda in olje, zdi se, da še vedno obstajajo trmasti ljudje, ki ne vidijo resničnosti tega, kar sledi Redhatu.
@rolo Želim, da namestite systemd in odstranite journald, systemd-udev in coredump ter uporabite možnosti, kot sta eudev in syslog, da vidite, ali lahko.
Ta komentar me ni mogel resneje nasmejati, umiram. 😀
Resno se resnično potrudijo, da bi malo brali, namesto da bi se držali žarka v očesu.
Poleg tega nihče ne pozabi, da Kay Sievers ne samo, da je zlomil jedro cmdline, temveč ga je želel zapreti, navsezadnje "generično je generično".
Z drugimi besedami, po vašem dejstvo, da dva procesa posredujeta informacije, jih naredi tako povezane, da dejstvo, da eden ne uspe, povzroči, da drugi ima veliko verjetnost okvare ... iz katere teorije razvoja programske opreme ste to dobili? Strinjam se z @pamp, da govorite iz iracionalnega in pristranskega strahu.
In vaše drugo veliko vprašanje, zakaj mora systemd nadzorovati toliko stvari? Preprost odgovor: ker s sysvinitom in vsemi drugimi init prednostmi, ki so bile nedavno uvedene v jedru Linuxa, zapravljamo, dokler jih nihče ne da v uporabo v uporabniškem prostoru, so "jezni" (kot pravimo na Kubi ... no, zapravljeni), brez nikogar Uporabljam jih in med skupinami dajejo zelo dobre prednosti pri učinkoviti uporabi strojnih virov (CPU, RAM, V / I itd.). Kar naredi systemd, je, da te dobre funkcije jedro Linuxa postavi v korist uporabniku, vendar mora biti za to tisti, ki te demone sproži.
Mislim, da ste napačno brali in analizirali (analiza je pomembna) ali pa si preprosto niste dali priložnosti za to. To, da dva procesa posredujeta informacije, ni razlog, da se sistem zlomi, vendar ko imate binarne datoteke z dinamičnim delovanjem, kot so nadzor omrežja, dnevniki ali izstopni podatki, ki podatke posredujejo neposredno v init, lahko stvari gredo narobe in bodo šle narobe, ker če Nekatere binarne datoteke se zlomijo, možnosti za počitek ostalih so veliko večje in to je povsem realno, kar se je tudi zgodilo, pred kratkim se je zlomil jedrni cmdline, težave z acpi, ki jih je Nvidia devs imela po zaslugi systemd-212 , vse to je vzorec tega, kar rečem.
@Dariem
Če ne morete zbrati vsakega od teh binarnih datotek v posamezne pakete, siliš, ker moraš namestiti enega, moraš namestiti vse, ko se namestijo vsi, se izkaže, da stopiš na druge pakete, ki jih ni mogoče namestiti, ker deli systemd zasedajo teh krajih.
Kakšen smisel je razdeliti veliko izvedljivo datoteko na več manjših izvedljivih datotek, če na koncu nimate paketa za vsakega, ki vam omogoča, da jih namestite posebej.
Vrnem se, da pošljem splošno zahtevo vsakemu naprednemu uporabniku systemd, da mi pove, kako sestaviti teh 90 modulov in ustvariti 90 paketov, ki jih po želji namestim in če ne, uporabim programe, ki sem jih uporabljal.
Vse to zelo slabo mleko ... Zdi se, da ljudje v sistemu mislijo, da so vsi uporabniki gnu / linux norci.
Za zapisnik uporabljam testiranje gentoo in pred nekaj meseci sem prešel na systemd in nisem mogel z journaldom, zaradi česar sem se vrnil na openrc hitreje, kot je bilo potrebno za prehod na systemd.
Da še naprej vidim, kako gre s sistemom, imam na prenosnem računalniku archlinux, ki bo kmalu izdan v gentoo .... Zagotovo stabilen.
@anonymous, samo želim videti, kako se bo vprašanje TTY razvijalo v Linuxu. Ko bo izšla koda CONFIG_VT, bomo v prid razdelitvi VT na dva dobro diferencirana dela (prostor jedrcev in uporabniški prostor) potrebovali nekaj orodja za nadzor VT-jev iz uporabniškega prostora in tam lahko systemd-consoled igra močno odvisnost, ki potegne preostanek distribucije na potrebo po namestitvi sistemskih komponent, samo da bi sistem lahko deloval. To, kar pravim, ni pretiravanje, je zelo, zelo velika možnost in res zaskrbljujoče. Obstajajo tudi drugi projekti, na primer KMSCon, toda če večina namizjev in distribucij podpira sistem, lahko stvari, kot je KMSCon, umrejo hitreje, kot mnogi mislijo.
@Yukiteru 3. decembra 2014 8:49
Tega se ne bojim, gospod Linus ne bo odstranil privzetih možnosti iz ene različice v drugo, novi sistem bo postavil kot NOV in omogočil vam bo izbiro med starim in novim.
Kar zadeva del uporabniškega prostora, lahko sestavite paket, ki to naredi samostojno. Če sistem Systemd to stori, zakaj tega ne bi moglo storiti še 50? Poleg tega bodo različni terminali sprejeli različne terminale. različni načini za uporabo z neuporabami, kot smo vajeni.
Enako velja za kdbus, da Linus to prizna v 3.19, kot pravi, ne pomeni, da ga bo človek moral imeti aktiven da ali da.
Zelo sem zadovoljen z openbox + compton, namizja zame lahko izginjajo, da me niti najmanj ne bodo prizadela.
@ anonimno vprašanje je, da je odstranitev CONFIG_VT nekaj, kar bo na koncu skupno (od tega, kar sem prebral), torej v jedru bodo ostali samo primitivi, medtem ko bodo ostala orodja v uporabniškem prostoru, to je ni slabo, nasprotno, iz jedra bo odstranil veliko stare kode, olajšal vzdrževanje in veliko bolj prilagodljiv (popolna podpora KMS / DRM za konzolo). Zagotovo bosta na začetku obstajala oba sistema, toda dolgoročno (15–20 izdaj) bo morda izstopil iz jedra, ali še prej, veliko orodij ne podpira več takšne kode v korist novejše in bolje podprte kode.
Zdaj pravite, da če systemd to stori, ker jih še 50 ne more (mislim, da še 50 aplikacij). No, če opazimo močne odvisnosti KMSCon (najstarejši projekt v tem smislu), so to libudev (koda, ki se bo kmalu pridružila systemd, ne bo podprta in bo v nasprotju s systemd, če bo delovala sama), libdrm, libxkbcommon, libtsm in se sam sistemsko lotil več sedežev, tako da ko to vidite, ugotovite, kako se stvari oblikujejo, ko si vzamete veliko orodij, potrebnih za brezhibno delovanje GNU / Linux OS.
@Yukiteru 3. decembra 2014 9:46
Tukaj v gentoo libudev je navidezni kazalnik sys-fs / eudev, zato bodo ljudje gentoo poskrbeli za spreminjanje eudev, da bo v skladu z API-jem, ki ga narekuje novi sistem jedra.
Torej mislim, da bodo distrosi, ki niso systemd (hello devuan), uporabili if ali if eudev.
Zgodilo se bo to, kar se je zgodilo s prvotnim udev, systemd ga je požrl, toda tukaj je jedro tisto, ki ga API narekuje, da vmesnik s konzolami uporablja DRM / KMS ... Že sem hotel videti urxvt, ki uporablja to ... hehe
Strinjam se s tem, da kdor uporablja systemd, ne bo imel možnosti spremeniti ničesar ... popolno in trdo namestitev in, kot sem že rekel ... jokati na pokopališče.
@ anonimni je zagotovo druga možnost, za katero pravite, eudev bo v zvezi s tem vzbudil večjo moč in odprte možnosti izbire različnih orodij.
PS: Kot pravite, bi bilo zanimivo videti, kako VT izkoristijo prednosti KMS / DRM skupaj s fbdev 😀
Natanko ste ponovili koncept, ki sem ga kritiziral, ker v nobenem trenutku nisem govoril o sistemu, govoril sem o komunikaciji med procesi in še enkrat ponavljam, od kod to, ker dva procesa komunicirata, smrt enega pomeni, da ima drugi široke možnosti Umreti? Pojasnite mi, kako lahko dva procesa, ki prebivata v ločenih pomnilniških prostorih, medsebojno vplivata na notranje vedenje drug drugega. Poglejmo, če si razložim, da je z vidika enega od teh procesov le dostop do mehanizma IPC (ne glede na to, kaj je bilo določeno za komunikacijo s sistemskimi procesi). Če je bil programer tako slab, ker ni vključeval kode, ki bi se lahko spoprijela z nepričakovanimi vhodnimi in izhodnimi podatki, je to nekaj drugega, vendar nima nič skupnega z enim procesom, ki vpliva na notranjost drugega. Če systemd-networkd zruši, mu ni treba ubiti journalda ali systemd-a, saj pri starem sysvinitu dejstvo, da zrušitve inetd ne bi smele vplivati, gre za ločene procese.
@dariem je na preprost način razložil, ali imate idejo:
Kar pravite, je zagotovo vedenje, ki se vedno pričakuje od modularnih programov in procesov. V ta namen je bila uporabljena modularnost, ločevanje dveh procesov in zasedanje lastnih pomnilniških prostorov ter komunikacija na nek način (IPC itd.), Tako da se v primeru, da gre kaj narobe, ne zgodi nič slabega. in sistem lahko še naprej deluje brez prekinitve. Teorija, ki je zagotovo imela veliko podporo zaradi svojega potenciala in izjemne meje zanesljivosti, ki jo je dala sedanjemu računalništvu. Zdaj to ni vedno res (življenje ni vedno lepo) in mislim, da ste bili v takšnih ali drugačnih primerih zagotovo žrtev teh dogodkov (to zagotovo velja za vse, ne glede na operacijski sistem, ki ga uporabljate), in dal bom nekaj primerov.
Prvi gre za Xorg (ki je modularni postopek, tako kot systemd), ki ga včasih obnore z gonilnikom in preprosto sesuje in ostane brez grafike, medtem ko preostali sistem še naprej deluje po pričakovanjih (blagoslovljena modularnost 😀). Zaenkrat dobro, naša teorija, da modularnim procesom ni treba razbiti sistema, deluje dobro. Toda (vedno je nekaj, vendar) včasih Xorg da kaj več kot norost in iz nenavadnih razlogov (ki lahko segajo od nadzora miške do grafičnega gonilnika) se Xorg ne sesuje, ampak vam daje tudi najlepše panike v jedru (in grafiti na monitorju, kot je Picasso), ki si jih lahko predstavljate, nato pa se zavedate, da ne glede na to, kako modularen je, če proces medsebojno komunicira in izmenjuje informacije / podatke z drugim in v enega od njih in iz nekega razloga napake ni mogoče pravilno obvladati, poveča se verjetnost, da bodo zadevni procesi prizadeti, že zato, ker so podatki napačni ali preprosto pokvarjeni, nato pa pride katastrofa.
Če mislite, da se to ne more zgoditi, vam pustim nekaj poročil o napakah (eno je moje v Debianu in ima nekaj fotografij) stare napake v Xorg, mesa, nouveau in gonilniku drm / kms jedra, ki kljub temu če tečejo ** ločeno in so modularni **, se skupaj ne razumejo najbolje, vsaj ne v teh okoliščinah.
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
Zdaj pa drugi primer, ki vam ga bom dal z systemd. Naš stari Sysvinit je imel posebnost, da je bil kljub temu, da je star, zelo zanesljiv do te mere, da če je imel vaš / etc / fstab vnos particije (za sistem ni pomemben, razumejte a / mnt / Disk160GB) in je iz nekega razloga ga ni bilo mogoče namestiti, preprosto je bil preskočen, dal vam je opozorilno sporočilo in nadaljeval s postopkom zagona. Zdaj je systemd druga zgodba, kljub svoji modularnosti, če imate vnos v / etc / fstab in systemd iz nekega razloga vidi, da ga je nemogoče namestiti, ne samo, da čaka, da bo particija na voljo (normalno programirano vedenje) če se čas konča, se vaš sistem ustavi in ne morete storiti nič drugega kot vstopiti v način za obnovitev in odstraniti to vrstico iz / etc / fstab, nekaj dejansko ne uspe. Te majhne podrobnosti ni več med samodejnim priklopom v zagonu in celoten postopek se ustavi, sprva (systemd-) je bila majhna podrobnost grša, ker se je smetišče pravkar pojavilo in morali ste ga znova zagnati. Nekdo, ki je šel skozi podrobnosti, vam pove.
Drug primer, ki ga lahko navedem, je coredumpd v systemd. coredumpd privzeto posreduje vse svoje podatke journaldu, da slednji zajete podatke zapiše na disk, zaenkrat tako dobro, v svojo korist uporabljamo modularnost systemd. Toda včasih se zgodi, da so odlagališča zelo velika, ravno tako velika, da lahko zavzamejo več GB, in v postopku posredovanja informacij iz coredump na journald in nato na disk se zgodijo nenavadne stvari, kot da Xorg preneha delovati in celo jedrna panika. To se seveda ne zgodi le s sistemom, ampak način njegove zasnove poveča faktor okvare in ustvari druge neprijetne podrobnosti (med njimi povečana poraba pomnilnika, poškodbe dnevnika, nepopolna odlagališča), kdor je moral delati Z KDE coredump ste zagotovo že preživeli več takšnih epizod in razumeli boste, kako pomembna je možnost sinhronizacije v / etc / fstab za vašo particijo izpisa in zagotovo boste sovražili dejstvo, da ne morete uporabiti druge možnosti za obdelavo odlagališč, če ste namestili systemd. Primer, kaj se lahko zgodi z systemd-coredumpd.
https://bugs.archlinux.org/task/41728
Zdaj pa za konec:
Ali ne bi smeli biti modularni programi in procesi? Da, modularni so. Jedro je edina monolitna stvar, o kateri sem že govoril, vendar sprejema tudi module (LKM), tako da bi lahko postalo nekakšno hibridno jedro, čeprav njegova osnovna oblika zasnove ni zasnovana v takšni strukturi, in zaradi tega je v določenih okoliščinah nekoliko nestabilen.
Ta modularnost mi ne bi smela omogočiti, da se moji procesi in sistem ne zrušijo, če gre kaj narobe? Res je, modularnost je ukrep, namenjen doseganju visoke stopnje stabilnosti in zanesljivosti, vendar ni 100% nezmotljiv ukrep, kajti če gre lahko kaj narobe, bo preprosto šlo narobe, ne glede na to, kako modularno, to je resničnost.
Kateri systemd mora imeti nadzor nad vsem, da omogoča uporabo skupin c in drugih možnosti, dodanih jedru? Popolnoma lažno. To sploh ni potrebno, sistems bi lahko imel vmesnik za nadzor zagona in dodeljevanja skupin procesom in demonom, ki bodo v sistemu, ne da bi moral prevzeti število storitev, ki jih ima zdaj, in najboljše primer tega je; da je OpenRC sposoben tudi uporabljati skupine in ni zato, da bi napadal to nalogo.
Kaj sem pristranska in se bojim, ko govorim o systemd? Pojma nimam, od kod mu to, ker se, kot vidite moj odgovor, tega ne bojim, govorim samo o vidikih, ki mi pri systemd-u niso všeč in se ne zanašam na mnenja tretjih oseb.
Nazadnje pravite, da: "Če je bil programer tako slab, ker ni vključeval kode, ki bi lahko obravnavala nepričakovane vhode in izhode, je to nekaj drugega ..."
Vsekakor bi rekel, da je programer, ker ni vključil kode, ki obravnava VSE možne načine, na katere se njegov program lahko zlomi zaradi napačnega vnosa podatkov, LOŠ, se mi zdi ogorčeno. Ne glede na to, kako dober programer je, človek ne more oblikovati nezmotljivega in varnega programa, VEDNO bo prišlo do napake, ki bo tako ali drugače prišla na dan, in ko se bo, bo to zaradi naključne okvare med uporaba s strani hekerja ali vdiralca, ki izkorišča ranljivost, s pregledom in revizijo kode ali na kakršen koli drug način, na katerega lahko programer računa. Bolje izmeriti besede, preden izgovorite kaj takega.
Lep pozdrav.
Primer Xorga je najmanj primeren, ker vsi, ki so prestali prehod na KMS / DRM, vedo, da težavo povzročajo napake v modulih jedra za nadzor KMS, ki jih ponujajo razvijalci gonilnikov Xorg. Napaka v modulu KMS je enaka paniki jedra, nima nič skupnega s komunikacijo med procesi, ker je v tem primeru Xorg sistemski klic (syscall), tako da jedro spremeni način zaslona, to je tam je vključen le en postopek (Xorg), ki prikliče jedro, nič skupnega s tem, kar imamo tukaj.
Trenutno vedenje systemd-a, ko ne najde točke vpenjanja, je nepomembno, ne glede na to, da gre za funkcijo, ki nekomu morda ni všeč, kar se reši s prošnjo, naj podpira drugo vedenje, in sicer ignoriranje neuspešnega priklopa. Do prejšnjega izpada je lahko prišlo zaradi različnih vzrokov, o katerih bi se lahko le ugibalo, toda dejanje, da se izvršitev ni nadaljevala, je lahko posledica želenega vedenja, saj pravite, da ga je bilo treba znova zagnati, ne pa, da je prišlo do panike v jedru ali samodejni ponovni zagon. Ker tega še nisem preživel, ne morem dati mnenja.
Glede težave, ki ste jo postavili z systemd-coredumpd, in povezave do poročila o napaki, vse kaže, da je bila težava v Arch Linuxu posledica stiskanja, ki so ga omogočili systemd, ko so ga sestavili za to distribucijo. Zdi se bolj kot problem z algoritmom stiskanja kot s samim sistemom. Operacijski sistem se ne sesuje, temveč algoritem stiskanja, ki se uporablja za shranjevanje primernih odlagališč, izprazni sistem in za to so krivi razvijalci Arch Linux, ki so sestavili systemd. Vendar ima sistemd nastavitve za omejevanje porabe virov in omogočanje / onemogočanje zajemanja vseh primerjalnih odlagališč, o katerih poroča jedro. Mogoče bi si jih morali ogledati Arch vzdrževalci systemd in tisti, ki uporabljajo KDE.
Pravite, da OpenRC uporablja tudi skupine, ne da bi bil invaziven. Težava je v tem: kako OpenRC prepozna ime izvedljivih datotek demona, da natančno ve, katera dodelitev virov je najprimernejša? Pravzaprav nisem prepričan, ali je to eden od razlogov, zakaj systemd skrbi za toliko stvari in daje izvršljivim datotekam dobro znano ime, vendar sumim, da gre stvar tako. Poleg tega odpravlja breme, da imate na sredini pomišljaj za zagon vsake od teh storitev, tako da neposredno prikliče izvršljive datoteke.
Ne bom zanikal, da ima lahko systemd veliko napak, toda če bi jih vse pripisal načinu, kako je zasnovan, mislim, da ne. V primeru sysvinita je bil super stabilen, zrel kos programske opreme, sistem pa šele začenja.
https://www.reddit.com/r/LinuxActionShow/comments/2nv4hp/ask_lennart_poettering_a_question/
Kako počijo kroglice s systemD, xD Če ga tako sovražite, ustvarite svoj distro, kar je brezplačna programska oprema za é_é
Ne gre za sovraštvo, temveč za obrambo skupnosti.
Mimogrede, če obstajajo distribucije Neodvisno "podzemlje":
http://gutl.jovenclub.cu/neonatox-un-linux-iconoclasta
Spoštovanja
ker primerjajte vse z Microsoftom, da se obnaša kot okna .. če stvari dobro delujejo in je za razvoj in razvoj linuxa težava ... vsak projekt na začetku ima lahko napake v spremembah, če so bili programi itd. Smo ljudje, a zato imamo napake.
da če systemd ne uspe, bo sistem zrušil .. in če odpove jedro, xorg, grub .. obstajajo ljudje, ki ob posodabljanju jedra na svojem računalniku ali prenosnem računalniku izgubijo sistem ... potem pa zaradi vztrajanja pri popolnosti nečesa ...
kot da bi kateri koli sistem, ki je izšel, v svojih začetkih ali celo v svoji zrelosti ni imel napak, napak
Systemd je bil uveden kot standard z umazano igro, za mnoge pakete je obvezna odvisnost, ker je veliko programov sistemd absorbiral bodisi zato, ker jih je vzdrževal bodisi, ker jih je počasi odpravil, ker niso bili več ustrezni, ker je systemd že zagotovil nekaj podobnega.
To omejuje svobodo izbire, torej distributerji ne morejo izbrati, da NE uporabljajo systemd, lahko se poskusijo upreti kot gentoo, toda to je bolj začasna rešitev za systemd, openrc je samo sysv podprt upravitelj storitev za init in in distro initscripts, systemd ponuja več funkcionalnosti kot openrc in ima nove funkcije vsak dan. Nova programska oprema podpira systemd in zahteva uvedbo podobnega, kar na koncu postavi druge enote bolj zapletene in bolj podobne systemd, kar pa ne želite.
Systemd naredi marsikaj v primerjavi s starim init-om, ki preprosto prebere nekaj vrstic iz / etc / inittab in nato naloži vsak initscript in njegove nastavitve glede na raven teka. Stari pristop je bil veliko bolj preprost in neodvisen. Smo v fazi prehoda v novo dobo homogenosti, rešitve ni, način prevladovanja je neustavljiv.
Čez nekaj let praktično ne bo nobene razlike med uporabo debiana, uporabo arch-a ali fedore, identiteta vsakega distro-ja bo izgubljena, če bomo nadaljevali tako in bo systemd vsak dan bolj vsiljiv, kar bo celo postalo del imena sistema (systemd / gnu / linux)
LOL
Zajokati v cerkev>: D
Kaj pravi Don KZKG, pustim vam tole: https://blog.desdelinux.net/systemd-vs-inteligencia/#comment-127648
Težava je v tem, da ste Argentinec (tudi jaz), vendar je način izražanja, da ima večina argentinskih linuxerosov, ki sem jih prebral, res zaskrbljujoč, čeprav je rečeno tudi, da svet brezplačne programske opreme privlači nekatere ljudi. Rešujem to, da ne domnevate, da ste Argentinec, a žal kaže na lige.
uyyuyy .. ta fant je padel s težko artilerijo ..
silovit komentar !!
Juju .. ..pochoclos .. xD
Iz tega članka izhaja, da vse, kar počnejo, "naložijo" sistem. Ne vstopam, da bi ocenil, ali je boljše (kar pa ni) ali slabše. Kar rečem, ponavljam, poudarjam in poudarjam, je, da v resnici ne želim, da bi mi karkoli vsiljevali.
Stavki, kot so: "Preprosto jih ne uporabljamo za postopek zagona, ker menimo, da niso najboljše orodje za ta poseben namen."
In kdo si ti, da mi poveš, ali želim uporabiti to ali ono orodje?
Tam vsak. Preprosto ga ne uporabljam, pika in dokler ne bom mogel, ne bom.
Podpisano. Talibani.
(To je, da me zabava klovna)
pogosto glavobol s to temo !!!! X_X
Upravljal sem strežnike s Centosom 6 in odhod na 7 s sistemom me ni nič stal, ne jokaj, življenje gre naprej.
Oprostite, vendar berem veliko stvari, ki me spominjajo na klasični diskurz "windows server - Certified Man VS linux server - OpenSource Man".
1. - Videli boste, če prisilite napako, je normalno, da odpove. Vsak video posnetek, ki sem ga videl, je vsiljena napaka. Kot da naredim program, ki v dnevnik syslog doda ključne besede, hkrati pa poskušam zagnati skript, ki temelji na grep, da iz njega izvlečem informacije ... seveda ne bo uspelo, jaz sem to povzročil.
To je kot dodajanje sladkorja dizelskemu motorju in reči "Poglejte ... bencin je boljši !!!" ali tako kot Windows, napačno napišite konfiguracijsko datoteko in se pritožite, da demon ne začne govoriti "z okni se to ne zgodi."
2. - Ta systemd vključuje veliko stvari, ki jih morda ne uporabljate? No, v čem je težava? Gre za to, da gre za isti prazen argument, ki ga uporablja Windows v primerjavi z Linuxom ... "Zakaj želim, da ima navadno besedilo tisoč in eno možnost, če jih ne boste uporabili?"
Še vedno slišim IBM-ove fantje s svojimi monilitskimi programi, ki so lajali o mysqlu pred leti, ko sem bral nekatere stvari. Zahvaljujem se in pozdravljam raznolikost GNU / Linuxa in njegove skupnosti. Če mi date 50 načinov, kako nekaj narediti, bom vsak trenutek izbral tistega, ki mi najbolj ustreza ali ustreza tistemu, kar potrebujem. Ali res vidite težavo v tem?
3. - Glede na raven pogovorov ugotavljam, da imate dovolj ravni za delo s katero koli distribucijo ali nastavite svojo in jo sami vzdržujte. Zakaj želite postaviti systemd in odstraniti stvari iz njega? Ali ni lažje nadaljevati z vašo init ali openRC?
Ljudem, ki so me prosili, naj jih naučim osnov linuxa, rečem vedno isto ... GNU / LINUX ni WINDOWS, ne poskušajte delati enakih stvari ali razmišljati, kot da bi bilo. Zakaj asimilirate, da je sistemd enak kot initd ali da deluje enako? Ali ni lažje uskladiti delovanje systemd in izkoristiti njegov potencial kot poskusiti narediti funkcije, kot sta init ali OpenRC? Običajno je, da vam ni všeč.
4. - Kaj je narobe s kompleksnostjo? Zagotovo se še vedno spomnite, kdaj ste dali linearno programiranje, in da ste zagotovo v nekem trenutku rekli ... «In zakaj se želim naučiti delati na predmetih, če lahko zdaj delam vse, pa še, da me uporabljajo?» ... (nekaj mesecev kasneje je facepalm super, če xD)
Bodimo jasni. Trenutni pobudniki (in sem vključujem systemd) imajo številne pomanjkljivosti, ki jih je mogoče zapolniti le z dodajanjem zapletenosti. Drugega ni, saj mora medsebojno povezan sistem rasti zapleteno, s tveganjem, da bo imel šibek del, vendar je bolje, kot da ostane miren.
Dolga pot je dolga in če… sistemd ni rešitev za vse. Toda noben ne ostane pri SysVinitu.
PS: Opazite ironijo, da sem uporabil kolegov računalnik "Držim se zagovornika Windows-strežnika", da ga bo mimogrede prebral. xD
Samo ena stvar, zagovornikom drugih INIT-jev, ki dajejo tehnične podatke in povezave ... ČAPO !!! Všeč mi je, da vidim takšne argumente in podatke. Opomba: podatki pred oktobrom 2014 so zgolj zgodovinski.
Številne stvari, o katerih se razpravlja, so že popravljene, številne preskusne steze, objavljene leta 2013, pa že pregledane.
@rolo
Če je res, če ste videli video, česar NISTE NAREDILI, vidite, da je dnevnik 8 MB, nič več in tako naprej in se vse poškoduje, lahko, pošljete izpise journalda v syslog v navadnem besedilu? Da, a tudi če se dotaknete dnevnikov, ki jih je ustvaril journald, se to zgodi, sistem visi in, razumljivo, poglejmo, dnevnik visi na PID1 skupaj s tako zapletenimi stvarmi, kot je systemd, ne uspe, zdi se, da nima nobenega dela koda, ki ne omogoča urejanja za kaj drugega kot isti dnevnik PID, pa tudi nima možnosti nadaljevanja pisanja po dnevniku, je poškodovana, kar kaže, da je LP poleg razmišljanja v načinu Windows slab programer .
Ne govorite mi, da bo le v centos, najstabilnejši različici distro, ki uporablja systemd, klon RHEL7, in napake ne poročam ali nameravam prijaviti.
Resnica je, da bolj ko berem pro sistemske komentarje, se zavedam, da so resnično kot religija, ali ste naklonjeni ali ste sovražnik, toda med temi religijami tipa ISIL so tiste iz islamske države, popolnoma ekstremistične, pravzaprav , Iz izkušenj vem, ljubitelji sistemov mislijo tako ali pa ste z njimi ali ste sovražnik. To je tisto, kar Lennart promovira s svojo aroganco in prosim, ne zajebavajte me z Linusom, ki ga podpira, systemd ni bil to, NI BIL, sistemd sem uporabil takoj, ko je izšel v Fedori 15 in je bil samo hitrejši začetek, ni nadomestil Modularnost GNU / Linux.
Če ubijem rsyslog, pokvarim njegove dnevnike ali ga nadomestim z risbo, nič več, le da mi zmanjka dnevnika, nič ne visi, sistem ne vpliva.
@Rafael Mardojai
To počne Devuan, to je storil Void Linux in drugi, ki se držijo stran od systemd.
@Jukiteru
Zagotovo vas nihče ne bere, kot mi pravijo talibani, ne bere vas, ker uporabljate okna ali ste komentirali iz njega in ker verjamem, da le malo ljubiteljev sistemov razume tehnični del tega, kar pravite, in v tem je težava.
======
Resnica je, da še vedno mislim, da je imela oseba, znana že leta 2006, glede nečesa prav:
"Nočem, da ljudje uporabljajo Linux ali da ga poznajo, ti fantje iz Ubuntuja imajo polna jajca
Jaz - "Zakaj?"
"Ko nekaj postane znano in za množice, se usra, zajebe in vzorcev je na pretek"
Jaz - "všeč kateri?"
"Poglejte, kaj se je zgodilo z Debianom, zdaj ima neumnega sina z imenom Ubuntu in ne pozabite, da bomo čez nekaj let imeli" hekerje "in" izrode ", ki so sesali Ubuntu in ne bodo znali razlikovati Ext3 od NTFS."
Nekaj je bilo prav ... systemd zmaguje med tistimi, ki vedo, kot pravi Allan McRae, ker mu je vseeno, kako zažene svoj stroj, zanj je to, gumb, čarovnija in imam poziv. Med tistimi, ki jih zanima le "delo" z lepimi lastnostmi, skupaj, za strežnike res uporabljajo LFS ali Gentoo ali BSD in nato tisti, ki jih imajo radi, ker se njihov računalnik hitreje vklopi z barvnimi lučmi, čudovitimi zvoki in igrami na srečo, vendar ne vedo, kaj je syscall.
@SynFlag, če ga ne preberejo, odločijo sami, tako kot za OS, ki ga uporabljam, če sem pri svojem delu in komentiram iz računalnika z Windows, je to edino, kar imam pri roki, razen strežnika v Debianu Pihanje in očitno s strežnika tukaj ne morem komentirati.
Tudi doma sem bil prisiljen uporabljati sestrin osebni računalnik, ker je moj osebni računalnik umrl (MB in vir napajanja sta se zarotila proti meni). Kljub temu, ko imam čas, namestim LiveCD in uporabim Sabayon (z OpenRC ), da tukaj komentiram, tako kot delam ravno takrat, ko pišem te besede.
Zdaj, če mi rečejo ali mislijo, da sem protisistemski taliban, mi je vseeno. Kot sem že rekel, sem uporabil systemd in vem, da šepa, ne samo to, ponavadi veliko berem seznam systemd, da izvem o stvareh, ki prihajajo v novih različicah, in tudi, da se zavem sprememb, ki so narejene in razprave, ki tam potekajo. Zdaj, če kateri koli ljubitelj systemd-a razume tehnični vidik tega, o čemer govorim, in vstavim svoje povezave (večinoma povezave do systemd git repo) in kljub temu ne more videti resničnosti, to mi omogoča le, da mislim, da ga prodajam v njihovi oči in ekstremizem v njihovem načinu gledanja / razmišljanja / čustvovanja / ljubezni / poveličevanja / hvale / čaščenja systemd je tako velik, da je vseeno, ali bo celo Linus sam brcnil **** iz systemd, bodo še vedno utrjeni v njihove ideje, da so pravilne.
Zdravo! Nisem zelo strokovnjak in me zanima, čemu služi ta "systemd" in zakaj se o njem toliko govori, v čem je težava in kakšna alternativa obstaja? hvala
Komentar SynFlag! Sem od "geeks", "geeks" in "pro linuxeros" do istega.
In to je prihodnost, ki nas čaka; Ubuntu tudi v juhi; Prenosniki Linux samo dostopajo do Steama in igrajo najnovejšo vročo igro. In legije malih gikov, ki ne vedo, za kaj gre pod.
PostScript: sistemski koncept ozadja je zanič.
gumba adk in forum nista vidna na glavni strani
Torej je po @SynFlag zdaj vsak, ki ni protisistemski, n00b, ekstremistični verski fanatik in kuga, ki kvari GNU / Linux. S tako ozkim mnenjem ne vem, ali je o tej temi vredno razpravljati. Bolje pustiti, da voda teče in dolgoročno se bo zgodilo, kar se mora zgoditi.
Res je, pride točka, o kateri ni več mogoče razpravljati. samo čas nam bo pokazal, ali bo sytemd nekaj pozitivnega za svet brezplačne programske opreme ali ne.
Prav tako mi daje idejo, da če bo ta distribucija na osnovi debiana, ki ne bo uporabljala systemd, uresničena, bo pomagala umiriti duh tistih, ki o systemdu ne želijo vedeti ničesar.
kot takrat, ko se je pojavil gnome 3 in je bil zgrajen izjemen odpor, dokler se ni pojavil cimet in enotnost, ki omogoča nadaljnje uporabo aplikacij gnome na namizju z več konfiguracijami in zasnovo, ki je bolj premišljena za računalnik in ne toliko za dotik
Mogoče je to, Rolo (pojav Devuana), lahko točka konsenza. Mislim, da ga vsi potrebujemo, da vsebuje polarizirano in vojaško razpravno okolje. Devuan bo prostor za ustvarjanje in kontinuiteto načina dela, kar bo pomagalo umiriti duhove. Proces, ki smo ga živeli v Debianu, je bil boleč, vendar se moramo soočiti s situacijo, ni druge izbire, kot da sprejmemo ločitev. To je na koncu podobno ločitvam. Ta vilica je lahko prepis mirovne pogodbe in točka in del. Obstajale so alternative, seveda Slackware, Gentoo, Funtoo, Crux, PCLinux OS, zdaj Manjaro (če jih naštejemo le nekaj) ... toda scena "deb" je zahtevala alternativo brez systemd. Zdi se jasno, da nihče ne bo nikogar prepričal, argumenti so na mizi in ni soglasja (kljub temu, da ima systemd dobre ideje in nevarnosti, ki jih prinaša ta programska oprema, so očitne). Čas je za vilice in za pridobitev svobode za uporabnika (kajti gre za brezplačno programsko opremo, kajne?)
Eden od dejavnikov, ki je vplival na postopek, je bil občutek "razočaranja" nekaterih, ki zaupamo Debianu. Zato je Devuan predstavljen kot vilica in ne kot derivat. Napetost je, ker nikomur ni všeč, kar se je zgodilo; niti prosistemski (torej nekateri besni napadi, ki poskušajo obrekovati) niti protisistemski (ki so stavili na vilice). V okolju je "na eni strani in na drugi strani" koliko talenta lahko izgubimo? "
Vsi uporabniki Debiana gledajo distro na "določen" način (to lahko velja tudi za druge distribucije). Obstajajo tisti, ki občudujejo njegovo tehnično kakovost, drugi njegovo družbeno pogodbo, njen vpliv v svetu Linuxa, spoštovanje, ki si ga je pridobil v preteklih letih, njegovo stabilnost v kritičnih proizvodnih okoljih ... Pri nekaterih uporabnikih se je to dojemanje spremenilo in pojavilo se je razočaranje. Razočaranje, razočaranje, imenujte to, kot želite. Od tam do ločitve je le majhen korak.
Ločitev v Debianu je podobna kot pri NetBSD in OpenBSD. Čeprav bo pokazal čas. V vilicah vidim veliko pričakovanj, zato se mi zdi, da to ne bo minljiva in sterilna distribucija. Ravno danes je član ekipe gnome komentiral Devuanov poštni seznam (čeprav je to storil nerodno), to po mojem mnenju kaže na to, da Devuan ustvarja zanimanje in želi na nek način dialog .
Kakorkoli, dober vikend.
@rolo
Če rečem, da je video mogoče prevarati ali da je programska oprema popolna zabloda in žalitev, sem v svojem življenju PU ** prevaral nekaj, da bi ustvaril mit, nikoli pa se ne pohvalim, da sem to napako videl s svojimi sredstvi in ne z mojimi triki. Vsi gredo na **** kot na ***** in ne bom dal več v sistemske razprave, ker je povsem do prdec, nihče noče ničesar razumeti in vse je kot izpadanje, kar, sovražim, ker vse To je z dogmo vere. Bodite zadovoljni s sistemom.
@SynFlag nasilje laže
Ta videoposnetek dokazuje napačnost izjave, da če je eden od sistemskih modulov uničen, povzroči, da se systemd sesuje, saj očitno iz tega, kar prikazuje vaš video, ni bilo xddddd in mimogrede journal teče kot root, zato, če tretja oseba vstopi in zlonamerno zajeba binarni dnevnik dnevnika, me ne bi skrbel sistemd, temveč varnost računalnika. xdddddd. Na koncu na temo video posnetka ponovite prikazano urejanje z nano datoteko /var/log/journal/24f02f5b2b16758b820ea6a751ed6efb/system.journal in ko znova zaženete, ugotovite, da obstaja nov system.journal in sistem @@ 24f02f5b2b16758 @@ 820f6f751bXNUMXbXNUMX @@ XNUMXfXNUMXfXNUMXbXNUMXbXNUMX @@ XNUMXfXNUMXfXNUMXbXNUMXbXNUMX dnevnik, ki je poškodovan binarni.
Z drugimi besedami, dnevnik ugotovi, da je datoteka poškodovana, zato je ne preimenuje in znova ustvari novo, ne vidim, v čem je težava ??, enako kot če bi bila datoteka system.journal izbrisana, dnevnik jo vrne v ustvariti.
Zanima me, kaj bi se zgodilo, če bi uničil navadno besedilno datoteko dnevnika s šestnajstiškim urejevalnikom, zagotovo dokler človek ne ugotovi, da je datoteka poškodovana, bi bili vsi podatki uničeni.
Pogovorimo se malo o reviji, ki je ena najpogostejših kritik sistema systemd.
journal je zelo pomembna komponenta systemd-a, ki zajema sporočila Syslog, sporočila dnevnika jedra, RAM in začetna sporočila o zagonu, pa tudi sporočila, napisana v STDOUT / TDERR, in vse te informacije da na voljo uporabniku.
Najpomembneje pa je, da se dnevnik lahko uporablja vzporedno ali kot nadomestek tradicionalnega demona syslog, kot je rsyslog ali syslog-ng, zato ima lahko previdni sysadmin rsyslog ali syslog-ng kot drugo orodje za poizvedbe, razen pretvorbe zapisov dnevnika v navadno besedilo, če se binarna datoteka poškoduje
Drugo pomembno dejstvo o dnevniku je, da če mapa / var / log / journal ni ustvarjena, se informacije shranijo le začasno in se ob vsakem ponovnem zagonu izgubijo.
na primer, ko sem v debian vpisal systemd, obstojnost dnevnika ni bila aktivna, zato sem moral ročno ustvariti mapo dnevnika
http://0pointer.net/blog/projects/journalctl.html
Tisti, ki znajo angleško, ne morejo zamuditi pogovorov med razvijalci Devuan, med drugim tudi Jaromil Dimkr max2344 na IRC kanalu #devuan.
Zelo zabavno je brati preiskave sistemske kode, saj so jo namerno razlili, da bi okužili (ustvarili nepotrebne odvisnosti).
Systemd me moti ... že od spredaj ... težko je. Majhna dokumentacija niti prekleti tanki ne poganjata samo KDM ali gdm, v lahkem sistemu pa hočem, da ga tanek lxdm ne podpira ali prevaja ... .. Resno, da še prej ... sem bil vesel, da bi morali. Resnica je, da sem začel uporabljati openrc, kot pravijo v gentooju, in pomagal je ... Veliko
@rolo
Si drzen in izkrivljač novic, ki to govori. To je najhujša žalitev, če mi rečete, da lažem ali ponarejam podatke, resnično se mi gnusi, kako da bi ubranil nekaj, kar napadate na ljudi, ki delajo resne PoC, kot sem jaz. Dnevnik se poškoduje, sistem se zruši, ponovni zagon storitve ne deluje, zato ni druge izbire, kot da znova zaženete računalnik, kar ni najboljše pri vdrtem strežniku, mi boste povedali, da če je bila ogrožena varnost, je najbolje znova zagnati ali znova namestiti in to je edina stvar, ki bi me morala skrbeti, saj sistemisti pravijo, da se opravičujejo in ne delajo vroče analize KAJ SE JE ZGODILO? priti do te točke? Očitno ste še en izdelek novega sysadmina, če pridete do tistega, ki je bil dvignjen s pomočjo ubuntuja in ima na vašem računalniku varnost DOS 5.0, tako da to, kar pravite, jemljem kot od koga prihaja, me jezi, da dvomite tudi Tisti, ki ponareja vas, ste odgovorili na isti OS s posodobitvami TISTEGA dne? Zagotovo ne, zato poskusite z drugim lažnivcem. Kakšno pomanjkanje zmogljivosti imate, pojdite na delo kot taksist več kot to. Dvomim, da vam bo to dalo, nehajte se igrati z linuxom in še naprej iščite pr0n
Poglejmo golob (synflag), oče vam bo pokazal, kako lahko dnevnik nadaljuje z delom, potem ko je iz nekega razloga poškodovana naša binarna datoteka dnevnika dnevnika, ne da bi morali znova zagnati računalnik.
V tem primeru izhajamo iz osnovne namestitve debian 8 jessie.
privzeto systemd-journal.service prihaja s funkcijo "storage = auto", zato je za trajni zapis dnevnikov potrebno predhodno ustvariti datoteko v / var / log / journal /.
# mkdir -p / var / log / journal /
Če želite, da dnevnik začne zapisovati dnevnike, računalnika NI treba znova zagnati, ampak:
# systemctl ponovno naloži systemd-journal.service
o
# systemctl prisilno naloži systemd-journal.service
### zdaj bomo simulirali, da je binarni dnevnik dnevnika poškodovan ###
# cd / var / log / journal
#ls
24f02f5b2b19808b820ea0a980ed6efb
# cd 24f02f5b2b19808b820ea0a980ed6efb
# nano sistem.revija
### zdaj spremenimo nekaj vrstic datoteke, da simuliramo, da je poškodovana
#journalctl
### po pričakovanjih se nič ne zgodi
#### ali je treba računalnik znova zagnati, da lahko dnevnik ustvari novo binarno datoteko? ŠT
# systemctl prisilno naloži systemd-journal.service
#ls
system@24f02f5b2b19808b820ea0a980ed6efb-0000000000000001-0005069a53abf581.journal
sistem.časopis
#journalctl
### Kot vidimo, dnevnik ustvari novo binarno datoteko dnevnika in zdaj lahko ponovno dostopamo do informacij, ne da bi morali kadar koli znova zagnati računalnik
https://www.youtube.com/watch?v=hEagyMdkN4A&feature=youtu.be
zaključek: synflag ali ste nevedni ali ste pravljičar
Ta končna obleka
zaradi tipkarske napake in zlorabe kopiranja in lepljenja sem napisal systemd-journal.service, v resnici pa se storitev imenuje systemd-journald.service
Pichon?, ... kako narobe si suh, resno .. To sem že vedel, prijavi napako v rdečem klobuku, da vidiš, kaj so rekli, udaril bom odgovor, ali boš ujel:
Če odstranite izhodno datoteko ali prepišete njene dele, demon v resnici ne more ničesar storiti: če ima napadalec dovoljenja za spreminjanje izhodne datoteke, je že zmagal. Demon bi lahko preveril nekatere od teh stvari, vendar bi bilo to precej neučinkovito in v resnici ne bi bilo koristno za nič. Če želite, lahko nastavite periodični kriptografski podpis z 'journalctl –setup-keys'. Oglejte si priročno stran journalctl.
Journalctl je odvisen od rsyslog, ne samodejno se znova zažene v primeru napake v dnevniku, ki je rsyslog ne potrebuje, skupaj, za pošiljanje v rsyslog morate uporabiti fordward in tako je napisan kljub vsemu in dnevnik dnevnika je obnovljen , to je oblikovna napaka journalda, če je nočete videti, me razstrelite.
@rolo
V videoposnetku (ne vem, če ste to storili) vidim, da se v minuti 2:11 uporablja ls in ne ls -l, kar bi omogočilo ogled velikosti, ki jo je imela prvotno datoteka system.journal, nato jo urejajo z nano in dodajte prazne vrstice, znova zaženite storitev z roko in v minuti 3:15 spet naredijo ls in ne ls -l, nato v minuti 3:20 vidijo dnevnik z journalctl, to prikazuje trenutni dnevnik, ki je v redu.
Zdaj pa moja vprašanja:
1 - ker je uporabljen ls in ne ls -l, da bi videli originalno velikost dnevnika, preden ga uredimo
2 - kaj se je zgodilo s starim dnevnikom? kam jo je systemd dal v pokvarjeni binarni dnevnik?
3 - s katerim ukazom systemd lahko popravite poškodovan binarni dnevnik ... ki ga ne bi smeli izbrisati
pozdrav
@anonymous
Zdaj pa moja vprašanja:
1 - ker je uporabljen ls in ne ls -l, da bi videli originalno velikost dnevnika, preden ga uredimo
2 - kaj se je zgodilo s starim dnevnikom? kam jo je systemd dal v pokvarjeni binarni dnevnik?
3 - s katerim ukazom systemd lahko popravite poškodovan binarni dnevnik ... ki ga ne bi smeli izbrisati
1 resnica je, da nisem razmišljal o tem, samo uporabite ls, da vidite, katere datoteke so bile v imeniku, toda če vas zanima, jih lahko podvojite, postopek je podroben, in to v virtualni škatli (namestitev baze debian je piškot)
2 stari dnevnik ostane v istem imeniku, le systemd ga preimenuje s kopico številk in črk (prikazano v videoposnetku)
3 V vsakem primeru lahko poskusite uporabiti programe drugih ponudnikov (predpostavljam nekaj šestnajstiških urejevalnikov), saj če bi systemd popravil poškodovano datoteko, je ne bi preimenoval ali ustvaril nove. V vsakem primeru, in kot sem že omenil v tej objavi, bi previdni sysadmin lahko uporabil rsyslog ali syslog-ng kot drugo orodje za poizvedbe, razen pretvorbe zapisov dnevnika v navadno besedilo, če bi binarna datoteka poškodovana. .
Mislim, ni ideja prepričati nikogar, da uporablja systemd (celo rad bi, da v namestitvenem programu debian obstaja možnost, da izbere int). ne bom pa molčal, ko berem nevedne ali čudovite, ki nenehno ponavljajo laži o systemd, kot obstaja blog, ko človek vidi, da ti reki ne sovpadajo z resničnostjo. in kot je rekel Aristotel, edina resnica je resničnost 😉
@rolo
Video sem še enkrat pogledal in če je bil tam naveden, je bilo le številčno ime tako dolgo, da sem ga videl, mislil sem, da je to imenik ... Suvereno ime.
Glede popravila binarnega datoteke je logično, kar pravite ... če bi ga lahko popravil, ne bi ustvaril novega.
Končno mi ostaja, da ne bi smel biti binarni, da se to ne bi zgodilo in da bi ga lahko videli brez posebnih orodij z journalctl ... Še vedno ne razumem, kaj je privedlo do uporabe binarne oblike.
Lep pozdrav in hvala za odgovor
Rolo, posveti se nečemu drugemu:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393
Vedela sem, ne da bi vedela ... Kako opazite razliko med tistim, ki poskuša stvari, in drugim, ki dela samo prdeče videoposnetke
Prišel sem, da zaprem ocote de Rolo, poročali so o napaki, ki je vidna v mojem PoC, zato zaprite ocote pichon:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393
Če želite videti čudovito:
1 Izjavili ste, da je bil za rešitev revije potreben ponovni zagon računalnika kot v sistemu Windows TOTALLY FALSE
Pokazal sem vam, da je to laž, in v videoposnetku, ki ste ga storili v nobenem trenutku, ne uporabljate ukaza systemctl force-reload systemd-journald.service, ker če bi ga uporabili, bi se vaš argument zrušil (ali pa niste poznali ukaza, ki bi pokazal, da ste nevednega ali ga namerno ni uporabil, kar bi pokazalo, da ste pravljičar)
2 Pravite, da obstajajo poročila o napakah, po eni strani pa je popolnoma nepomembno, saj običajno ljudje veliko neumnosti prijavijo kot napako (da boste razumeli, da vsako poročilo o napaki ni prava napaka), mi celo daje idejo, da ste to prijavili sami enako. Po drugi strani pa imajo vsi programi napake (koliko prijavljenih napak vsebuje sysvinit (program, star približno 20 let)), dobro pa je, da poročilo pomaga razvijalcem pri odkrivanju in reševanju težav (nekateri hitreje, drugi počasneje)
3 Pravite, da se pri napaki, ki jo ustvarite v dnevniku, pri ponovnem zagonu systemd zruši, saj lahko v videoposnetku vidite, da morate prisilno znova zagnati virtualbox. Popolnoma napačno
Resnica je, da systemd ne zruši, saj se sistem zažene popolnoma (če se ne zažene systemd, bi vas spustila jedra in morali bi vstopiti v način obnovitve)
Z vami se zgodi, da sistem preverite, ko poskušate z urejevalnikom besedila urediti binarno datoteko, dejavnikov pa je lahko veliko, na primer dodeljeni pomnilnik, stanje operacijskega sistema (v videoposnetku sistem traja dolgo, da se zažene in izklopite tisto, kar kaže, da ne gre za čisto namestitev 0 (kar je priporočljivo za to vrsto primerov) itd. Lahko vam povem le, da je binarni zapis, ki sem ga uredil približno 10 ali 20 krat, in ni bil nikoli preverjen. To tudi kaže, da ste ali nevedni ali pravljičar.
4 Zdaj pravite, da je dnevnik odvisen od rsyslog TOTALLY FALSE, dejstvo je, da ga lahko vsakdo preveri tako, da namesti ali odstrani rsyslog in vidi, da dnevnik deluje popolnoma
Zelo bi hvaležen, če zapustite to nezdravo obsedenost z mano, nisem kriv, da ste nevedni ali čudoviti
Zaključek:
Ne želite uporabljati systemd, mislim, da je super, zdaj vam ni treba širiti terorja z lažmi, da bi privržence pripeljali do vašega protisistemskega križarskega pohoda. Živela sem in pustila živeti, da je na svetu prostor za brezplačno programsko opremo 😉
pojasnilo k točki 3, bi mi nekdo rekel, da ker je systemd v pid1, zrušitev stroja pomeni to sistemsko čelado. Dve stvari, najprej tukaj je bilo navedeno, da je systemd strmoglavil zaradi okvare dnevnika, v resnici pa je kljukica za vnos binarne datoteke (ki se uporablja v realnem času) z urejevalnikom besedila, pojasnjujem tudi, da v vsi testi, ki sem jih opravil, nikoli niso preverili navideznega stroja. Drugič, nihče pri zdravi pameti ne more trditi, da linux nima oznake xddd,
Čudovito?, Suh, zadrži se malo, čudovito svojo staro žensko, ki pravi, da vržem gumo, ko se je ne dotaknem s palico, se vračam k spoštovanju:
1. - Znova morate zagnati ali prisiliti ponovni zagon storitve, kar ni idealno in v CentOS 7, ko sem ga preizkusil, ponovni zagon storitve ni naredil ničesar, ne pozabite, da gre za različico 208 in ne za novo 217 ali 216 Fedore.
2.- Nepomembni in tisti, ki prijavijo napake? ... idiot si, niti ti ne odgovorim
3.- NESREČNA, različica, ki sem jo tisti dan poskušal na videu, ki jo lahko vidite, celoten OS se je zrušil, zakaj mislite, da je orto nesrečna laž? Nisem lažnivi opica, pojdite po cindor pajero.
4. - Odvisno od tega, da se sam regenerira, tega ne naredi sam, pravzaprav sem to predlagal sistemskim razvijalcem kot funkcijo, da se sam regenerira, ne da bi ustavil beleženje, razen če se storitev znova zažene, saj so jo vzeli kot to, kar so da dodam, zato sesaj mojega tiča in mi reci hvala očka za sodelovanje, medtem ko gledam pornografijo.
Adijo suh, naveličal sem se pogovorov z opicami, ker raje grem v živalski vrt, ko si na ravni mojega anusa, mi klepetamo.
@SynFlag se opravičujem, nisem vedel, da si bolan, resnično sem verjel, da si čudovit in neveden, toda s tem, kar si pravkar napisal, se zavedam, da si v resnici v blodnji.
no nič, upam, da boste bolje diplomirali po svojih zdravilih in se vrnili v resničnost, na silo! ti lahko!!!
Berem in berem in berem, vendar ničesar ne razumem, vem le, da odkar je Xubuntu 14.04.1 izšel do danes, nisem imel nobenih težav s prenosnikom ali laserskim tiskalnikom hp 1102, sploh ne vem ničesar, sem uporabnik in Ne vem, ali je systemd slabši ali ni primeren za init, vendar ponavljam, da nimam težav z xubuntujem. 🙂
Berem, berem in preberem in vem le, da podoživljam staro temo. XD