Afmystificere System D.

Hver dag udgør vores computere en vigtigere del af vores liv, hvis det har en slags problemer, påvirker det vores humør, vores humor hehe. Sikker på, Windows-brugere er mere tilbøjelige til panikanfald end hvis vira (længe leve linux!), hvad hvis defragmentering af harddisken, hvad hvis søgning og installation af Clean Master til pc (selvom vi her i Linux stadig skal rense systemet, er BleachBit et af de foretrukne alternativer). For nylig har Linux-brugere (nogle) en bestemt hovedpine kaldet: systemd

Nå til det punkt har jeg læst en interessant artikel om systemd, som synes at være tendensen ikke længe.

SystemD, som nogle synes om (og jeg vil bruge en vens ord), en ring for at styre dem alle ... For andre kommer det simpelthen ikke eller går, så længe computeren fungerer fint, betyder det ikke noget, om init gør X- eller Y-ting, eller hvis systemd bruges. Til denne, der skriver, ja ... lad os sige, at jeg foretrækker init, jeg finder det enklere 🙂

Jeg lader artiklen være her:

Før jeg begynder, må jeg sige, at jeg ikke kan lide beslutningen om at ændre ting i Debian, men på intet tidspunkt planlægger jeg at opgive min elskede spiral. Jeg prøver bare det, hvis vi skal diskutere et emne, i det mindste gør vi det så forberedt som muligt, selvom jeg selv ikke betragter mig selv som pro-systemd. For at opnå demystificering af systemd vil jeg stole på et websted, hvor udviklere giver deres synspunkt som kom til mine hænder af en kollega, der synes at være pro-systemd, selvom han ikke er en Debian-bruger. Når det er sagt, tror jeg, jeg kan gå videre til at forsøge at afmystificere det, der siges om systemd.

systemd er binærbaseret

Måske er dette et af de aspekter, der chokerer os mest, hvis alt er baseret på binært, hvordan overvåger vi de ting, vi normalt gør ved hjælp af logfiler? Jeg har ingen idé om, hvordan denne myte blev født, men det er ikke helt sandt.

systemd er konfigureret næsten udelukkende gennem almindelige tekstfiler. Nogle indstillinger, der også kan ændres med kernekommandolinjen og gennem miljøvariabler. Der er ikke noget binært i din konfiguration (ikke engang XML). Bare en simpel, ligetil og let at læse tekstfil.

systemd fans homer simpson

Den ting er monolitisk og styrer alt

Før jeg kom til den førnævnte hjemmeside, indrømmer jeg, at jeg selv tænkte sådan, men efter at have læst, hvad dens udviklere siger, har min mening ændret noget ...

Hvis du bygger systemd med alle konfigurationsindstillinger aktiveret, bygger du 69 individuelle binære filer. Disse binære filer tjener forskellige opgaver og adskilles omhyggeligt af en række årsager. For eksempel er systemd designet med sikkerhed i tankerne, derfor kører de fleste dæmoner med mindst privilegier (f.eks. Ved hjælp af kernefunktioner) og er kun ansvarlige for meget specifikke opgaver for at minimere deres fodaftryk. sikkerhed og påvirkning. Systemd paralleller starter også mere end nogen tidligere løsning. Denne "parallelisering" oprettes ved at køre forskellige processer parallelt. Derfor ses det, at systemd er meget godt opdelt i mange binære filer og derfor processer. Faktisk adskiller mange af disse binære filer sig så godt, at de er meget nyttige uden for systemd.

En pakke, der indeholdt 69 individuelle binære filer, kunne næppe kaldes monolitisk. Hvad der dog adskiller sig fra tidligere løsninger er, at vi sender flere komponenter i en enkelt tarball og holder dem kædet i et enkelt arkiv med en samlet frigivelsescyklus.

Det ligner ikke Unix

Der er bestemt en vis sandhed ved det. Systemd-kildefilerne indeholder ikke en enkelt kodelinje fra de originale UNIX-linjer. Imidlertid stammer inspiration fra UNIX, og der er således en masse UNIX i systemd. Et eksempel ville være UNIX-ideen "alt er en fil", hvilket afspejles i, at i systemd er alle tjenester eksponeret ved kørsel i et kernefilsystem, c -grupper. Så et af de originale træk ved UNIX var support med flere sæder, baseret på indbygget terminalstøtte. Med systemd bragte vi support med flere sæder igen, men denne gang med fuld support til nutidens hardware, der dækker grafik, mus, lyd, webcams og mere. Faktisk er designet af systemd som en række integrerede værktøjer, der hver har deres individuelle formål, men når de bruges sammen, er mere end summen af ​​delene, hvilket mere eller mindre er kernen i UNIX-filosofien. Så den måde, hvorpå vores projekt håndteres (dvs. at beholde det meste af operativsystemets kerne i et enkelt git-arkiv) er meget tættere på BSD-modellen (som er en ægte UNIX, i modsætning til Linux) for at få tingene gjort (hvor det meste af kerneoperativsystemet opbevares i et enkelt CVS / SVN-lager), hvilket aldrig var tilfældet på Linux.

I sidste ende betyder spørgsmålet om, hvorvidt noget er UNIX, ikke meget meget. At være teknisk fremragende er det næppe unikt for UNIX. For os er UNIX en vigtig indflydelse (faktisk den største), men vi har også andre påvirkninger. Derfor vil systemd være meget UNIX i nogle områder og i andre lidt mindre.

Det er meget komplekst ...

Der er bestemt en vis sandhed ved det. Moderne computere er komplekse dyr, og operativsystemet, der kører på dem, vil naturligvis også være det, så de skal være komplekse. Systemd er dog bestemt ikke mere kompliceret end tidligere implementeringer af de samme komponenter. Det er enklere og har mindre redundans. På den anden side involverer opbygning af et simpelt systemd-baseret operativsystem langt færre pakker end traditionelle Linux-anvendelser. Færre pakker gør det lettere at opbygge dit system, det slipper af indbyrdes afhængighed og meget af den forskellige opførsel af alle involverede komponenter.

Det lader mig ikke bruge shell-scripts

Dette er helt usant. simpelthen Vi bruger dem ikke til opstartsprocessen, fordi vi mener, at de ikke er det bedste værktøj til det specifikke formål, men det betyder ikke, at systemd var uforenelig med dem. Du kan nemt køre shell-scripts som systemd-tjenester eller dæmoner, du kan køre scripts skrevet i cualquier sprog som systemd-tjenester, da systemd ikke er ligeglad med, hvad der er inde i dets eksekverbare. På den anden side bruger vi stort set shell-scripts til vores egne formål til installation, bygning, test af systemd. Og du kan indsætte scripts i den tidlige startproces, de bruges til normale tjenester, de kan køres ved sidste stop, der er praktisk talt ingen grænser.

På dette tidspunkt antager jeg, at nogle af de vigtigste overbevisninger måske er blevet afklaret, på trods af at jeg ikke har følt mig som en talsmand for forandring og har mine betænkeligheder ved ”en dæmon til at kontrollere dem alle"Jeg tror, ​​at i sidste ende ingen vil tør sige, at det i det mindste ikke virker, jeg kender endda nogle brugere, der bemærker, at med systemd" kører pc'en hurtigere ", men det ville være andre ting, der kunne diskuteres. For øjeblikket er det kun tilbage for mig at invitere dig til her at diskutere de synspunkter, du har om opstartsmanageren, som mange distributioner har vedtaget, selvom de største reaktioner nu ses i Debian-samfundet, som endda har født en ny gaffel med alt dette. Uanset om du kan lide det eller ej, er det et spørgsmål for alle, for min del vil jeg bare gøre min del i at afmystificere systemd, der til sidst vil være til stede i Jessie, den næste stabile version af Debian.

 Jeg så artiklen i GUTL (som igen blev taget fra FraAbreus)

poettering-1984

Systemd strøm?

Jeg er en af ​​dem, der ikke læser meget nyt, når noget skaber så meget kontrovers, jeg foretrækker at blive med mere tekniske detaljer. Er det…. nogle gange føler jeg, at visse emner holder op med kun at være en teknisk diskussion eller debat og bliver som et af disse berømtheds sladder 🙁

Først en åben række fra en bruger til systemd kaldet systemd VS intelligens, så sagde Linus Torvalds det systemd er ikke så slemt hvordan de maler detog en eller anden grund, hvis han har), en gaffel kaldet ubrugelig ... Ingen kommentarer ... og endelig Devuan.

Jeg vil ikke sige, om det er så slemt som de siger, mindre dårligt eller værre. Systemet fungerer for mig uden problemer, men for personlig smag foretrækker jeg init, da dets måde at organisere forskellige ting på (som f.eks. Logfiler) kan jeg bedre lide, men hej, hvis systemd bliver kaldt en løbshest og skal udskiftes til i det (Ville det være vores pakke-muldyr, som gør alt andet end langsomt?) Nå ... mand, så længe ændringen ikke er ekstremt brat, kan brugerne tilpasse sig uden meget problemer, og systemet fungerer bedre (ja, bedre, det er det alligevel ikke værd!), Velkommen 😀


Indholdet af artiklen overholder vores principper for redaktionel etik. Klik på for at rapportere en fejl her.

114 kommentarer, lad dine

Efterlad din kommentar

Din e-mailadresse vil ikke blive offentliggjort. Obligatoriske felter er markeret med *

*

*

  1. Ansvarlig for dataene: Miguel Ángel Gatón
  2. Formålet med dataene: Control SPAM, management af kommentarer.
  3. Legitimering: Dit samtykke
  4. Kommunikation af dataene: Dataene vil ikke blive kommunikeret til tredjemand, undtagen ved juridisk forpligtelse.
  5. Datalagring: Database hostet af Occentus Networks (EU)
  6. Rettigheder: Du kan til enhver tid begrænse, gendanne og slette dine oplysninger.

  1.   mørkere sagde han

    Meget god artikel, jeg har været med Linux Mint 17.1 Rebecca med systemd i et par dage, og jeg føler mig meget mere flydende end i tidligere versioner, jeg ved ikke meget om dette, fordi jeg er en almindelig bruger, der lærer om dette, men Jeg vil være opmærksom på, at dette er den første artikel, jeg læser, der ikke taler skadedyr af systemD.

    1.    SynFlag sagde han

      For noget, vil han være den første, du læser, der ikke taler skadedyr om ham, og på den anden side, fortæl mig, bruger du din mynte som server? Jeg mener, det ville ikke generer dig, hvis den har en fejl fra tid til anden, nej? Det er derfor, du bruger Mint, og det er derfor, det ikke generer dig, du kan ikke lide det, men heller ikke systemd skruer dig. Når du har fejl, og derfor har du alvorlige problemer i alvorlige miljøer, vil det genere dig.

      1.    carlos sagde han

        Dude, enhver Debian Stable-baseret distro, du anbefaler? Jeg kunne bruge Debian, men du skal konfigurere mange ting, når de er installeret, codecs osv ... Hvilken anbefaler du? tak.

    2.    Santiago Burgos sagde han

      Og hvordan lykkedes det dig at få systemd til Linux Mint? Jeg ville prøve at sætte det ind, men jeg ved ikke, om der skal gøres noget yderligere (som teoretisk set allerede bringer Ubuntu), hvis du har nogen vejledning i sagen eller noget, du kan give mig videre, jeg ville sætte stor pris på det

  2.   Giskard sagde han

    Meget god artikel. Lad os se, om Taliban anti-SystemD læste det (men jeg tvivler på det)

    Under alle omstændigheder vil jeg om et år se dem bruge SystemD, og ​​de vil benægte det, de sagde for et år siden. Det er de også. Modstandsdygtig over for ændringer? Sikkert ja.

    1.    elav sagde han

      Du betragter mig som en taliban for ikke at acceptere Systemd, så betragter jeg dig som en taliban for ikke at acceptere, at jeg ikke ønsker at acceptere Systemd. Vi er ved hånden 😉

      1.    jlbaena sagde han

        Som det står i slutningen af ​​dine artikler:

        «Elav: Personlig blog / Twitter / G + / ArchLinux-bruger. Computerforsker, musikelsker, blogger og webdesigner. Administrator og grundlægger af DesdeLinux.net. »

        det vil sige, du bruger en af ​​de første distributioner, som SystemD har vedtaget.

        hilsen

    2.    Jorge Robles sagde han

      OK, knægt.
      Uden ord !!!!, fortsæt med at lege, at livet er rosenrødt.

    3.    Tito sagde han

      For kommentarer som din, kære Giskard, er det derfor, jeg fraskriver mig SystemD, og ​​hvad det står for.
      Og hvis jeg efter 20 år bruger og arbejder med og for Linux, er jeg en taliban; Nå, så være det.

    4.    Giskard sagde han

      Om et år snakker vi. Og elav, jeg nævnte ikke dig. Du dræbte dig selv som Chacumbele.

    5.    Giskard sagde han

      Lad os se, folk læser og læser IKKE. Er der eller er der ingen Taliban imod SystemD? Der er! Og der er andre på den anden side, dem, der forsvarer det tand og søm, som om det var et universalmiddel. Hvad er det alle, der er? Ingen! Slet ikke! Der er dem, der sympatiserer med det ene eller det andet og ser det gode og dårlige både deres egne og andre. Med dem kan du tale uden problemer. Men de vil ikke benægte, at der ER Taliban. Og fra side til side. Og hvis nogen blev stukket af det uden at forstå, at de meget vel IKKE kunne være en Taliban, så hviler jeg på min sag, fordi beviset gør dem skyldige.
      Hvis jeg dialoger med nogen om SystemD og fra starten kalder den person ikke ved hans navn, men Systemshit eller noget lignende, vil jeg oprigtigt gerne have dem til at fortælle mig, om det er muligt at føre en samtale med en sådan person, der oprindeligt diskvalificerer modstander. Det kan det ikke.
      Under alle omstændigheder skal du læse. Lad os se, hvis jeg kommer og siger "der er nogle eschejfhduf (opfundet ord), der slår børn, når de forlader skolen" og nogle få kommer til at forsvare "eschejfhduf" er det ikke at tro, at de selv er det?
      Hvis nogen derude (ikke Taliban, tak og ikke eschejfhduf heller) vil tale om fordele og ulemper ved init og SystemD (som begge har gode og dårlige), vil jeg gerne være der.
      Greetings.

    6.    synflag sagde han

      Taliban-antisystemet? og sig mig, hvad er du? den pro-systemerede Taliban? på den anden side, fordi du antager, at vi ikke vil læse, men at kommentere direkte? Hvem er den lukkede Taliban, der ikke indrømmer diskussion og taler som LP :: «det er det bedste , stol på mig, jeg ved hvad jeg gør ". ?

      Jeg har læst hele artiklen, og jeg kan fortælle dig:

      Systemd er binært baseret: Sandt
      Afmystificering: Falsk

      LP gengiver forkert det, der siges, hvilket er, at systemd-kernen er binær, mange, for mange til at hænge fra PID1, stærkt sammenflettet, så meget, at jeg inviterer dig til at se på #devuan, hvordan det koster at rense f.eks. Logind systemd og resten af ​​pakkerne i Debian, givet hvor bundet den logning, der erstatter PAM, er med systemet.

      Konfigurationen er kortfattet og tillader ikke ALT, som jeg ikke ønsker, ligesom deaktivering af journal, da du hverken kan dræbe PID eller stoppe det eller noget, det er modularitet?, Samme opstart.

      ===========
      "Den ting er monolitisk og styrer alt."

      Det er ud over det faktum, at de er 2 eller 69 binære filer, de er interlaced med hinanden med dbus og dermed med hele operativsystemet, ikke tillader dem at være let uafhængige, det klareste tilfælde er journald, at du ikke kan deaktivere det, også, starten af ​​dæmoner eller tjenester sker gennem "enheder", der er tekstfiler, men intet andet end det, parset af systemd og voila, ingen ændringer eller hacks i tjenester ud over det, der er etableret.

      =======

      "Ser ikke ud som UNIX"

      Jeg vil besvare det kort. Det er ikke i overensstemmelse med LSB eller med POSIX og i dag sagde en fedora-udvikler, der hjælper i #devuan: «Det er sandt, det er ikke, det betyder ikke noget, det der betyder noget er, at det kan køre ting, der er POSIX, hvile, bestemt er jeg ikke interesseret i hvilket operativsystem eller hvad som helst, så længe det fungerer og har gode funktioner ». Og hvorfor det skal være UNIX eller UNIX-lignende: Gør en ting og gør det godt, noget som systemd ikke gør.

      ===========

      ”Systemd er dog bestemt ikke mere kompleks end tidligere implementeringer af de samme komponenter. Det er enklere og har mindre redundans »

      Mindre redundans? De beder dig om at installere EN ANDEN syslog til almindelig tekst, og de bad om det til fjernlogning, før der var systemd-journald-remote, det vil sige de satte den i produktion uden at være i stand til at foretage en fjernlogning uden at være afhængig af rsyslog, noget grundlæggende som centraliseret login. Alligevel har den ikke muligheden, en simpel boolsk til at angive, om vi vil have output i binær eller i almindelig tekst, og hvis det skulle bruge binært, hvorfor ikke noget kendt som berkeley DB, så det kan læses fra ethvert UNIX- eller Linux-system?

      Enkelt?, Virkelig? se på, hvor enkelt det er: http://wiki.gentoo.org/wiki/Comparison_of_init_systems

      Se på antallet af linjer med kode og filer.

      =========================

      "Det lader mig ikke bruge shell-scripts"

      Det er falsk, men igen er det forkert præsenteret, det kritiseres ikke for ikke at tillade brugen af ​​bash-script, men for ikke at bruge dem til at starte tjenester, så det er ikke modificerbart, hackbart og fleksibelt, ligesom upstart eller sysvinit. Og med hackbar mener jeg kodet.

      ============================

      Du tror stadig, at:

      1.- Jeg har slet ingen grund
      2. - Jeg har ikke læst noget og er jeg en taliban?

      1.    Richard sagde han

        Jeg spekulerer på ... skal jeg virkelig stole på, hvad Lennart siger? Hvis nogen neutral fortæller mig, at jeg kan tage visse ting i betragtning, men det smager det samme for mig, da Red Hat udgiver noget for at forsvare Systemd

  3.   ArthurShelby sagde han

    Wow, indtil nogen her omkring siger noget rimeligt og ikke bare frygt og misinformation.

    1.    elav sagde han

      Artiklen er den spanske oversættelse af, hvad Lennart skrev.

      1.    Søren Brun sagde han

        Ingen lovovertrædelse, men oversættelsen ser ud til at være foretaget af Google Translator betaversion ... 🙁 Jeg havde svært ved at forstå nogle afsnit; alligevel er informationen værdsat.

      2.    Martin sagde han

        @ Charlie-Brown, det er fordi Lennart ikke ved, hvordan man udtrykker sig på engelsk meget godt. Så grimt forstås det ved at læse originalen.

  4.   Søren Brun sagde han

    Årsagerne er gyldige, men jeg tror, ​​at nogle måske genererer flere spørgsmål. Under alle omstændigheder er min anbefaling til dem, der har mulighed for: gå til den oprindelige kilde til informationen http://0pointer.net/blog/projects/the-biggest-myths.html (desværre for nogle er det på engelsk), som er meget mere komplet og går så langt som at underbygge op til 30 grunde til, at brugen af ​​SistemD anses for gunstig.

    1.    elav sagde han

      Den artikel, du nævner, er skrevet af skaberen af ​​Systemd. Naturligvis ingen bedre end ham til at forsvare sit arbejde, men jeg opfordrer dig til at se denne video http://hackingthesystem4fun.blogspot.com/2014/12/systemd-journald-centos-7-totally.html og de vil fortælle mig deres konklusioner om det. Jeg siger ikke mere.

      1.    Rolo sagde han

        elav spørgsmålet om journallogfiler, der er i en binær er et af de mest kritiserede punkter, selv linus selv rejste det, når han i en rapport, hvor han indrømmede, at systemd ikke var så slemt. Linus forklarede også, at du kan oprette et script til at tage journaldataene og sætte det i almindelig tekst.
        Også systemd giver dig mulighed for at konfigurere størrelsen på journal binær, hvilket reducerer risikoen for en mulig fejl.

        Faktisk er den kunst, du citerer, meget seriøs, da den ikke har et antydning af objektivitet, og det får mig endda til at spekulere på, om den fejl, den viser, er ægte, eller er den falsk (fuck den proprietære software, så den giver fejlen).

        alle programmer har bugs på et eller andet tidspunkt, men det ser ud til, at de altid vil kigge efter kattens femte ben for at finde noget galt med systemd.

        For eksempel: i debian blev det besluttet, at systemd vil være standardinit, men det forhindrer ikke brug af sysvinit eller openrc eller upstart, og du vil fortælle mig godt ja, men du kan ikke fjerne systemd helt, og mit svar ville være, at det er det samme som det skete i debian wheezy hvor du kan køre openrc, systemd eller upstart, men under sysvinit

        PS: Jeg vil ikke forestille mig, hvor vanvittigt de kommer til at blive med kdbus og dens integration med systemd på Linux-kerneniveau http://kroah.com/log/blog/2014/01/15/kdbus-details/

        1.    elav sagde han

          Hvis det kan være. Desuden planlægger jeg officielt at trække mig tilbage fra diskussionerne om Systemd. Uanset hvad der skal ske 🙂

      2.    Yukiteru sagde han

        @rolo fejlen er dokumenteret, han er blevet præsenteret for flere fejlrapporter, de præsenterer ham en video, og nu siger de, at den er forfalsket. Hvis du vil være sikker, skal du følge trinene og se, hvad der sker. Nu er der flere oplysninger om sagen, opfandt bugs? Det tror jeg ikke.

        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 og hans store forklaringer)
        https://bugzilla.redhat.com/show_bug.cgi?id=974132
        https://bugzilla.redhat.com/show_bug.cgi?id=1157350

      3.    Emmanuel sagde han

        Hvad videoen nævner er bestemt nysgerrig. Som udvikler får vi altid at vide, at en detalje ikke skal påvirke hele systemet / programmet, for eksempel hvis en udvalgt forespørgsel til databasen mislykkes, hvorfor skulle hele programmet gå ned? Det er det samme med SystemD, hvis det mislykkes, fordi andre fejler, ved jeg ikke, hvor godt gjort det er. Der er åbenbart tilfælde, hvor en fejl praktisk talt er en systemfejl, men jo mere internt isoleret programegenskaberne er, desto bedre bliver produktet.
        At angribe software fra sin svage side er ikke nyt, det er snarere en meget almindelig praksis, og at det faktisk skal gøres med hvert program, så at se SystemD falde for journald, er et gyldigt bevis for, at SystemD Det er ikke, hvad der er sagde eller førte til at tro.
        Jo flere ting er afhængige af hinanden med SystemD, jo værre bliver tingene. Hvis en enhed ikke monterede systemet inden montering, ser tingene muligvis ikke så godt ud.
        SystemD er ikke dårligt, jeg hader det ikke, men det er ikke, hvad mange vil have dig til at tro. Det har fordele, men intet som Upstart ikke havde eller kunne have, selvfølgelig, Canonical var involveret, og ingen ville være opmærksomme mere.
        Greetings.

      4.    Rolo sagde han

        men i den videoen ved jeg ikke på noget tidspunkt, at systemet går ned. typen, hvad den gør, er at ændre binær for journalinfo for at generere fejlen, men pointen er, at hver gang den kommer ind i systemd.
        Fra hvad jeg forstår, hvis du begrænser størrelsen på den binære journal, når den når grænsen, opretter den en ny og så videre. mindsker muligheden for at ødelægge alle data.

      5.    Jorgicio sagde han

        Lad os være klare ... Hvem tænker også på at ændre logfilen? xD

      6.    anonym sagde han

        @Jorgicio 4. december 2014 kl. 6:03
        Lad os være klare ... Hvem tænker også på at ændre logfilen? xD

        Hvis du sagde det på en ironisk måde ... okay, forstod jeg :)), men hvis du virkelig spurgte, giver jeg mit synspunkt.

        For mig er det klart, at det ikke er en fejl, det er en funktion !! Ideen er, at hvis der er optrapning af privilegier i en fjernadgang, ville det være meget let for dem, der er enige om at slette loggen ved blot at redigere den for at ødelægge den og for systemd at slette den som korrupt og dermed slippe af med at blive opdaget i den fjernadgang.
        Fortæl mig paranoid, men jeg har ingen anden måde at tænke på ... det er ikke en fejl, det er en funktion, og det er derfor, de ikke accepterer at rette den fejl.

  5.   daryo sagde han

    uff nu gør alle linux-blogs 200 artikler om systemd til det punkt, at jeg allerede kender næsten alle argumenterne mod og for xD.

    og lidt efter lidt er jeg blevet overbevist om nogle af de anti-sistemd argumenter, og blandt hvilke jeg har set (hvis der er noget galt, bedes du rette mig)

    Jeg så endda en artikel om, hvordan du styrter hele systemet, når du redigerer en binær log, og at det ikke giver nogen oplysninger om, at filen er korrupt.

    manglen på klarhed i logfiler

    et udviklingsteam, der ofte ignorerer fejlrapporter

    At være så stor og inkludere så mange ting inde i en init gør systemet meget mere ustabilt, og hvis vi tilføjer bugs som den ovennævnte, skaber det et system uden den stabilitet, som linux kendetegner så meget.

    det siges modulært, men dele af det kan ikke fungere uden andre dele af det samme systemd

    en udvikling, der i det lange løb skaber afhængigheder ved programmering, hvilket gør software som gnome næppe bærbar til systemer uden systemd.

    det erstatter dele (netværksd, logind osv.), der har arbejdet og modtaget vedligeholdelse i årevis, og ændrer dem til nye uden behov, der har tendens til at have mange flere fejl.

  6.   mat1986 sagde han

    Fra det tidspunkt, hvor jeg har brugt Arch-baserede distroer (Manjaro, Bridge Linux, Antergos), der naturligvis bruger systemd, må jeg sige, at jeg ikke har nogen klager over brugen og håndteringen. Det er let at starte tjenester - endnu mere i Bridge, hvor bluetooth eller modemmanager er deaktiveret som standard. Bortset fra en fejl relateret til hwdb.bin (https://bbs.archlinux.org/viewtopic.php?id=189536) Jeg har ikke haft mange problemer. Naturligvis tror jeg ikke, det er alles mening, men personligt har jeg ingen klager 🙂

  7.   Solrak Rainbowarrior sagde han

    Jeg kan ikke lide tanken om, at et firma (Red Hat), der beskyldes for at samarbejde med NSA (bagdøre og amerikansk kontrol), opretter et system, hvor alt styres. En ring til at kontrollere dem alle, om nødvendigt at binde dem i mørket ..

    På den anden side må jeg indrømme, at Intel IRIS PRO 5200 fungerer bedre for mig og næsten aldrig, hvis ikke længere, går mit grafiksystem i stykker, når jeg starter openSUSE 13.1. Og ja, alt er bedre, det starter og lukker meget hurtigere. Hvordan en enkel bruger har haft gavn af mig.

    1.    johnfgs sagde han

      anklaget at samarbejde med NSA

      Jeg fremhæver den vigtige del

      Hvis nogen beskylder dig for at have solgt stoffer, er du automatisk en stofhandler?

      1.    anonym sagde han

        @juanfgs
        Narkotikahandel nr .... en medskyldig ja.

      2.    johnfgs sagde han

        Narkotikahandel nr .... en medskyldig ja.

        Gud ... Jeg ville fornærme dig, men dine egne ord gør det for dig.

  8.   Rafael Castro sagde han

    Bare præciser, at systemd er skrevet, og det er sådan, det skal gøres.

    Stavekontrol

    Ja, det er skrevet systemd, ikke system D eller System D eller endda SystemD. Og det er heller ikke system d. Hvorfor? Fordi det er en systemdæmon, og under Unix / Linux er de med små bogstaver og bliver efterfulgt af små bogstaver d. Og da systemd administrerer systemet, kaldes det systemd. Det er så simpelt. Men så igen, hvis alt det, der synes for simpelt for dig, skal du kalde det (men aldrig stave det!) System Fem hundrede, da D er det romertal for 500 (dette tydeliggør også forholdet til System V, ikke?). Den eneste situation, hvor vi finder det OK at bruge et stort bogstav i navnet (men heller ikke kan lide det) er, hvis du starter en sætning med systemd. På høje helligdage kan du også stave det sÿstëmd. Men så igen er Système D ikke en acceptabel stavemåde og noget helt andet (dog lidt passende).

    http://freedesktop.org/wiki/Software/systemd/

    1.    elav sagde han

      Også her? Du sætter det i GUTL .. men mand, alle siger Linux og ikke GNU / Linux, så med SystemD det samme.

  9.   Tysk sagde han

    Jeg fortæller dig, at det ikke er nødvendigt at bruge logsystemet eller den cron, som systemD giver, du kan følge syslog-ng og cronie for dette eller andre alternativer
    Jeg bruger systemD i ArchLinux, siden jeg var i aur, og det ser ud til at være lettere at håndtere end den afledte og redhat-afledte måde, det har mange konsolkommandoer, der sparer dig for at redigere tekstfilerne og forenkle samlingen af ​​konfiguration af scriptsinstallation (husk at i bue er alt installeret med konsol)
    Og ikke mindst starter systemet hurtigt, i bue kan du starte tjenester parallelt, når du starter systemet, men det er risikabelt

  10.   santiago sagde han

    Hvad jeg synes er dårligt ved problemet er, at de fleste tager side, eller du er pro-systemd eller anti-systemd, og jeg synes, det har sine gode og dårlige ting, jeg er bruger, og jeg begyndte at spille lidt med systemd, virkelig De gode ting er, opstarten er hurtigere og mindre kompleks end resten af ​​initiativet, selvom udgaven af ​​tidsskriftet også generer mig meget.
    Jeg forstår, at de, der virkelig kan sige, om det er godt eller dårligt, er sysadminerne eller eksperterne om emnet, men det ser ud til, at systemdrevet har stoppet med at være noget teknisk for længe siden og blev noget mere "show-stop", for min del er jeg lidt imod, men jeg betragter mig ikke som anti eller pro

  11.   Yukiteru sagde han

    @KZKG_Gaara

    Jeg kan se, at meget af det, du kommenterer her, er det samme som Lennart har offentliggjort på sin blog, mere præcist i dette indlæg: http://0pointer.de/blog/projects/the-biggest-myths.html.

    Selvfølgelig har indlægget haft visse "afklaringer" og har afsat bestemt teknisk indhold for at være let at fordøje information til dem, der skal læse den, men vi vil være seriøse og oprigtige, selvom sandheden gør ondt: systemd har mange af de ting, som Lennart benægter, at den ikke har, det og meget mere faktisk. Og i denne forstand forklarer jeg delvist.

    1.- Lennart siger, at han ikke er oppustet, og at han ikke har et højt NIH-syndrom (Ikke opfundet her syndrom). Hvis det er tilfældet, bedes nogen forklare mig: Hvorfor en init skal have netværkskontrol (systemd-networkd), dns (systemd-networkd), m-dns (systemd-networkd), logs (journald), coredumps (systemd -coredump), debugs (systemd-coredump og journald), acpi (logind), eskalering af privilegier (logind), kontrol af ntp (systemd-timesyncd), kontrol over dev (systemd tog al udevs funktionalitet), kontrol af / dev / random (tilfældigt tal generator) og den seneste kontrol over TTY (systemd-trøstet)? Var der ikke en masse værktøjer oprettet til sådanne formål, at systemd nu tilføjer sine egne nogle med eksklusiv adgang (journald case)? Hvilken logisk og acceptabel forklaring giver du mig for en init for at være i stand til at bryde kernedebug og cmdline? For at tilføje kontrol over kdbus, den næste IPC, der integreres i kernen. De vil helt sikkert fortælle mig her: «Men du kan installere et andet værktøj til at kontrollere alt dette». Og hvis det er sandt, men mange af disse værktøjer modtager kun en strøm af data kastet af systemd, som i tilfældet med syslog og rsyslog, som forbinder til en data / stream, som journald leverer, så andre værktøjer kan SE, hvad journald kører i sidste ende betyder det bare, at du har to værktøjer, der gør det samme, og et af dem er en pandorakasse. (Fortæl mig venligst ikke, at koden kan revideres, fordi jeg inviterer nogen til at "ryge" journald-koden og dens rammer med systemd og andre relaterede værktøjer)

    2. - Lennart fortæller os også, at systemd tilbyder support til SysV- og LSB-scripts. Dette er en "halv sand" en "hvid løgn" for at sige det, fordi sandheden er, at systemd-214 ikke tilbyder support til bash-scripts, SysV eller LSB, og det er relateret i dens udgivelsesnotater til den version.

    3.- Hvilket systemd er ikke bærbart? Det er et andet svagt punkt. I BSD fungerer det ikke godt, i BSD er der ingen Cgroups blandt andre værktøjer, som systemd har brug for at køre. Men det er af systemdesign grund, ikke fordi det ikke er bærbart. Indtil BSD-kernen ikke opfylder minimumet for at understøtte den, vil systemd ikke arbejde på den platform, og det er ikke nogen skyld, kun at BSD ikke har nogen interesse, heller ikke Lennart. Det er så simpelt. Nu er understøttelsen af ​​andre C-biblioteker en anden ting, velkendte er glibc-problemerne (lav bare en kerne i hånden for at se mængden af ​​muligheder og løsninger, der er foretaget for at undgå disse detaljer, især for glibc 2.3, 2.5 og 2.11 , blandt andre fejl, som glibc har trukket med igennem årene), men det slutter ikke der, det slutter ikke, Lennart har selv sagt, at han har foretrukket at oprette sit eget libc-bibliotek, fordi det for sin gruppe er meget hurtigere at gøre det, end at læse kode, der allerede er oprettet (og dokumenteret forresten), men det stopper ikke der, planlægger de at fjerne glibc og bruge deres libc ikke kun til systemd, men også til Fedora, hvilket gør det standard til konstruktionen af ​​alle deres pakker . NIH Hvor? Det ser ud til, at den gode gamle Lennart kan lide at trolde og stort.

    4.- Det systemd er ikke monolitisk, fordi det er opdelt i 69 binære filer. Ja godt, dette kan diskuteres. systemd har 69 binære filer, der udfører forskellige opgaver, men disse binære filer videregiver deres opgaveoplysninger til systemd, så hvis en mislykkes, øges chancerne for at bryde systemet ganske dramatisk. Dette er veldokumenteret, bugs rapporter bugner af problemer som disse og endnu enklere problemer, dumt simpelt faktisk. systemd kan opdeles i hundredvis af binære filer, men så længe din kerne er under kontrol, fortsætter risikoen for en pause og øges, og hvis du ikke tror på mig, skal du læse fejlrapporterne og have det sjovt.

    Bemærk, at her har jeg ikke kommenteret noget, som systemd er skrald, jeg har kun fremsat "tekniske" kommentarer (det er klart, at tale om tekniske ting bliver meget kompliceret) og gyldigt, bakket op af oplysninger, der er let tilgængelige på internettet. Nu: Hvilken Linux har brug for en standardinit? Ja, det ville bestemt være noget af stor værdi for samfundet. Hvilket systemd er løsningen? Nej, selvom det er tæt, har det bestemt mange positive ting, men dets virusspredning og antallet af ting, det øger risikoen for, hvad der kan gå galt og ender med at skade samfundet.

    PS: Jeg efterlader materiale, hvor du kan bekræfte, hvad jeg siger, læse det vil være ret illustrativt og se, at jeg ikke inkluderer blogs eller noget lignende, ren personlig og baseret kritik. Hilsen.

    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 måske føler du dig identificeret)
    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

    1.    elav sagde han

      Amen broder .. amen ..

    2.    pamp sagde han

      Jeg kan stadig ikke se nogen gyldige grunde til ikke at vedtage systemd. Du fortolker simpelthen hvad du ser med frygt, hvilket resulterer i overdrivelser. Hverken klare og veldefinerede fordele eller ulemper.
      Derudover tillader denne integration den standardisering, som du endda talte om. Ikke kun Red Hat arbejder på systemd, men forskellige virksomheder og frivillige fra andre distributioner.
      Jeg tror, ​​at fejlen er, at driften af ​​systemd ikke undersøges ordentligt.

      1.    Xiep sagde han

        Jeg kan se gyldige grunde i Yukiterus analyse. Bemærk, at jeg i stedet for frygt ser strenghed, præcision og klarhed. Det må være et øjenlæge problem.

      2.    Yukiteru sagde han

        Det er ikke frygt (jeg er ikke bange for et stykke kode), og de er heller ikke overdrivelser (alt, hvad jeg har sagt her, er dokumenteret, og jeg har videregivet nok information, der bekræfter det, information, der forresten kommer ud af listerne og fra sindet / stemmen / Lennarts egen håndskrift og ikke fra en bloggers kommentarer), det er VIRKELIGHEDEN.

        systemd gør alt det og meget mere, og det er noget BEGYNDELIGT (et andet koncept end at være bange) fordi det helt sikkert kræver attributter og gør ting, der i øjeblikket kan gøres på andre måder, og som forresten fungerer bedre og er mere stabile . systemd er meget Windows-lignende, og det kan ikke skjules, ved bare hvad userinit.exe, svchost.exe, smss.exe og andre afhængigheder gør, og sammenlign dem med systemd, ligheden er så stor, at det er en dårlig idé. Nu kan bestemt systemd have en bedre kvalitet end dets Windows-modstykke (eller det modsatte kan ske, ingen ved det virkelig, medmindre du programmerer til Microsoft), men du kan ikke beskylde mig for overvældende og frygtelig, når du læser Lennart selv på en liste og taler om Oprettelse af et helt nyt C-bibliotek, fordi han er træt af Glibc, og til napa skal du smide det lille og ubetydelige tip ind, at libc kan bruges til at bygge alle Fedora-pakkerne. Og hvis du mener, at det er en løgn, og at jeg er overdrevet, vil jeg give dig beskeden i dette link: http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html (på engelsk)

        Fortæl mig nu, hvis det er en overdrivelse at sige foran alle disse ting, at når Linus først beslutter, at CONFIG_VT, som det er, er han nødt til at forlade kernen (situation, der har eksisteret i lang tid) og videregive den til brugerområdet, ikke ske en skør ting som hvis systemd-trøstet er en stærk afhængighed for næsten enhver Linux-installation (noget skal håndtere VT'er, synes du ikke?), ville det ikke sætte forskellige ikke-systemd distroer i rampelyset for at tvinge en switch. Hvis du synes, det er en strækning, så lad mig fortælle dig, at du ikke har nogen idé om, hvad Lennart er i stand til og gør, da hans seneste ændringer påvirker udviklingen af ​​udev gaffel, Gentoo eudev, og han vil fortsætte med at gøre det med sine trusler ved at under bordet (for senere at klage som han gjorde på Google+)

      3.    Yukiteru sagde han

        @xiep Jeg kan ikke være mere enig med din kommentar.

      4.    johnfgs sagde han

        Che Yukiteru, din lange erklæring udelader det faktum, at e-mailen, du linkede til libc, er en april-tåbe-vittighed, se på fodnoten og se på datoen (31. marts, sandsynligvis 1. april i Lennarts tidszone)

        [1] Vi kan tilføje en kerne senere, efter GNU / Hurd er vellykket
        nærme sig.

        Øv din engelske fu, fordi den er vandig og sætter spørgsmålstegn ved al din "forskning".

      5.    Yukiteru sagde han

        @juanfgs du ser ud til at være den eneste, der læser, i det mindste bifalder jeg dig for det, men du skal læse noget meget vigtigt, der er i min kommentar, det betyder ikke noget, jeg lægger det her:

        »NIH Hvor? Det ser ud til, at den gode gamle Lennart kan lide at trolde og stort. "

        Jeg tror ikke, han skrev det af en uskyldig grund, han var opmærksom på, at det var endnu en Lennart-vittighed til aprilens dårlige dag (dårligt humør) såvel som hans lidenskab for at gøre /, / etc og alt andet til / Linux. 🙂

        PS: Tak, men jeg behøver ikke øve mig på engelsk, jeg har brugt sproget siden jeg var 6 år gammel
        aaahh og alt andet er sandt, bekræft det 🙂

      6.    johnfgs sagde han

        Jeg tror ikke, jeg skrev det af en uskyldig grund, jeg vidste det faktum, at det var en anden vittighed fra Lennart for aprilens dårlige dag (dårligt humør) nalist skør

        Dette er direkte sensationalisme, du siger, at du er baseret på fakta, men i virkeligheden følger du din fornemmelse af, at fyren er dårlig og ønsker at overtage verden, og du vrider fakta for at afspejle din tale. Dette er det, der generer mig meget ved anti-systemd mennesker, de hakker ikke ord, når det kommer til at vride fakta og fortælle halve sandheder, selvfølgelig fyldt med deres mening.

        Min "tommelfingerregel" i disse tilfælde er simpelthen den følgende logiske opdeling, startende med den forudsætning, at
        - Jeg er en webudvikler / desktop-app eller cli
        - Jeg har aldrig skrevet et init-system.
        - Jeg er ikke vedligeholder en distro.

        kontrollere, om samtalepartneren har:
        - oprettet et init-system
        - er en aktiv opretholder af init-systemet til en distro

        og virkeligheden er, at de fleste antisystemer fejler denne test, men alligevel er de en håndfuld mennesker, der af en eller anden grund VIDER mere end folkene bag: Debian, Fedora, Archlinux, Linux-kernen, hele GNOME-projektet, sandsynligvis KDE-projektet også da de ikke har klaget over systemd, SUSE og en lang osv.

        Alligevel er hans giftige og glasagtige tale det eneste, han opnår, at skabe uenighed, problemer og andre. Sådan er det punkt, at jeg ikke kan vente på, at de endelig skifter til BSD, da de har truet af Xorg, NetworkManager, PulseAudio, og jeg ved ikke, på grund af ren teknisk uvidenhed, eller fordi de ikke ville klage over det.

      7.    Yukiteru sagde han

        @juanfgs, jeg tager dig med dit ord specifikt om dette:

        «Og virkeligheden er, at det meste af antisystemet ikke består denne test, selvom der er en håndfuld mennesker, der af en eller anden grund VIDER MERE end folket bag: Debian, Fedora, Archlinux, Linux-kernen, hele GNOME-projektet Sandsynligvis også KDE-projektet, da de ikke har klaget over systemd, SUSE og en lang osv.

        Alligevel er hans giftige og glasagtige tale det eneste, han opnår, at skabe uenighed, problemer og andre. Sådan er det punkt, at jeg ikke kan vente på, at de endelig skifter til BSD, da de har truet af Xorg, NetworkManager, PulseAudio, og jeg ved ikke, om på grund af ren teknisk uvidenhed, eller fordi de ikke ville klage over det. "

        Så I OVERENSSTEMMELSE med jer, er vi alle anti-systemd giftige og glasagtige, at det eneste, vi opnår, er uenighed, problemer og så videre. Lad mig fortælle dig, at det er den største vrede, jeg har været i stand til at læse her. Jeg ved ikke, hvorfor det pro-system gider, når et systems strukturelle problemer bringes i lyset, hvilket naturligvis vil påvirke dem på et eller andet tidspunkt, fordi der muligvis ikke er sket noget med dem nu, men på et tidspunkt vil de. det vil, og så vil nogle anti-systemd minde dem om de ord, de sagde mange gange, og ingen stoppede dem, og måske vil nogle andre anti-systemd give dem en hånd.

        Personligt kan jeg ikke lide systemd, men det betyder ikke, at jeg ikke bruger init, det skal jeg, for netop i mit arbejde, hvis jeg skal røre ved en maskine med den init, skal jeg have viden om, hvordan man håndterer det. Derudover har jeg personligt også brugt det, siden jeg kom til Archlinux og endda i Debian og Gentoo, så fortæl mig ikke, at min vision er skæv ved ikke at bruge systemd, jeg har brugt den, og jeg ved, at den halter, og hvis jeg skal hjælpe nogen her i FromLinux-forummet eller på IRC eller Debian-listen (som er den distro, hvor jeg har været længst og stadig bruger i mit arbejde), vil jeg gøre det med glæde, for netop hvis noget glæder mig over Linux-samfundet er, at det på trods af forskellen altid hjælper.

        Nu for at skifte til BSD er det muligt, men jeg vil kun gøre det, hvis systemd bliver noget så virulent, at det ikke tillader mig at bruge nogen anden mulighed, i mellemtiden forbliver jeg på Linux og deaktiverer al den vanvid, inklusive mange af Cgroups-tingene.

      8.    johnfgs sagde han

        og virkeligheden er, at mest anti-systemd

        !=

        Så I OVERENSSTEMMELSE med jer alle anti-systemd

        Igen vrider du ordene, så de passer til din tale. Du er meget godt materiale til en politiker / journalist.

      9.    johnfgs sagde han

        Jeg præciserer, mit problem er ikke, at de nævner tekniske problemer med Systemd, pointen er, at de mange gange indlæser deres tale med løgne, nemlig:

        At hvis systemd vil tvinge dig til at bruge en microhttpd-server (som er et valgfrit modul, der IKKE er installeret som standard), at hvis systemd er en enkelt binær, vil denne systemd blive lukket, fordi lennart betales af microsoft, at binære logfiler De er obligatoriske. Ingen ønsker systemd, og vedtagelsen sker af en politisk lobby.

        Det er det, der chokerer, løgnene. Hvis det var en rimelig diskussion, ville det være det værd, men det er bare den gode FUD.

        At du ikke kan lide det virker perfekt for mig, jeg kan ikke lide meget software, endda programmeringssprog, distroer og andre, men jeg opfinder ikke ting om det, og jeg læser heller ikke det, jeg vil læse og indlæser mine udsagn med personlige følelser for at skade billedet af mennesker, der udvikler det.

      10.    Yukiteru sagde han

        @juanfgs undskyld, men det er ikke mig, der kalder en bestemt gruppe mennesker "giftige og vitrioliske" simpelthen fordi de ikke kan lide et stykke software.

      11.    johnfgs sagde han

        Ikke desto mindre hans tale giftige og vitrioliske det eneste, det opnår, er at skabe uenighed, problemer og andre.

        Igen vride sætninger for at være et offer.

      12.    Yukiteru sagde han

        @juanfgs igen siger jeg dig, det blev sagt af dig, tjek dine ord, jeg gengiver ikke dine ord forkert, jeg lavede bare en kopi / indsæt af dine ord i kommentar 59.

      13.    johnfgs sagde han

        Jeg citerer min tekstkommentar capo, den, du skal læse igen, er dig, fordi du ikke vil forstå, eller hvis du ikke ved, hvordan du skal diskutere. Du tager tingene ud af kontekst og fortolker dem, når de synges for dig. Så hvis du vil vælge at leve i en verden, hvor du føler dig fornærmet, fordi dine argumenter udfordres, forfølger Lennart, Red Hat og Microsoft dig, er det fordi du vælger at tro det.

        Kort her, fordi jeg er klar over, at du ikke er en fornuftig person, fordi du ikke vil forstå, du vil fortolke tingene, som du finder det passende.

        Hvis du vil blive fornærmet, skal du fornærme, men det er dit problem, ikke resten af ​​verden.

      14.    Yukiteru sagde han

        @juanfgs Jeg er ikke generet af dine kommentarer, sandheden er, at jeg ikke ser nogen grund, vi diskuterer, civiliserede mennesker argumenterer uden at skulle bekymre sig om det (det er hvad jeg synes).

        Nu hvis du kan lide at mærke, fordømme (eller hvad du end vil kalde det) folk for deres taler eller handlinger (måske skal du læse min kommentar # 64 og måle bredden af ​​den), det er dit problem, begræns dig til dem handlinger over for dig selv og lad andre være ude af den taske.

        Greetings.

      15.    Xiep sagde han

        "Det meste af anti-systemd", "næsten alt", "alt", "en del af anti-systemd" ... vi afviger, Mariano, vi afviger. I det foreliggende tilfælde: Jeg kan ikke se nogen steder, at Yukiteru har holdt en sensationel tale baseret på hunches (henviser til hans analyse på denne måde har noget vridet), tværtimod har han udviklet solide argumenter om ulemperne af systemd baseret på passende spørgsmål og materiale hentet fra mailinglister og bugspor (såvel som på en høflig og civiliseret måde). Muligvis af denne grund irriterer han nogle, og de angriber ham ved den første kommentar for at miskreditere og diskvalificere ham (denne gang på en giftig måde).

        Hvis du ser, at diskursen for de fleste anti-systemd er giftige og vitrioliske, er det, jeg ser i diskursen fra nogle pro-systemd (jeg ved ikke, om de er et flertal eller et mindretal) hysteri og forfølgelse af dem, der netop de fremfører solide argumenter midt i al støj. At vi i mit land kalder chikanerende dissens.

        Går systemd det godt for dig? Fantastisk, det virker godt for mig, men lad dem, der ikke synes det samme, udtrykke deres forbehold (operativsystemet fungerer muligvis ikke på samme måde).

        hilsen

    3.    pamp sagde han

      Åh forresten, hvorfor blæses der en systemd-fejl op til det punkt, at den spilder hele komponenten, men andre som GCC, glibc eller endda kernen er ikke blevet kritiseret til det punkt for mange af deres bugs?
      Du sagde det selv, glibc har trukket på problemer i lang tid. Llvm har over tid vist sig at have fordele i forhold til GCC. Og her ser jeg ikke den samme kritik.
      Hvorfor ikke gøre det samme med andre projekter?
      Det er simpelthen kollektiv og irrationel frygt for mig.

      1.    Yukiteru sagde han

        Glibc har sine bugs ingen kan skjule dem, der er enorme Glibc bugs, der påvirker kernen og hundredvis af eksekverbare filer. Forskellen mellem Glibc og systemd er, at førstnævnte er en base, hvorfra tusinder af softwareprojekter kan omdannes til binære filer, mens systemd er en init, hvis formål er at være et stabilt, bevist og praktisk talt ufejlbarligt stykke. Ikke kun det, Glibc skal tilpasse sig hundreder af forskellige hardwarearkitekturer (CPU), til forskellige optimeringsflag og unikke egenskaber ved CPU'en, til forskellige former for softwareoptimering, et meget mere besværligt og vanskeligt arbejde end systemd også. Jeg ser virkelig ingen måde at præsentere en sammenligning mellem de to projekter på samme skala.

        Det samme gælder for GCC, GCC er en kompilator, der forresten understøtter mange sprog (i alt 13 tæller de uofficielle) og har karakteristika, der ligner Glibc, understøtter mange arkitekturer (70 arkitekturer til version 4.9), binær optimering flag, CPU-optimeringsflag og mange andre funktioner. Nu er de på samme sværhedsgrad, en kompilator med en init. Svaret er mere end indlysende, startende med, at systemd er i C, og meget af GCC-koden er i assembler, eller du skal bruge assembler til at få ting til at fungere i binært, noget lidt "svært at gøre".

        Hvad er GCC og Glibc fejl? Klar. Selv Linus har givet dem sit angreb, men i GCC og Glibc har de noget positivt, at de i systemd ofte bliver glemt, og det vil sige, en fejl rapporteret, en fejl set, en fejl løst.

    4.    Rolo sagde han

      - vær venlig at forklare mig: Hvorfor en init skal have kontrol over:
      netværk (systemd-netværkd),
      dns (systemd-networkd),
      m-dns (systemd-netværk d), l
      ogs (journald),
      coredumps (systemd-coredump),
      debugs (systemd-coredump og journald),
      acpi (logind), eskalering af privilegier (logind),
      ntp (systemd-timesyncd),
      dev (systemd tog al funktionaliteten fra udev),
      de / dev / random (tilfældig talgenerator)
      TTY (systemd-trøstet)?

      Et tema 100000 gentaget og gentaget, hvad du har brug for at sige er, at systemd kan arbejde uden dem, faktisk i debian er der ikke engang halvdelen af ​​dem, du nævner

      det er også kun et træk ved dets brede tilgang

      lennart: Godt systemd opdeler, hvad det skal gøre, i mange forskellige komponenter (90+ binære filer i disse dage). Hver enkelt kører med færrest mulige privilegier.
      Jeg forestiller mig, at dette ikke er for meget af en forskel coreutils, som også har et stort antal komponenter i en pakke. Og coreutils er sandsynligvis et af de store projekter, der får Linux til at føles som et UNIX-lignende operativsystem, ikke?
      Men ja, systemd er mere kompleks end sysvinit, ingen tvivl. I de sidste 40 år af computing har meget ændret sig, og mange af dem kræver faktisk en vis grad af kompleksitet at håndtere ... Der er meget lidt rundt.

      Fordi du ikke bliver så kompromisløs med freebsd, hvilket gør nøjagtigt det samme, men med dets værktøjer og uden at lade andre blive brugt, hvilket ikke er tilfældet med systemd.

      - Var der ikke en masse værktøjer oprettet til sådanne formål, at systemd nu tilføjer sine egne, nogle med eksklusiv adgang (journald case)?

      Jeg vil ikke benægte, at journaltemaet gemmer informationen i en binær er den svageste ting at forsvare, men det er ikke verdens ende, de kan gemmes i almindelig tekst

      - Hvilken logisk og acceptabel forklaring giver du mig, at en init er i stand til at bryde kernedebug og cmdline?

      Mmmmmmmmmmm …………………. bryde kernen ……. 5000000 ting kan bryde kernen

      - Føj til den kontrol over kdbus, den næste IPC, der integreres i kernen.

      Ifølge lennart Dette har et positivt forhold for udviklere og systemd vil bringe værktøjer til at åbne dbus for administratorer, det vil også give journal- og netværksd busgrænseflader

      - De vil helt sikkert fortælle mig her: "Men du kan installere et andet værktøj til at kontrollere alt det." Og hvis det er sandt, men mange af disse værktøjer modtager kun en strøm af data kastet af systemd, som i tilfældet med syslog og rsyslog, ... det betyder kun, at du har to værktøjer, der gør det samme, og et af dem er en Pandoras æske. (Fortæl mig venligst ikke, at koden kan revideres, fordi jeg inviterer nogen til at "ryge" journald-koden og dens rammer med systemd og andre relaterede værktøjer)

      her går vi ind i konspirationsteorien !!!!! det er tynd fri software intet er skjult

      3.- Hvilket systemd er ikke bærbart? Det er et andet svagt punkt. I BSD fungerer det ikke godt, i BSD er der ingen Cgroups blandt andre værktøjer, som systemd har brug for at køre. Men det er af en systemd designårsag, ikke fordi det ikke er bærbart. Indtil BSD-kernen ikke opfylder minimumet for at understøtte den, vil systemd ikke arbejde på den platform, og det er ikke nogen skyld, kun at BSD ikke har nogen interesse, heller ikke Lennart.

      Nå det er ikke helt korrekt, bsd-udviklerne gør noget, der ligner systemd, som Lennart selv fremhævede i sin g + -konto

      https://plus.google.com/115547683951727699051/posts/g78piqXsbKG

      https://www.youtube.com/watch?v=Mri66Uz6-8Y

      4.- Det systemd er ikke monolitisk, fordi det er opdelt i 69 binære filer. Ja godt, dette kan diskuteres. systemd har 69 binære filer, der udfører forskellige opgaver, men disse binære filer videregiver deres opgaveoplysninger til systemd, så hvis en mislykkes, øges chancerne for at bryde systemet ganske dramatisk. Dette er veldokumenteret, bugs rapporter bugner af problemer som disse og endnu enklere problemer, dumt simpelt faktisk. systemd kan opdeles i hundredvis af binære filer, men så længe din kerne er under kontrol, fortsætter risikoen for en pause og øges, og hvis du ikke tror på mig, skal du læse fejlrapporterne og have det sjovt.

      Hvis du bruger sysvinit, og din TTY dev acpi ntp bryder dit system også, så så ikke terror.

      Monolitisk er freebsd, og du siger ikke noget

      1.    anonym sagde han

        @rolo
        Liste mig nu, hvilke distroer der tog systemd og oprettede de 90 binære filer i separate pakker, det ville være 91 pakker med systemd.
        Og når jeg installerer systemd, beder det mig ikke om nogen af ​​disse 90 pakker som afhængigheder.

        Seriøst, og igen insisterer jeg ... giv mig venligst indstillingerne for –konfigurer-hjælp, som jeg vil lave 91 pakker, der kompileres i hånden med mærke.

        Der er ikke noget værre blindt end den, der ikke ønsker at se ... drenge dette er vand og olie, det ser ud til at der stadig er stædige mennesker, der ikke ser virkeligheden af, hvad redhat er efter.

      2.    Yukiteru sagde han

        @rolo Jeg vil have dig til at installere systemd og fjerne journald, systemd-udev og coredump og bruge indstillinger som eudev og syslog direkte for at se om du kan.

        Denne kommentar kunne ikke få mig til at grine mere seriøst, jeg dør. 😀

        Seriøst nok går de virkelig i besværet med at læse lidt i stedet for at holde fast med strålen i øjet.

      3.    Yukiteru sagde han

        Ingen glemmer også, at Kay Sievers ikke kun brød kernen cmdline, men også ville lukke den, når alt kommer til alt "generisk er generisk".

    5.    Dariem sagde han

      Med andre ord, ifølge dig, gør det faktum, at to processer videregiver oplysninger, dem så koblede, at det faktum, at den ene fejler, gør den anden den store sandsynlighed for fiasko ... fra hvilken softwareudviklingsteori fik du det? Jeg er enig med @pamp, at du taler af irrationel og partisk frygt.

      Og dit andet store spørgsmål, hvorfor skal systemd kontrollere så mange ting? Simpelt svar: fordi med sysvinit og alle de andre init-fordele, der for nylig blev introduceret i Linux-kernen, spildes, så længe ingen bruger dem til at bruge i brugerrummet, bliver de "forbanna" (som vi siger på Cuba ... ja, spilder) uden nogen Jeg bruger dem, og de giver meget gode fordele ved effektiv brug af hardwarressourcer (CPU, RAM, I / O osv.) Inklusive cgroups. Hvad systemd gør er netop at sætte disse gode funktioner Linux-kernen til brugerens tjeneste, men til det skal han være den, der starter disse dæmoner.

      1.    Yukiteru sagde han

        Jeg tror, ​​du har læst og analyseret forkert (analysering er vigtig), eller du har bare ikke engang givet dig selv en chance for at gøre det. At to processer videregiver information er ikke en grund til, at et system går i stykker, men når du har binære filer med dynamisk handling som netværkskontrol, logfiler eller coredump, videregiver information direkte til init, kan ting gå galt, og de vil gå galt, hvis nogle af binærfilerne går i stykker, er chancerne for at bryde resten meget højere, og det er ret realistisk, og det er sket, kernel cmdline styrtede for nylig, de acpi-problemer, som Nvidia devs havde, takket være systemd-212, alt det der er en prøve af hvad jeg siger.

      2.    anonym sagde han

        @Dariem
        Hvis du ikke kan kompilere hver af disse binære filer i individuelle pakker, tvinger du det, fordi du vil have en installeret, skal du installere dem alle, når du installerer dem alle, viser det sig, at du træder på andre pakker, der ikke kan installeres, fordi de dele af systemd optager Disse steder.
        Hvilken mening giver det at opdele en stor eksekverbar i flere mindre eksekverbare filer, hvis du i sidste ende ikke har en pakke til hver enkelt, der giver dig mulighed for at installere dem individuelt.
        Jeg vender tilbage for at stille den generelle anmodning til alle avancerede systemd-brugere for at fortælle mig, hvordan jeg kompilerer de 90 moduler og opretter 90 pakker, som hvis jeg har lyst til at installere dem, og ellers bruger jeg de programmer, jeg har brugt.
        Meget dårlig mælk alt dette .... det ser ud til, at folk i systemd tror, ​​at alle GNU / Linux-brugere er tåber.
        For ordens skyld bruger jeg gentoo-test, og for et par måneder siden var jeg skiftet til systemd, og jeg kunne ikke med journald, der fik mig til at vende tilbage til openrc hurtigere end det tog at skifte til systemd.
        For at fortsætte med at se, hvordan det går med systemd, har jeg archlinux på en notesbog, der snart frigives til gentoo ... Sikkert stabil.

      3.    Yukiteru sagde han

        @ anonym, jeg vil bare se, hvordan TTY-problemet vil udvikle sig i Linux. Når CONFIG_VT-koden kommer ud, til fordel for at opdele VT i to godt differentierede dele (kernelspace og userpace), har vi brug for noget værktøj til at kontrollere VT'erne fra userpace, og der kan systemd-trøstes spille i at være en stærk afhængighed, der trækker resten af distroerne til nødvendigheden af ​​at skulle installere systemd-komponenterne bare for at gøre det muligt for systemet at arbejde. Det, jeg siger, er ikke en overdrivelse, det er en meget, meget stor mulighed og virkelig bekymrende. Der er andre projekter, som KMSCon, men hvis de fleste desktops og distroer går til fordel for systemd, kan ting som KMSCon dø hurtigere end mange tror.

      4.    anonym sagde han

        @Yukiteru 3. december 2014 8
        Jeg er ikke bange for det, Mr. Linus vil ikke fjerne standardindstillingerne fra en version til en anden, han vil sætte det nye system som NYT og give dig mulighed for at vælge mellem det gamle og det nye.
        Med hensyn til userpace-delen kan du lave en pakke, der gør det uafhængigt, hvis systemd gør det, hvorfor kunne ikke yderligere 50 mere? Hvad mere er, de forskellige måder at gøre det på, får de forskellige terminaler til at vedtage forskellige måder alle med USEs til at aktivere og deaktivere, som vi er vant til.
        Det samme gælder for kdbus, at Linus indrømmer det i 3.19 som han siger, det betyder ikke, at man bliver nødt til at have det aktivt ja eller ja.
        Jeg er meget tilfreds med openbox + compton, desktops for mig kan forsvinde, fordi de ikke vil påvirke mig i det mindste.

      5.    Yukiteru sagde han

        @ anonymt er spørgsmålet, at fjernelse af CONFIG_VT er noget, der i sidste ende vil være totalt (fra det, jeg har læst), det vil sige, at i kernen forbliver kun primitiverne, mens resten af ​​værktøjerne vil være i brugerområdet, dette er ikke dårligt, tværtimod fjerner det en masse gammel kode fra kernen, gør det lettere at vedligeholde og meget mere konfigurerbar (fuld KMS / DRM-understøttelse til konsol). Bestemt i starten vil der være begge systemer, men på lang sigt (15-20 udgivelser) kan det muligvis forlade kernen, eller endnu hurtigere, mange værktøjer understøtter ikke længere en sådan kode til fordel for nyere og bedre understøttet kode.

        Nu siger du, at hvis systemd gør det, fordi 50 flere ikke kan gøre det (jeg forestiller mig 50 flere applikationer). Nå, hvis vi ser de stærke afhængigheder af KMSCon (det ældste projekt i denne forstand) er de libudev (kode, der snart bliver knyttet til systemd, det understøttes ikke og vil være i konflikt med systemd, hvis det fungerer alene), libdrm , libxkbcommon, libtsm og systemd selv til at håndtere multisæde, så når du ser dette, indser du, hvordan tingene tager form ved at tage for sig selv mange værktøjer, der er nødvendige for, at et GNU / Linux OS fungerer uden problemer.

      6.    anonym sagde han

        @Yukiteru 3. december 2014 9
        Her i gentoo er libudev virtuelt, der peger på sys-fs / eudev, så gentoo-folkene sørger for at ændre eudev for at overholde den API, der er dikteret af det nye kernesystem.
        Så jeg tror, ​​at andre distroser end systemd (hej devuan) vil bruge, hvis eller hvis eudev.
        Hvad der skete med den oprindelige udev vil ske, systemd slugte det op, men her er kernen den, der er dikteret af API'en til interface til konsollerne ved hjælp af DRM / KMS .... Jeg ville allerede se en urxvt ved hjælp af dette ... hehe
        Det jeg accepterer er, at den, der bruger systemd, ikke har mulighed for at ændre noget ... fuld og hård indførelse og som jeg sagde før ... at græde til kirkegården.

      7.    Yukiteru sagde han

        @ anonym helt sikkert hvad du siger er den anden mulighed, eudev vil tage større styrke i denne henseende og vil holde mulighederne åbne for at vælge forskellige værktøjer.

        PS: Som du siger, ville det være interessant at se, hvordan VT'er tager fordelene ved KMS / DRM sammen med fbdev 😀

      8.    Dariem sagde han

        Du har nøjagtigt gentaget konceptet, som jeg kritiserede dig, for på intet tidspunkt talte jeg om systemet, jeg talte om kommunikation mellem processer, og jeg gentager igen, hvor får du det, fordi to processer kommunikerer, døden af ​​den ene indebærer, at den anden har rigelige muligheder for At dø? Forklar mig, hvordan to processer, der ligger i separate hukommelsesrum, gensidigt kan påvirke hinandens interne adfærd. Lad os se, hvis jeg forklarer mig selv, set fra en af ​​disse processers synspunkt, har han kun adgang til en IPC-mekanisme (uanset hvad det er, der blev defineret til at kommunikere til systemd-processerne). Hvis programmøren var så dårlig til ikke at inkludere kode, der kan håndtere uventet input og output, er det noget andet, men det har intet at gøre med en proces, der påvirker internt i en anden. Hvis systemd-networkd går ned, behøver det ikke dræbe journald eller systemd, som med den gamle sysvinit, det faktum, at inetd crash ikke bør påvirke det, de er separate processer.

      9.    Yukiteru sagde han

        @dariem forklarede på en enkel måde for at se, om du får ideen:

        Hvad du siger er bestemt den adfærd, der altid forventes af modulære programmer og processer. Modularitet blev implementeret til dette formål, nemlig at adskille to processer, og at de optager deres egne hukommelsesrum, og at de kommunikerer på en eller anden måde (IPC osv.), Så i tilfælde af at noget går galt, så sker der ikke noget dårligt. Og systemet kan fortsætte med at fungere uden afbrydelse. En teori, der helt sikkert har haft stor opbakning på grund af dens potentiale og den enorme margin til pålidelighed, som den har givet til nuværende databehandling. Dette er ikke altid sandt (livet er ikke altid smukt), og jeg tror, ​​du har helt sikkert været offer for disse begivenheder ved en eller anden lejlighed (dette gælder helt sikkert for alle uanset hvilket operativsystem du bruger), og jeg vil give et par eksempler.

        Den første går med Xorg (som er en modulær proces ligesom systemd), som nogle gange bliver skør med en driver og bare går ned og efterlader dig uden grafik, mens resten af ​​systemet fortsætter med at arbejde som forventet (Salig modularitet 😀). Indtil videre er vores teori om, at modulære processer ikke behøver at bryde systemet, fint. Men (der er altid nogle, men) Xorg giver undertiden noget mere end galskab og af en eller anden mærkelig grund (som kan variere fra musekontrol til grafikdriver), kolliderer ikke kun Xorg, men det giver dig også det smukkeste af kernepanikken (og en graffiti på skærmen som Picasso), som du kan forestille dig, og så indser du, at uanset hvor modulær det er, hvis en proces kommunikerer og udveksler information / data med en anden, og noget går galt i en af ​​dem, og af en eller anden grund, kan fejlen ikke håndteres korrekt, chancerne for, at de pågældende processer påvirkes, øges, for det enkle faktum, at dataene er forkerte eller simpelthen korrupte, og så kommer de katastrofen.

        Hvis du tror, ​​at dette ikke kan ske, efterlader jeg dig nogle fejlrapporter (en er min i Debian og har et par fotografier) ​​af en gammel fejl, der er i Xorg, mesa, nouveau og kernens drm / kms-driver, behandler det på trods af løber ** separat og er modulær **, sammen kommer de ikke godt sammen, i det mindste ikke under disse omstændigheder.

        https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742930
        https://bugzilla.redhat.com/show_bug.cgi?id=901816
        https://bugzilla.redhat.com/show_bug.cgi?id=679619

        Nu det andet eksempel, jeg vil give dig med systemd. Vores gamle Sysvinit havde en ejendommelighed, at selvom den var gammel, var den meget pålidelig, til det punkt, at hvis din / etc / fstab havde en partitionsindgang (ikke vigtig for systemet, skal du forstå a / mnt / Disk160GB), og det er det kunne ikke monteres af en eller anden grund, monteringen blev simpelthen sprunget over, gav dig en advarselsmeddelelse og fortsatte med opstartsprocessen. Nu er systemd en anden historie, på trods af sin modularitet. Hvis du har en post i / etc / fstab og systemd af en eller anden grund ser, at det er umuligt at montere det, venter det ikke kun på, at partitionen er tilgængelig (den normale programmerede adfærd) til sin samling, men hvis tiden slutter, stoppes dit system, og du kan ikke gøre mere end at gå ind i gendannelsestilstand og fjerne den linje fra / etc / fstab, noget der faktisk fejler. Den lille detalje ikke mere under automount i opstarten, og hele processen stopper, først (systemd-) var den lille detalje grimere, fordi dumpen netop dukkede op, og du var nødt til at genstarte. En person, der gennemgik detaljerne, fortæller dig.

        Et andet eksempel, jeg kan give, er coredumpd i systemd. coredumpd sender som standard al sin information til journald for at sidstnævnte kan skrive den fangede information til disken, indtil videre så god, vi bruger systemd's modularitet til vores fordel. Men det sker nogle gange, når coredumps er meget store, bare så store, at de kan tage flere GB, og i færd med at videregive oplysninger fra coredump til journald og derefter til disk, sker der mærkelige ting som Xorg holder op med at arbejde og selv kernepanikker. Det sker ikke kun med systemd selvfølgelig, men den måde, det er designet på, øger fejlfaktoren og skaber andre ubehagelige detaljer (blandt dem øget hukommelsesforbrug, logkorruption, ufuldstændige dumps), der har været nødt til at arbejde Med en KDE coredump har du helt sikkert været igennem flere episoder som disse, og du vil have forstået vigtigheden af ​​at have synkroniseringsmuligheden i / etc / fstab til din dump-partition, og du vil helt sikkert hader det faktum, at du ikke kan bruge en anden mulighed til at håndtere lossepladserne, hvis du har systemd installeret. Et eksempel på hvad der kan ske med systemd-coredumpd.

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

        Nu for at afslutte:

        Skal de ikke være modulære programmer og processer? Ja, de er modulære. Kernen er den eneste monolitiske ting, jeg har talt om her, men den accepterer også moduler (LKM), så det ville være en slags hybridkerne, selvom dens basisdesignform ikke er designet i den type struktur, og det gør det lidt ustabilt under visse omstændigheder.

        Denne modularitet burde ikke tillade mig at forhindre mine processer og system i at gå ned, hvis noget går galt? Det er sandt, modularitet er et mål designet til at opnå en høj grad af stabilitet og pålidelighed, men det er ikke en 100% ufejlbarlig foranstaltning, for hvis noget kan gå galt, vil det simpelthen gå galt, uanset hvor modulært, det er en virkelighed.

        Hvilket systemd skal have kontrol over alt for at muliggøre brugen af ​​cgroups og andre muligheder tilføjet til kernen? Helt falsk. Det er slet ikke nødvendigt, systemd kunne have været tilbage med en grænseflade til at styre opstart og tildeling af cgroups til de processer og dæmoner, der vil være i systemet uden at skulle overtage antallet af tjenester, det nu har, og bedste eksempel på det er; at OpenRC også er i stand til at bruge cgroups, og det er ikke af den grund så invasivt at udføre denne opgave.

        Hvad er jeg partisk og bange når jeg taler om systemd? Jeg har ingen idé om, hvor han får det fra, for som du ser mit svar, er jeg ikke bange for det, jeg taler kun om aspekter, som jeg ikke kan lide ved systemd og allerede uden at stole på udtalelser fra tredjeparter.

        Endelig siger du, at: "Hvis programmøren var så dårlig til ikke at inkludere kode, der kan håndtere uventet input og output, er det noget andet ..."

        Bestemt at sige, at programmøren for ikke at medtage en kode, der håndterer ALLE de mulige måder, hvorpå hans program kan brydes af en eller anden fejlagtig dataindtastning, er DÅRLIG, det forekommer mig en skandale. Ligegyldigt hvor god en programmør han er, en person er ude af stand til at designe et ufejlbarligt og fejlsikkert program, vil der ALTID være en fiasko, hvilken eller anden måde der kommer til at lyse, og når det gør det, vil det være takket være en tilfældig fejl under brug af en hacker eller krakker, der udnytter en sårbarhed, ved en kodevurdering og revision eller på andre måder, som programmøren kan stole på. Bedre at måle ordene, før du siger noget lignende.

        Greetings.

      10.    Dariem sagde han

        Det eksempel, du giver om Xorg, er det mindst passende, fordi alle, der har gennemgået overgangen til KMS / DRM, ved, at problemet skyldes fejl i kernemodulerne til at kontrollere KMS, der leveres af udviklerne af Xorg-driverne. En fejl i et KMS-modul er det samme som en kernepanik, det har intet at gøre med kommunikation mellem processer, for i så fald er det Xorg, der foretager et systemopkald (syscall), så kernen ændrer skærmtilstand, dvs. der er kun en proces involveret (Xorg), der kalder kernen, intet at gøre med det, vi har at gøre med her.

        Den nuværende opførsel af systemd, når man ikke finder monteringspunktet, er irrelevant uanset det faktum, at det er en funktionalitet, som nogen måske ikke kan lide, der løses ved at bede om, at de støtter den anden adfærd, nemlig at ignorere den mislykkede montering. Den coredump, der opstod før, kunne skyldes forskellige årsager, som man kun kunne spekulere i, men det faktum, at udførelsen ikke fortsatte, kan skyldes en ønsket adfærd, da du siger, at den skulle genstartes, ikke at der var en kernepanik eller en automatisk genstart. Da jeg ikke har været igennem det, kan jeg ikke afgive en udtalelse.

        Med hensyn til det problem, du har sat med systemd-coredumpd og linket til fejlrapporten, indikerer alt, at dette problem i Arch Linux skyldtes den komprimering, de aktiverede systemd, da de kompilerede det til den distribution. Det ligner mere et problem med komprimeringsalgoritmen end med selve systemd. Operativsystemet går ikke ned, snarere synes kompressionsalgoritmen, der bruges til at gemme coredumps, at dræne systemet, og det er fejlen fra Arch Linux-udviklerne, der kompilerede systemd. Systemd har dog indstillinger for at begrænse ressourceforbrug og aktivere / deaktivere indfangning af alle coredumps rapporteret af kernen. Måske skal Arch-vedligeholdere af systemd og dem, der bruger KDE, se på dem.

        Du siger, at OpenRC også bruger cgroups uden at være invasiv. Problemet er dette: hvordan genkender OpenRC navnet på daemon-eksekverbare filer for at vide nøjagtigt, hvilken ressourcetildeling der er bedst? Jeg er faktisk ikke sikker på, om dette er en af ​​grundene til, at systemd tager sig af så mange ting og giver eksekverbare et velkendt navn, men jeg formoder, at tingene går sådan. Derudover eliminerer det byrden ved at have bindestreg i midten for at køre hver af disse tjenester ved direkte at påberåbe eksekverbare filer.

        Jeg vil ikke benægte, at systemd kan have mange bugs, men derfra til at tilskrive dem alle til den måde, det er opfattet på, tror jeg ikke det. I tilfælde af sysvinit var det superstabilt, et modent stykke software, systemd er lige ved at komme i gang.

  12.   Rafael Mardojai sagde han

    Hvordan de sprænger bolde med systemD, xD Hvis du hader det så meget, skal du oprette din egen distro, hvilket er hvad Free software er til é_é

    1.    Alexander den Store sagde han

      Det handler ikke om had, det handler om at forsvare dit samfund.
      Forresten, hvis der er distributioner Uafhængig "undergrund":
      http://gutl.jovenclub.cu/neonatox-un-linux-iconoclasta
      Respekter

  13.   wacos sagde han

    fordi sammenlign alt med microsoft, at det opfører sig som windows .. hvis ting fungerer godt, og det er til udvikling og udvikling af linux, hvad er problemet ... hvert projekt i starten kan muligvis have ændringer, hvis softwareprogrammerne osv. var perfekte, Vi er mennesker, men det er derfor, vi har fejl.

    at hvis systemd mislykkes, vil systemet gå ned ... og hvis kernen, xorg, grub mislykkes ... er der folk, der opdaterer kernen på deres pc eller laptop, mister systemet ... så fordi insisteringen på perfektion af noget ...

    som om ethvert system, der er kommet ud, ikke havde haft fejl bugs eller noget i begyndelsen eller endda i dets modenhed har fejl

  14.   lf sagde han

    Systemd blev pålagt som en standard med snavset spil, det er en obligatorisk afhængighed for mange pakker, fordi mange programmer blev absorberet af systemd, enten fordi de vedligeholdt dem, eller fordi de langsomt fjernede dem, da de ikke længere var relevante, fordi systemd allerede leverede noget lignende.
    Dette begrænser valgfriheden, dvs. distroer kan ikke vælge IKKE at bruge systemd, de kan forsøge at modstå som gentoo, men det er mere en midlertidig løsning på systemd, openrc er bare en sysv-understøttet servicemanager til init og i dist initscripts , systemd giver mere funktionalitet end openrc og har ny funktionalitet hver dag. Den nye software understøtter systemd og kræver implementering af noget lignende, som ender med at gøre de andre inits mere komplekse og mere ligesom systemd, hvilket er det, du ikke vil have.
    Systemd gør mange ting i forhold til den gamle init, der simpelthen læser et par linjer fra / etc / inittab og derefter indlæser hver af inskripterne og deres indstillinger i henhold til runlevel. Den gamle tilgang var meget enklere og mere uafhængig. Vi er i en overgangsfase mod en ny æra af homogenitet, der er ingen løsning, den måde, den hersker på, er ustoppelig.
    Om et par år vil der praktisk talt ikke være nogen forskel mellem at bruge debian, bruge arch eller fedora, identiteten på hver distro vil gå tabt, hvis vi fortsætter sådan og systemd bliver mere påtrængende hver dag, at det endda bliver en del af systemnavnet (systemd / gnu / linux)

    1.    MSX sagde han

      LOL

      At græde til kirken>: D

  15.   MSX sagde han
    1.    lf sagde han

      Problemet er, at du er argentinsk (det er jeg også), men måden at udtrykke sig på, at de fleste af de argentinske Linux-brugere, jeg læser, er virkelig bekymrende, selvom det også siges, at verden af ​​gratis software tiltrækker visse mennesker. Det jeg redder er, at du ikke formoder dig at være argentinsk, men det viser desværre ligaer.

    2.    x11tete11x sagde han

      uyyuyy .. den dreng faldt med tungt artilleri ..

    3.    WACOS sagde han

      stærk kommentar !!

    4.    rawBasic sagde han

      Juju .. ..pochoclos .. xD

  16.   Tito sagde han

    Det følger af denne artikel, at alt hvad de gør er at "påtvinge" et system. Jeg går ikke ind for at vurdere, om det er bedre (hvilket det ikke er) eller værre. Hvad jeg siger, gentager jeg, understreger og understreger, er at jeg ikke rigtig vil have noget pålagt mig.
    Sætninger som: "Vi bruger dem bare ikke til opstartsprocessen, fordi vi mener, at de ikke er det bedste værktøj til det specifikke formål."
    Og hvem skal du fortælle mig, hvis jeg vil bruge dette eller det andet værktøj?
    Der hver. Jeg bruger det bare ikke, punktum, og selvom jeg måske ikke gør det, vil jeg ikke.
    Underskrevet. En Taliban.
    (Det er, at jeg morer mig med klovnene)

  17.   kuktos sagde han

    ofte en hovedpine med det emne !!!! X_X

  18.   Tabris sagde han

    Jeg administrerede servere med Centos 6, og at gå til 7 med systemd kostede mig ikke noget, græd ikke, livet fortsætter.

  19.   Jok sagde han

    Undskyld mig, men jeg læser en masse ting, der minder mig om den klassiske "windows server - Certified Man VS linux server - OpenSource Man" diskurs.

    Første - Du vil se, hvis du tvinger en fejl, er det normalt, at det fejler. Hver eneste af de videoer, jeg har set, er tvangsfejl. Det er som om jeg laver et program, der føder nøgleord til syslog-loggen, og samtidig prøver jeg at udføre et grep-baseret script for at udtrække information fra loggen ... selvfølgelig vil det mislykkes, jeg har forårsaget det.

    Det er som at hælde sukker i en dieselmotor og sige "Se ... benzin er bedre !!!" eller som Windows gør, skriv en konfigurationsfil forkert og klag over, at dæmonen ikke begynder at sige "med windows sker dette ikke".

    2. - Det systemd indeholder mange ting, som du måske ikke bruger? Nå, hvad er problemet? Det er, at det er det samme tomme argument, som Windows bruger mod Linux-dem ... "Hvorfor vil jeg have en almindelig tekst til at sætte tusind og en indstilling, når du ikke skal bruge dem?"

    Jeg hører stadig IBM-fyrene med deres monilithiske programmer gøen om mysql for mange år siden, da jeg læste nogle ting. Jeg takker og bifalder mangfoldigheden af ​​GNU / Linux og dets samfund. Hvis du giver mig 50 måder at gøre noget på, vælger jeg hvert øjeblik den, der fungerer bedst for mig eller passer til det, jeg har brug for. Ser du virkelig et problem i dette?

    3. - På niveau med samtalerne udleder jeg, at du har et tilstrækkeligt niveau til at arbejde med enhver distribution eller oprette din egen og vedligeholde det selv. Hvorfor vil du sætte systemd og fjerne ting fra det? Er det ikke lettere at fortsætte med din init eller openRC?

    Til de mennesker, der har bedt mig om at lære dem det grundlæggende i Linux, siger jeg altid det samme ... GNU / LINUX er ikke WINDOWS, prøv ikke at gøre de samme ting eller tænk som om det var. Hvorfor assimilerer du, at sistemd er det samme som initd, eller at det fungerer det samme? Er det ikke lettere at assimilere driften af ​​systemd og bruge dens potentiale end at forsøge at lave funktioner som init eller OpenRC? Det er normalt, at du ikke kan lide det.

    4. - Hvad er der galt med kompleksitet? Du kan helt sikkert stadig huske, da du gav lineær programmering, og at du helt sikkert på et tidspunkt sagde ... «Og hvorfor vil jeg lære at arbejde på objekter, hvis jeg nu kan gøre alt, og ellers lader de mig bruge til?» ... (Facepalm et par måneder senere er fantastisk, hvis xD)

    Lad os være klare. Den aktuelle init (og jeg inkluderer systemd) har mange mangler, der kun kan udfyldes ved at tilføje kompleksitet. Der er ingen anden, for for at et sammenkoblet system skal vokse, skal det vokse i kompleksitet med risiko for at have en svag del, men det er bedre end at forblive stillestående.

    Det tager lang vej at gå, og hvis ... sistemd ikke er løsningen på alt. Men ingen af ​​dem opholder sig hos SysVinit.

    1.    jok sagde han

      PS: Læg mærke til ironien om, at jeg har brugt min kollegas pc "Jeg klamrer mig til windows-server defender", så han kan læse den forresten. xD

      Bare én ting, til forsvarerne af andre INIT'er, der giver tekniske data og links ... CHAPO !!! Jeg elsker at se argumenter og data som denne. Bare en note, dataene før oktober 2014 er kun historiske.

      Mange ting, der diskuteres, er allerede rettet, og mange testbeds, der blev offentliggjort i 2013, er allerede blevet gennemgået.

  20.   SynFlag sagde han

    @rolo

    Hvis det er sandt, hvis du så videoen, som du IKKE gjorde, kan du se, at loggen er 8 MB, intet mere og så videre, og alt bliver ødelagt, forresten, kan du sende output fra journald til syslog i simpel tekst? Ja, men alligevel, hvis du rører ved de logfiler, der er oprettet af journald, sker det, systemet hænger, og det er forståeligt, lad os se, journal hænger på PID1 sammen med ting så komplekse som systemd, det mislykkes, du ser, at det ikke har en del af koden, der ikke tillader redigering af andet end den samme PID af journald, såvel som den ikke har evnen til at fortsætte med at skrive ud over loggen er beskadiget, hvilket viser, at ud over at tænke i Windows-tilstand, er LP en dårlig programmør.

    Fortæl mig ikke, at det kun vil være i centos, den mest stabile version af distroen, der bruger systemd, klon af RHEL7, og jeg rapporterer ikke eller planlægger at rapportere fejlen.

    Sandheden er, at jo mere jeg læser de pro systemd-kommentarer, er jeg klar over, at de virkelig er som en religion, eller at du er for, eller at du er fjenden, men af ​​disse ISIL-religioner, dem fra den islamiske stat, helt ekstremistisk, faktisk ved jeg det erfaringsmæssigt, systemd elskere, de tror det, eller du er med dem, eller du er fjenden. Det er, hvad Lennart fremmer med sin arrogance, og vær så snill at ikke kneppe mig med Linus, der støtter ham, systemd var ikke dette, DET VAR IKKE, jeg brugte systemd, så snart det kom ud i Fedora 15, og det var bare en hurtigere init, det erstattede ikke GNU / Linux-modulariteten.

    Hvis jeg dræber rsyslog, ødelægger dens logfiler eller erstatter den med en tegning, intet andet, kun at jeg løber tør for log, intet hænger, systemet påvirkes ikke.

    @Rafael Mardojai

    Det er hvad Devuan gør, det er hvad Void Linux gjorde og andre der holder sig væk fra systemd.

    @Yukiteru

    Sikkert ingen læser dig, som de fortæller mig Taliban, de læser dig ikke, fordi du bruger windows, eller du kommenterede fra det, og fordi jeg tror, ​​at få af systemd elskere forstår den tekniske del af det, du siger, og deri ligger problemet.

    ======

    Sandheden er, jeg tror stadig, at en person, der var kendt tilbage i 2006, havde ret i noget:

    "Jeg vil ikke have folk til at bruge Linux eller at vide det, disse Ubuntu-fyre har mine bolde fulde"

    Jeg- "Hvorfor?"

    "Når noget bliver kendt og for masserne, skider det, det knepper op, og der er masser af prøver af det"

    Jeg- "som hvilke?"

    "Se hvad der skete med Debian, nu har han en fjollet søn ved navn Ubuntu og husk om et par år vil vi have" hackere "og" nørder ", der sugede Ubuntu, og de ved ikke, hvordan man skelner Ext3 fra NTFS"

    Noget var i orden .... systemd triumferer blandt dem, der ved, som Allan McRae siger, fordi han er ligeglad med, hvordan hans maskine starter, for ham er det, knap, magi, og jeg har en prompt. Blandt dem, der kun er interesseret i at "arbejde" med gode funktioner, i alt, til server, bruger LFS eller Gentoo eller BSD virkelig og derefter dem, der elsker det, fordi det tænder deres pc hurtigere med farvede lys, smukke lyde og hasardspil, men de ved ikke, hvad et syscall er.

    1.    Yukiteru sagde han

      @SynFlag, hvis de ikke læser det, er det ved deres egen beslutning, som for det operativsystem, jeg bruger, hvis jeg er på mit arbejde og kommenterer fra en Windows-pc, er det fordi det er det eneste, jeg har ved hånden, undtagen serveren det er i Debian Wheezy og åbenbart fra serveren kan jeg ikke kommentere her.

      Selv hjemme er jeg blevet tvunget til at bruge min søsters pc, fordi min pc er død (MB og strømkilden sammensværgede mod mig), og alligevel når jeg har tid, monterer jeg en LiveCD og bruger Sabayon (med OpenRC ) at kommentere her, som jeg gør lige som jeg skriver disse ord.

      Hvis de fortæller mig eller tror, ​​at jeg er et anti-system Taliban, betyder det ikke noget for mig. Som jeg sagde, har jeg brugt systemd, og jeg ved, at benet halter, ikke kun det, jeg læser normalt systemd-listen meget for at finde ud af ting, der kommer i nye versioner, og også for at være opmærksom på de ændringer, der foretages og af de diskussioner, der finder sted der. Hvis nogen systemd-elsker nu forstår det tekniske aspekt af det, jeg taler om, og jeg lægger i mine links (linkene til systemd git repo for det meste), og selv da ikke er i stand til at se virkeligheden, giver det mig kun mulighed for at tænke, at jeg sælger det i deres øjne og ekstremisme i deres måde at se / tænke / føle / elske / glorificere / rose / tilbede systemd er så stor, at det ikke betyder noget, om selv Linus selv sparker **** ud af systemd, de vil forblive forankret i deres ideer om, at de er korrekte.

  21.   Ezequiel sagde han

    Hej! Jeg er ikke særlig ekspert, og jeg vil gerne vide, hvad denne "systemd" er til, og hvorfor tales der så meget om, hvad er problemet, og hvilket alternativ er der? tak

  22.   Tito sagde han

    SynFlag-kommentaren! Jeg er fra "nørder", "nørder" og "pro linuxeros" til det samme.
    Og det er fremtiden, der venter os; Ubuntu selv i suppen; Linux-laptops til bare at få adgang til Steam og spille det nyeste hot-spil. Og legioner af små nørder, der ikke ved, hvad bælgen handler om.
    Efterskrift: systemds baggrundskoncept stinker.

  23.   Hannibal Smith sagde han

    adk og forum knapperne er ikke synlige på hovedsiden

  24.   Dariem sagde han

    Så ifølge @SynFlag er alle, der ikke er anti-systemd, en n00b, ekstremistisk religiøs fanatiker og pesten, der ødelægger GNU / Linux. Med en så snæver mening som denne ved jeg ikke, om dette emne er værd at diskutere. Bedre at lade vandet løbe, og i det lange løb skal der ske, hvad der skal ske.

    1.    Rolo sagde han

      Det er sandt, der kommer et punkt, der ikke kan diskuteres mere. kun tiden vil fortælle os, om sytemd vil være noget positivt for verdenen af ​​gratis software eller ej.

      Det giver mig også ideen om, at hvis denne debianbaserede distribution, der ikke kommer til at bruge systemd, opnås, vil det hjælpe med at berolige ånden hos dem, der ikke vil vide noget om systemd.

      som da gnome 3 dukkede op og der blev bygget en enorm modstand, indtil "gaffel" kanel og enhed dukkede op, hvilket gjorde det muligt at fortsætte med at bruge gnome-applikationer på et skrivebord med flere konfigurationer og et design mere tænkt til pc'en og ikke så meget til berøring

      1.    Xiep sagde han

        Måske kan det, Rolo (udseendet af Devuan), være et konsensuspunkt. Jeg tror, ​​at vi alle har brug for det for at indeholde en polariseret og bellicose atmosfære af diskussion. Devuan vil være et rum til skabelse og kontinuitet af en måde at gøre på, og som vil hjælpe med at berolige åndene. Processen, som vi har boet i Debian, har været smertefuld, men vi må stå over for situationen, der er intet andet valg end at acceptere adskillelsen. Dette ender med at blive lidt som skilsmisser. Denne gaffel kan være en udskrift af en fredsaftale og en del af den. Der var selvfølgelig alternativer, Slackware, Gentoo, Funtoo, Crux, PCLinux OS, nu Manjaro (for at nævne nogle få) ... men "deb" -scenen krævede et alternativ uden systemd. Det ser ud til, at ingen vil overbevise nogen, argumenterne ligger på bordet, og der er ingen konsensus (på trods af at systemd har gode ideer og de farer, som denne software medfører, er indlysende). Det er tid for gafler og for frihed, der opnås for brugeren (fordi det handler om fri software, ikke?).

        En faktor, der har påvirket processen, har været følelsen af ​​"skuffelse" fra nogle af os, der sætter vores tillid til Debian. Derfor præsenteres Devuan som en gaffel og ikke som et derivat. Der er spænding, fordi ingen kan lide det, der skete; hverken pro-systemd (dermed visse rasende angreb, der forsøger at ærekrænke) eller anti-systemd (der har satse på gaffelen). I miljøet er det «hvor meget talent kan vi miste?», Både på den ene side og på den anden.

        Alle Debian-brugere ser på distro på en "bestemt" måde (dette kan også anvendes til andre distributioner). Der er dem, der beundrer dets tekniske kvalitet, andre dets sociale kontrakt, dens indflydelse i Linux-verdenen, den respekt, den har opnået gennem årene, dens stabilitet i kritiske produktionsmiljøer ... I nogle brugere har denne opfattelse ændret sig, med skuffelse. Skuffelse, ubehag, kalde det, hvad du vil. Derfra til adskillelsen er der kun et lille skridt.

        Debians skilsmisse ligner det, der skete med NetBSD og OpenBSD. Selvom tiden vil vise det. Jeg ser mange forventninger i gaflen, og det får mig til at tænke, at det ikke vil være en flygtig og steril distribution. Lige i dag var der et medlem af gnome-teamet, der kommenterede Devuans mailingliste (selvom han har gjort det akavet), dette efter min mening antyder, at Devuan skaber interesse og på en eller anden måde ønsker dialog.

        Alligevel god weekend.

      2.    SynFlag sagde han

        @rolo

        At sige, at videoen kan blive narret, eller softwaren er en total fejlslutning og fornærmelse, i mit PU ** liv narrede jeg noget til at skabe en myte, aldrig, jeg kan prale af at have set den fiasko ved mine midler, ikke ved mine tricks. De går alle til **** end *****, og jeg vil ikke lægge mere i diskussioner om systemd, fordi det er helt til fjenden, ingen vil forstå noget, og det er alt sammen et nedrykning, som , Jeg hader, fordi alt det er ved troens dogme. Vær tilfreds med systemd.

      3.    Rolo sagde han

        @SynFlag vold lyver

        Hvad denne video viser, er falskheden i påstanden om, at hvis et af systemd-modulerne er ødelagt, får det systemd til at gå ned, da det tydeligvis ud fra det, din video viser, ikke skete, xddddd og forresten journal kører som root, derfor, hvis en tredjepart kommer ind og ondsindet knepper journal log binær, ville jeg ikke bekymre mig om systemd, men snarere om sikkerheden på din computer. xdddddd. Endelig om emnet for videoen, repliker det, der vises redigering med nano filen /var/log/journal/24f02f5b2b16758b820ea6a751ed6efb/system.journal, og når du genstarter, finder du ud af, at der er et nyt system.journal og et system @@ 24f02f5b2b16758 @ @ 820f6f751bXNUMXbXNUMX. journal, som er den beskadigede binære.

        Det vil sige, journal indser, at filen er korrupt, så den ikke omdøber den og opretter en ny igen, jeg kan ikke se, hvad problemet er i det ?, Det samme som hvis filen system.journal er slettet, journal returnerer det for at oprette.

        Jeg spekulerer på, hvad der ville ske, hvis jeg ødelagde en almindelig tekstlogfil med en hexadecimal editor, helt sikkert indtil man indså, at filen var beskadiget, ville alle data blive ødelagt Oo

        Lad os tale lidt om journal, som er en af ​​de mest almindelige kritik af systemd.
        journal er en meget vigtig komponent i systemd, der fanger Syslog-meddelelser, kernelogmeddelelser, RAM og indledende opstartsmeddelelser samt meddelelser skrevet i STDOUT / TDERR og gør al denne information tilgængelig for brugeren.

        Men vigtigst af alt kan journal bruges parallelt eller som erstatning for en traditionel syslog-dæmon, såsom rsyslog eller syslog-ng, derfor kan en forsigtig sysadmin muligvis have rsyslog eller syslog-ng som et andet forespørgselsværktøj bortset fra at transformere journaloptegnelser i almindelig tekst, hvis binærfilm bliver ødelagt

        En anden vigtig kendsgerning ved journal er, at hvis mappen / var / log / journal ikke oprettes, gemmes information kun midlertidigt, som går tabt ved hver genstart.
        for eksempel, da jeg indtastede systemd i debian, var vedholdenheden af ​​loggen ikke aktiv, så jeg var nødt til manuelt at oprette journalmappen

        http://0pointer.net/blog/projects/journalctl.html

  25.   anonym sagde han

    De, der kender engelsk, kan ikke gå glip af de samtaler, der føres mellem devuan-udviklere, jaromil dimkr max2344 blandt andet på freenode IRC-kanalen #devuan.
    Meget sjovt at læse undersøgelserne af systemd-koden, da de har spildt den med vilje for at inficere (skabe unødvendige afhængigheder).

  26.   Sircacaroto sagde han

    Systemd generer mig ... lige forfra ... det er svært. Lille dokumentation eller den skide slanke kører kun KDM eller gdm, og i et let system vil jeg have slank lxdm understøtter ikke det eller kompilerer det ... .. Seriøst, at jeg selv før ... var tilfreds med, at de skulle. Sandheden er, at jeg begyndte at bruge openrc, som de siger i gentoo, og det hjalp…. Meget

  27.   synflag sagde han

    @rolo

    Du er en uforskammet og nyhedsfejl for at sige det. Det er den værste fornærmelse, at du fortæller mig, at jeg lyver eller forfalsker data, det væmmes mig virkelig, hvordan man for at forsvare noget, du angriber folk, der gør seriøs PoC som mig. Loggen er beskadiget, systemet går ned, genstart af tjenesten fungerer ikke, så der er intet andet valg end at genstarte maskinen, hvilket ikke er det bedste i en hacket server, du vil fortælle mig, at hvis sikkerheden blev kompromitteret, er det bedste at genstarte eller geninstallere og det er det eneste, jeg skal bekymre mig om, da systemet siger undskylde sig selv og ikke foretage en varm analyse af HVAD SKJEDDE? at komme til det punkt? Det er klart, at du er endnu et produkt af det nye sysadmin, hvis du kommer til det, der blev rejst ved hjælp af ubuntu og har sikkerheden for en DOS 5.0 på din pc, så hvad du siger, jeg tager det som hvem det kommer fra, det generer mig, at du også tvivler Den, der forfalsker, er dig, svarede du på det samme operativsystem med opdateringerne DENNE dag? Sikkert ikke, så prøv at lyve for en anden. Hvilken mangel på kapacitet du har, gå på arbejde som taxachauffør i mere end det, jeg tvivler på, at det vil give dig, stop med at spille med linux og bliv ved med at kigge pr0n

    1.    Rolo sagde han

      Lad os se due (synflag), far vil vise dig, hvordan du får journalen til at fortsætte med at arbejde, efter vores binære journallogfil er beskadiget af en eller anden grund uden at skulle genstarte computeren.

      I dette eksempel starter vi fra en basisinstallation af debian 8 jessie.

      systemd-journal.service leveres som standard med funktionen "storage = auto", så det er nødvendigt at oprette filen i / var / log / journal / tidligere for at have en vedvarende registrering af logfilerne.

      # mkdir -p / var / log / journal /

      For at journal kan begynde at skrive logfiler, behøver du IKKE genstarte computeren, bare gør:

      # systemctl genindlæs systemd-journal.service
      o
      # systemctl tvangsindlæs systemd-journal.service

      ### nu skal vi simulere, at tidsskriftets binære log er beskadiget ###

      # cd / var / log / journal
      # ls
      24f02f5b2b19808b820ea0a980ed6efb
      # cd 24f02f5b2b19808b820ea0a980ed6efb
      # nano system.journal
      ### nu ændrer vi en eller anden linje i filen for at simulere, at den er beskadiget
      # journalctl
      ### som forventet intet sker
      #### skal computeren genstartes for at journal kan oprette en ny binær? INGEN
      # systemctl tvangsindlæs systemd-journal.service
      # ls
      system@24f02f5b2b19808b820ea0a980ed6efb-0000000000000001-0005069a53abf581.journal
      system.journal
      # journalctl
      ### Som vi kan se, opretter journal en ny binær logfil, og vi kan nu få adgang til oplysningerne igen uden at skulle genstarte computeren på noget tidspunkt

      https://www.youtube.com/watch?v=hEagyMdkN4A&feature=youtu.be

      konklusion: synflag eller du er uvidende, eller du er en fabler
      lad det pynt dig endeligt

      1.    Rolo sagde han

        for skrivefejl og misbrug af kopi og indsæt skrev jeg systemd-journal.service, når tjenesten i virkeligheden kaldes systemd-journald.service

      2.    SynFlag sagde han

        Pichon?, ... hvor forkert er du mager, seriøst .. Jeg vidste det allerede, rapporter fejlen i rød hat for at se, hvad de sagde, jeg rammer svaret, se om du fanger:

        Hvis du fjerner outputfilen eller overskriver dele af filen, kan dæmonen ikke rigtig gøre noget ved det: hvis en hacker har tilladelse til at ændre outputfilen, har hun allerede vundet. Dæmonen kunne kontrollere nogle af disse ting, men det ville være ret ineffektivt og ikke rigtig nyttigt til noget. Hvis du vil, kan du oprette en periodisk kryptografisk signatur med 'journalctl – opsætningstaster'. Se journalctl mandesiden.

        Journalctl afhænger af rsyslog, det genstarter ikke sig selv i tilfælde af en fejl i loggen, hvilket rsyslog ikke har brug for, i alt, du skal bruge fordward til at sende rsyslog og på den måde skrives det på trods af alt, og journalloggen regenereres, det er en designfejl i journald. Hvis du ikke vil se det, så blæse mig.

      3.    anonym sagde han

        @rolo

        I videoen (jeg ved ikke, om du gjorde det) ser jeg, at i minut 2:11 bruges ls og ikke ls -l, hvilket gør det muligt at se den størrelse, som filen system.journal oprindeligt havde, så redigerer de den med nano og tilføj tomme linjer, genstart tjenesten manuelt og i minut 3:15 gør de ls igen og ikke ls -l, så i minut 3:20 ser de loggen med journalctl, dette viser den aktuelle log, som er fin.

        Nu kommer mine spørgsmål:
        1 - fordi ls bruges og ikke ls -l, for at kunne se den originale størrelse, som loggen havde før den blev redigeret
        2 - hvad skete der med den gamle log? hvor lagde systemd det i den korrupte binære log?
        3 - med hvilken systemd-kommando du kan reparere din korrupte binære log ... som du ikke skal slette

        hilsen

      4.    Rolo sagde han

        @anonym

        Nu kommer mine spørgsmål:
        1 - fordi ls bruges og ikke ls -l, for at kunne se den originale størrelse, som loggen havde før den blev redigeret
        2 - hvad skete der med den gamle log? hvor lagde systemd det i den korrupte binære log?
        3 - med hvilken systemd-kommando du kan reparere din korrupte binære log ... som du ikke skal slette

        1 sandheden er, at jeg ikke tænkte over det, bare brug ls til at se, hvilke filer der var i biblioteket, men hvis du er interesseret, kan du replikere det, proceduren er detaljeret, og jeg gør det i virtualbox (installation af en debian base er et stykke kage)
        2 forbliver den gamle log i samme mappe, bare at systemd omdøber den med en masse tal og bogstaver (vist i videoen)
        3 Under alle omstændigheder kan du prøve at bruge tredjepartsapplikationer (en hex-editor antager jeg), da hvis systemd kunne reparere den korrupte fil, ville den ikke omdøbe den eller oprette en ny. Under alle omstændigheder, og som jeg allerede har nævnt ved andre lejligheder i dette indlæg, kunne en forsigtig sysadmin bruge rsyslog eller syslog-ng som et andet forespørgselsværktøj bortset fra at omdanne journalposter til almindelig tekst, hvis binæren blev ødelagt.

        Jeg mener, det er ikke ideen at overbevise nogen om at bruge systemd (jeg vil endda elske at have muligheden for at vælge intet i Debian-installationsprogrammet). men jeg vil ikke forblive tavs, når jeg læser uvidende eller fabelagtig, som gentagne gange gentager løgne om systemd, som der findes en blog, når man ser, at disse ord ikke falder sammen med virkeligheden. og som Aristoteles sagde, den eneste sandhed er virkeligheden 😉

  28.   anonym sagde han

    @rolo

    Jeg har kigget på videoen igen og ja, den var opført der, kun det numeriske navn var så langt, at jeg så den, jeg troede, det var biblioteket .... Suverænt navn.
    Med hensyn til reparation af binær, ja, det er logisk, hvad du siger ... hvis jeg kunne reparere det, ville jeg ikke oprette en ny.
    Endelig er jeg tilbage med, at det ikke skal være en binær, så dette ikke sker, og at kunne se det uden specielle værktøjer med journalctl ... Jeg forstår stadig ikke, hvad der førte det til at bruge et binært format.

    Hilsner og tak for svaret

    1.    SynFlag sagde han

      Rolo, dedikér dig til noget andet:

      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393

      Jeg vidste uden at vide det…. Hvordan bemærker du forskellen mellem en, der prøver ting, og en anden, der kun laver fartvideoer

  29.   SynFlag sagde han

    Jeg kommer for at lukke ocote de Rolo, den fejl, der ses i min poC, blev rapporteret, så luk ocote-pichon:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393

  30.   Rolo sagde han

    Lad os se fantastiske:
    1 Du erklærede, at for at journal kunne løse problemet, var det nødvendigt at genstarte pc'en som i windows HELT FALSK
    Jeg viste dig, at det var en løgn, og i den video, du gjorde på intet tidspunkt, bruger du systemctl force-reload systemd-journald.service-kommandoen, for hvis du havde brugt det, ville dit argument gå ned (eller du kendte ikke kommandoen , som viser, at du er en uvidende, eller med vilje ikke brugte det, hvilket ville vise, at du er en historiefortæller)

    2 Du siger, at der er fejlrapporter, på den ene side er det fuldstændig irrelevant, da folk normalt rapporterer meget vrøvl som en fejl (så du forstår, at ikke alle fejlrapporter er en rigtig fejl), det giver mig endda ideen om, at du rapporterede det selv det samme. Og på den anden side har alle programmer bugs (hvor mange rapporterede bugs har sysvinit (et program, der er omkring 20 år gammelt)), og det gode ved rapporten er, at det hjælper udviklere med at finde og løse problemer (nogle hurtigere , andre langsommere)

    3 Du siger, at med den fejl, du genererer i journal, går det ned, når du genstarter systemd, da du i videoen kan se, at du er nødt til at genstarte virtualbox med kraft. HELT FALSK
    Sandheden er, at systemd ikke går ned, da systemet starter perfekt (hvis det ikke startede systemd, ville det give dig en kernepanik, og du bliver nødt til at gå ind i gendannelsestilstand)
    Hvad der sker med dig er, at systemet kontrolleres, når du prøver at redigere en binær med en teksteditor, og faktorerne kan være mange, såsom den tildelte hukommelse, operativsystemets tilstand (i videoen tager systemet lang tid at starte og slukke, hvad der antyder, at det ikke er en ren installation på 0 (som anbefales til denne type sager)) osv. Jeg kan kun fortælle dig, at den binære, som jeg redigerede ca. 10 eller 20 gange, og den aldrig blev kontrolleret. Dette viser også, at du enten er en uvidende eller en historiefortæller.

    4 Nu siger du, at journal afhænger af rsyslog HELT FALSK, faktum er, at alle kan kontrollere det ved at installere eller afinstallere rsyslog og se, at journal fungerer perfekt

    Jeg ville meget sætte pris på det, hvis du lader den usunde besættelse med mig, det er ikke min skyld, at du er uvidende eller fabelagtig

    Konklusion:
    Du ønsker ikke at bruge systemd, jeg synes det er fantastisk, nu har du ikke brug for at sprede terror med løgne for at få tilhængere af dit antisystemd korstog. Jeg boede og lod leve, at der er et sted for alle i verdenen af ​​fri software 😉

    1.    Rolo sagde han

      en afklaring på punkt 3, ville nogen fortælle mig, at da systemd er i pid1, ville et nedbrud indebære den systemd hjelm. To ting, først her, hvad der blev anført er, at systemd styrtede ned på grund af journalfejlen, men i virkeligheden er der en kontrol for at indtaste en binær (som bruges i realtid) med en teksteditor, jeg præciserer også, at i alle de test, jeg udførte, kontrollerede aldrig den virtuelle maskine. For det andet kan ingen med deres rette sind hævde, at linux ikke er mærket xddd,

    2.    SynFlag sagde han

      Fabelagtig?, Tynd, hold lidt tilbage, fabelagtig din gamle kvinde, der siger, at jeg smider gummiet, når jeg ikke rører ved det med en pind, jeg vender tilbage til respekt:

      1.- Du er nødt til at genstarte eller tvinge genstart af tjenesten, hvilket ikke er ideelt, og i CentOS 7, da jeg prøvede, genstartede tjenesten ikke noget, glem ikke at det er version 208 ikke den nye 217 eller 216 af Fedora.

      2.- Irrelevant og dem, der rapporterer om bugs? ... du er en idiot, jeg svarer dig ikke engang

      3.- UNHAPPY, den version, som jeg prøvede den dag af videoen, som du kan se, hele operativsystemet styrtede ned, hvorfor tror du, at den ortho ulykkelige løgn? Jeg er ikke en liggende abe, gå for at tage cindor pajero.

      4.- Det afhænger af selvregenerering, det gør det ikke af sig selv, faktisk foreslog jeg det til systemd devs som en funktion, at det regenererer sig selv uden at stoppe logning, medmindre tjenesten genstartes, de tog det som det de er for at tilføje, så sug min pik og fortæl mig tak far, fordi du samarbejdede, mens jeg ser porno.

      Farvel tynd, jeg blev træt af at tale med aber, fordi jeg foretrækker at gå i zoologisk have, når du er på niveau med min anus, vi snakker med.

      1.    Rolo sagde han

        @SynFlag Jeg undskylder, jeg vidste ikke, at du var syg, jeg troede virkelig, du var en fabelagtig og uvidende, men med det du lige skrev, indser jeg, at du faktisk er vildfarende.

        godt intet, jeg håber du graduerer din medicin bedre og kommer tilbage til virkeligheden, kraft! du kan!!!

  31.   pedro sagde han

    Jeg læser og læser og læser igen, men jeg forstår ikke noget, jeg ved kun, at siden Xubuntu 14.04.1 kom ud til dato, har jeg ikke haft noget problem med min notesbog eller med min hp 1102 laserprinter, jeg ved slet ikke noget, jeg er bruger og Jeg ved ikke, om systemd er værre eller ikke egnet til init, men jeg gentager, at jeg ikke har nogen problemer med xubuntu. 🙂

  32.   Den rigtige sagde han

    Jeg læser, læser og læser igen, og jeg ved bare, at jeg genoplever et gammelt emne. XD