Avmystifierar System D.

Varje dag utgör våra datorer en viktigare del av vårt liv, om det har något slags problem påverkar det vårt humör, vår humor hehe. Visst, Windows-användare är mer benägna att få panikattacker än om virus (länge leva Linux!), tänk om du defragmenterar hårddisken, tänk om du söker och installerar Clean Master för PC (även om vi här i Linux fortfarande måste städa systemet är BleachBit ett av de föredragna alternativen). Nyligen har Linux-användare (vissa) en viss huvudvärk som heter: SYSTEMD

Jag har läst en intressant artikel om SYSTEMD, vilket verkar vara trenden inte länge.

SystemD, som för vissa tycks (och jag kommer att använda ord från en vän), en ring att härska över dem alla ... För andra kommer det helt enkelt inte eller går, så länge datorn fungerar bra, spelar det ingen roll om init gör X- eller Y-saker, eller om systemd används. Till den som skriver, ja ... låt oss säga att jag föredrar init, jag tycker det är enklare 🙂

Jag lämnar artikeln här:

Innan jag börjar måste jag säga att jag inte gillar beslutet att ändra saker i Debian, men jag planerar inte att överge min älskade spiral vid något tillfälle. Jag försöker bara det, om vi ska diskutera ett ämne, åtminstone gör vi det så förberett som möjligt trots att jag inte anser mig vara pro-systemd. För att uppnå avmystifiering av systemd kommer jag att lita på en webbplats där utvecklare ger sin synpunkt som kom till mina händer av en kollega som verkar vara pro-systemd även om han inte är en Debian-användare. Som sagt tror jag att jag kan gå vidare till att försöka avmystifiera vad som sägs om systemd.

systemd är binärt baserat

Kanske är det en av de aspekter som chockar oss mest, om allt är baserat på binär, hur övervakar vi de saker vi brukar göra genom loggar? Jag har ingen aning om hur denna myt föddes, men det är inte helt sant.

systemd konfigureras nästan uteslutande genom vanliga textfiler. Vissa inställningar som också kan ändras med kärnans kommandorad och genom miljövariabler. Det finns inget binärt i din konfiguration (inte ens XML). Bara en enkel, enkel och lättläst textfil.

systemd fans homer simpson

Den saken är monolitisk och den kontrollerar allt

Innan jag kom till ovannämnda webbplats erkänner jag att jag själv tänkte på det här sättet, men efter att ha läst vad dess utvecklare säger har min åsikt förändrat något ...

Om du bygger systemd med alla konfigurationsalternativ aktiverade kommer du att bygga 69 individuella binärer. Dessa binärfunktioner har olika uppgifter och är noggrant åtskilda av flera anledningar. Till exempel har systemd utformats med säkerhet i åtanke, därför kör de flesta demoner med minst privilegier (med exempelvis kärnfunktioner) och ansvarar för endast mycket specifika uppgifter för att minimera deras fotavtryck. Säkerhet och påverkan. Systemd-paralleller startar också mer än någon tidigare lösning. Denna "parallellisering" skapas genom att köra olika processer parallellt. Därför ser man att systemd är mycket väl uppdelat i många binära filer och därför processer. Faktum är att många av dessa binära filer skiljer sig så bra att de är mycket användbara utanför systemd.

Ett paket som innehöll 69 individuella binärer kunde knappast kallas monolitisk. Vad som skiljer sig från tidigare lösningar är dock att vi levererar fler komponenter i en enda tarball och håller dem kedjade i ett enda arkiv med en enhetlig frigöringscykel.

Det ser inte ut som Unix

Det finns verkligen viss sanning. Systemd-källfilerna innehåller inte en enda kodrad från de ursprungliga UNIX-raderna. Men inspiration hämtas från UNIX, och därmed finns det mycket UNIX i systemd. Ett exempel kan vara UNIX-idén "allt är en fil" vilket återspeglas i att i systemd alla tjänster exponeras vid körning i ett kärnfilsystem, c -grupper. Så, en av de ursprungliga funktionerna i UNIX var stöd för flera platser, baserat på inbyggt terminalstöd. Med systemd kom vi med stöd för flera platser naturligt igen, men den här gången med fullt stöd för dagens hårdvara, som täcker grafik, möss, ljud, webbkameror och mer. I själva verket är utformningen av systemd som en serie integrerade verktyg som alla har sina individuella syften men när de används tillsammans är mer än summan av delarna, vilket är mer eller mindre kärnan i UNIX-filosofin. Så sättet vårt projekt hanteras på (dvs. hålla det mesta av operativsystemets kärna i ett enda git-arkiv) är mycket närmare BSD-modellen (som är en sann UNIX, i motsats till Linux) för att få saker gjort (där det mesta av kärnoperativsystemet förvaras i ett enda CVS / SVN-förvar) vilket aldrig var fallet på Linux.

I slutändan betyder frågan om något är UNIX eller inte mycket lite. Eftersom det är tekniskt utmärkt är det knappast unikt för UNIX. För oss är UNIX ett stort inflytande (faktiskt det största), men vi har också andra influenser. Därför kommer systemd att vara mycket UNIX och i andra lite mindre.

Det är väldigt komplicerat ...

Det finns verkligen viss sanning i det. Moderna datorer är komplexa odjur och operativsystemet som körs på dem kommer självklart också att vara så de måste vara komplexa. Systemd är dock inte mer komplicerat än tidigare implementeringar av samma komponenter. Det är enklare och har mindre redundans. Å andra sidan kommer att bygga ett enkelt systemd-baserat operativsystem innebära mycket färre paket än traditionella Linux-användningar. Färre paket gör det lättare att bygga ditt system, det blir av med varandra beroende och mycket av det olika beteendet hos alla inblandade komponenter.

Det låter mig inte använda skalskript

Detta är helt osant. helt enkelt Vi använder dem inte för startprocessen, för vi tror att de inte är det bästa verktyget för det specifika ändamålet, men det betyder inte att systemd var oförenligt med dem. Du kan enkelt köra skalskript som systemd-tjänster eller demoner, du kan köra skript skrivna i någon språk som systemd-tjänster eftersom systemd inte bryr sig minst vad som finns i dess körbara. Å andra sidan använder vi till stor del skalskript för våra egna ändamål, för installation, byggnad, testning av systemd. Och du kan klistra in skripten i den tidiga startprocessen, de används för normala tjänster, de kan köras vid sista stoppet, det finns praktiskt taget inga gränser.

Vid denna tidpunkt antar jag att vissa av de viktigaste övertygelserna kan ha klargjorts, trots att jag inte känner mig som en förespråkare för förändring och har min oro överen demon för att kontrollera dem alla"Jag tror att ingen i slutändan vågar säga att det åtminstone inte fungerar, jag känner till och med vissa användare som märker att med systemd" körs datorn snabbare "men det skulle vara andra saker som skulle kunna diskuteras. För tillfället återstår det bara för mig att bjuda in dig att diskutera de synpunkter du har om starthanteraren som många distributioner har antagit, även om nu de största reaktionerna ses inom Debiansamhället som till och med har fött en ny gaffel med allt detta. Oavsett om du gillar det eller inte är en fråga för alla, för min del vill jag bara göra mitt för att avmystifiera systemd som så småningom kommer att finnas i Jessie, nästa stabila version av Debian.

 Jag såg artikeln i GUTL (som i sin tur togs från FromAbreus)

poettering-1984

Systemström?

Jag är en av dem som inte läser mycket nyheter när något genererar så mycket kontrovers, jag föredrar att stanna med mer tekniska detaljer. Är det…. Ibland känner jag att vissa ämnen slutar vara enbart teknisk diskussion eller debatt och blir som en av dessa kändisskvaller ip

Först kallas en öppen rad från en användare till systemd systemd VS intelligens, sedan Linus Torvalds säger det systemd är inte så dåligt hur de målar detoch någon anledning om han har), en gaffel som heter värdelös ... Inga kommentarer ... och slutligen Devuan.

Jag kommer inte att säga om det är så illa som de säger, mindre dåligt eller sämre. Systemet fungerar för mig utan problem, men för personlig smak föredrar jag init, för dess sätt att organisera olika saker (som loggar till exempel) jag gillar bättre, men hej, om systemd kommer att kallas en tävlingshäst och måste bytas ut till i det (Skulle det vara vår packmule, som gör allt annat än långsamt?) Tja ... man, så länge förändringen inte är extremt plötslig kan användarna anpassa sig utan mycket problem och systemet fungerar bättre (ja, bättre, det räcker inte för mig!), Välkommen 😀


Innehållet i artikeln följer våra principer om redaktionell etik. Klicka på för att rapportera ett fel här.

114 kommentarer, lämna din

Lämna din kommentar

Din e-postadress kommer inte att publiceras.

*

*

  1. Ansvarig för uppgifterna: Miguel Ángel Gatón
  2. Syftet med uppgifterna: Kontrollera skräppost, kommentarhantering.
  3. Legitimering: Ditt samtycke
  4. Kommunikation av uppgifterna: Uppgifterna kommer inte att kommuniceras till tredje part förutom enligt laglig skyldighet.
  5. Datalagring: databas värd för Occentus Networks (EU)
  6. Rättigheter: När som helst kan du begränsa, återställa och radera din information.

  1.   mörkare sade

    Mycket bra artikel, jag har varit med Linux Mint 17.1 Rebecca med systemd i några dagar och jag känner mig mycket mer flytande än i tidigare versioner, jag vet inte mycket om detta eftersom jag är en vanlig användare som lär sig om detta men Jag kommer att vara medveten om, det här är den första artikeln jag läser som inte talar skadedjur av systemD.

    1.    SynFlagga sade

      För något kommer han att vara den första du läser som inte talar skadedjur om honom och å andra sidan, säg mig, använder du din mynta som server? Jag menar, det skulle inte störa dig om det har en bugg från då och då, nej?, och det är därför det inte stör dig, du gillar det inte men inte heller systemd skruvar dig. När du har buggar och på grund av det har du allvarliga problem i allvarliga miljöer stör det dig.

      1.    carlos sade

        Dude, någon Debian Stable-baserad distro du rekommenderar? Jag skulle kunna använda Debian, men du måste konfigurera många saker en gång installerat, codecs, etc ... Vilken rekommenderar du? tack.

    2.    Santiago Burgos sade

      Och hur lyckades du få systemd till Linux Mint? Jag ville försöka sätta in den men jag vet inte om något ytterligare behöver göras (som, i teorin, Ubuntu redan ger), om du har någon guide i saken eller något du kan ge mig vidare, jag skulle uppskatta det

  2.   Giskard sade

    Mycket bra artikel. Låt oss se om Taliban anti-SystemD läste det (men jag tvivlar på det)

    Hur som helst, om ett år framöver ser jag dem använda SystemD och de kommer att förneka vad de sa för ett år sedan. Så de är. Motståndskraftig mot förändring? Visst ja.

    1.    elav sade

      Du anser mig vara en taliban för att jag inte vill acceptera Systemd, då anser jag att du är en taliban för att du inte vill acceptera att jag inte vill acceptera Systemd. Vi är till hands 😉

      1.    jlbaena sade

        Men som det står i slutet av dina artiklar:

        «Elav: Personlig blogg / Twitter / G + / ArchLinux-användare. Datavetare, musikälskare, bloggare och webbdesigner. Administratör och grundare av DesdeLinux.net. »

        det vill säga du använder en av de första distributionerna som SystemD antog.

        hälsningar

    2.    George Robles sade

      Okej.
      Utan ord !!!!, fortsätt spela, att livet är rosigt.

    3.    Tito sade

      För kommentarer som din, kära Giskard, det är därför jag avstår SystemD och vad det står för.
      Och om jag efter 20 år använder och arbetar med och för Linux är jag taliban; Tja, så var det.

    4.    Giskard sade

      Om ett år pratar vi. Och elav, jag nämnde inte dig. Du dödade dig själv som Chacumbele.

    5.    Giskard sade

      Låt oss se, folk läser och läser INTE. Finns det eller finns det inga talibaner mot SystemD? Det finns! Och det finns andra på andra sidan, de som försvarar det tand och spik som om det vore ett universalmedel. Vad är det alla som är? Nej! Inte alls! Det finns de som sympatiserar med den ena eller den andra och ser det goda och det dåliga både av sina egna och av andra. Med dem kan du prata utan problem. Men de kommer inte att förneka att det finns talibaner. Och från sida till sida. Och om någon blev stucken av det utan att förstå att de mycket väl INTE kunde vara taliban, så vilar jag mitt fall eftersom bevisen gör dem skyldiga.
      Om jag dialogar med någon om SystemD och från början kallar den personen inte vid hans namn utan Systemshit eller något liknande, skulle jag uppriktigt vilja att de berättade för mig om det är möjligt att ha en konversation med en sådan person som ursprungligen diskvalificerar motståndare. Det kan inte.
      Hur som helst måste du läsa. Låt oss se, om jag kommer och säger "är det några eschejfhduf (ord som uppfanns) som slår barn när de lämnar skolan" och några kommer för att försvara "eschejfhduf" är det inte att tro att de själva är det?
      Tja, om någon där ute (inte talibanerna, snälla och inte eschejfhduf heller) vill prata om för- och nackdelar med init och SystemD (som båda har bra och dåliga) kommer jag gärna att vara där.
      Hälsningar.

    6.    synflagg sade

      Talibanens antisystemd? och säg mig, vad är du? Pro-system Taliban?, Å andra sidan, varför antar du att vi inte kommer att läsa utan att kommentera direkt?, vem är den slutna taliban som inte erkänner diskussion och talar som LP :: «Det är bäst, lita på mig, jag vet vad jag gör ". ?

      Jag läste hela artikeln och kan berätta:

      Systemd är binärbaserat: sant
      Avmystifiering: Falskt

      LP visar felaktigt vad som sägs, vilket är att systemd-kärnan är binär, många, för många att hänga från PID1, starkt sammanflätade, så mycket att jag uppmanar dig att titta på #devuan hur det kostar att rengöra, till exempel logind systemd och resten av paketen i Debian, med tanke på hur knuten loggningen som ersätter PAM är med systemet.

      Konfigurationen är kortfattad och tillåter inte ALLT som jag inte vill, som att inaktivera journalen, eftersom du varken kan döda PID, eller stoppa den eller något, det är modularitet? Med sysvinit åtminstone kan du döda allt tills du var bara kvar med init, samma uppstart.

      ===========
      "Den saken är monolitisk och kontrollerar allt."

      Det är, utöver det faktum att de är två eller 2 binära filer, de är sammanflätade med varandra med dbus och därmed med hela operativsystemet, så att de inte lätt kan relateras, det tydligaste fallet är journald, att du inte kan inaktivera det, också startar daemoner eller tjänster genom "enheter" som är textfiler, men inget mer än det, analyserat av systemd och voila, inga modifieringar eller hack i tjänster utöver vad som är etablerat.

      =======

      "Ser inte ut som UNIX"

      Jag kommer att svara på det kort. Det överensstämmer inte med LSB, inte heller med POSIX och idag sa en Fedora-utvecklare som hjälper till i #devuan: «Det är sant att det inte är, det spelar ingen roll, det som är viktigt är att det kan köra saker som är POSIX, vila, jag är verkligen inte intresserad av vilket operativsystem eller vad som helst, så länge det fungerar och har bra funktioner ». Och varför det ska vara UNIX eller UNIX-liknande: Gör en sak och gör det bra, något som systemd inte gör.

      ===========

      Systemd är dock verkligen inte mer komplicerat än tidigare implementeringar av samma komponenter. Det är enklare och har mindre redundans »

      Mindre redundans? De ber dig att installera EN ANNAN syslog för vanlig text och de bad om det för fjärrloggning innan det fanns systemd-journald-remote, det vill säga de satte den i produktion utan att kunna göra en fjärrloggning utan att bero på rsyslog , något grundläggande som den centraliserade inloggningen. Ändå har den inte förmågan, en enkel boolean att ange om vi vill ha utdata i binär eller i vanlig text och om det skulle använda binärt, varför inte något som kallas berkeley DB så att det kan läsas från något UNIX- eller Linux-system?

      Enkelt?, Verkligen? ta en titt på hur enkelt det är: http://wiki.gentoo.org/wiki/Comparison_of_init_systems

      Titta på mängden rader med kod och filer.

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

      "Det låter mig inte använda skalskript"

      Det är falskt, men återigen är det felaktig framställning, det kritiseras inte för att inte tillåta användningen av bash-skript, utan för att inte använda dem för att starta tjänster, varför det inte är modifierbart, hackbart och flexibelt liksom uppstart eller sysvinit. Och med hackbar menar jag hårkodad.

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

      Du tror fortfarande att:

      1.- Jag har ingen anledning alls
      2.- Jag läste ingenting och är jag taliban?

      1.    Richard sade

        Jag undrar ... måste jag verkligen lita på vad Lennart säger? Om någon neutral säger till mig att jag kan ta vissa saker i beaktande, men det smakar samma sak för mig när Red Hat publicerar något för att försvara Systemd

  3.   ArthurShelby sade

    Wow, tills någon här säger något rimligt och inte bara rädsla och felinformation.

    1.    elav sade

      Artikeln är den spanska översättningen av vad Lennart skrev.

      1.    Charlie brun sade

        Inget brott, men översättningen verkar ha gjorts av betaversionen av Google Translator ... 🙁 Jag hade svårt att förstå några stycken; hur som helst informationen uppskattas.

      2.    Martin sade

        @ Charlie-Brown, det beror på att Lennart inte vet hur man uttrycker sig på engelska så bra. Så ful är det genom att läsa originalet.

  4.   Charlie brun sade

    Anledningarna är giltiga, men jag tror att vissa kan generera fler frågor. Hur som helst, min rekommendation till dem som har möjlighet: gå till den ursprungliga informationskällan http://0pointer.net/blog/projects/the-biggest-myths.html (tyvärr för vissa är det på engelska) som är mycket mer komplett och går så långt att det underbyggs upp till 30 skäl till varför användningen av SistemD anses gynnsam.

    1.    elav sade

      Den artikeln du nämner är skriven av skaparen av Systemd. Uppenbarligen ingen bättre än honom att försvara sitt arbete, men jag uppmanar dig att titta på den här videon http://hackingthesystem4fun.blogspot.com/2014/12/systemd-journald-centos-7-totally.html och de kommer att berätta för mig vad de har dragit. Jag säger inte mer.

      1.    Rolo sade

        elav frågan om journalloggar som finns i en binär är en av de mest kritiserade punkterna, till och med linus själv tog upp den, när han i en rapport där han erkände att systemd inte var så dåligt. Linus själv förklarade också att du kan skapa ett manus för att ta journaldata och lägga den i klartext.
        Även systemd låter dig konfigurera storleken på journalbinären, vilket minskar risken för ett eventuellt fel.

        Egentligen är konsten du citerar väldigt oseriös, eftersom den inte har en antydan till objektivitet, och det får mig till och med att undra om felet det visar är verkligt eller är det falskt (knulla den proprietära programvaran så att den ger felet).

        alla program har buggar någon gång, men det verkar som att de alltid kommer att leta efter kattens femte ben för att hitta något fel med systemd.

        Till exempel: i debian bestämdes det att systemd ska vara standardinit, men det förhindrar inte att man använder sysvinit eller openrc eller upstart och du kommer att säga till mig ja, men du kan inte ta bort systemd helt, och mitt svar skulle vara att det är samma som det hände i debian wheezy där du kan köra openrc, systemd eller upstart men under sysvinit

        PS: Jag vill inte föreställa mig hur galna de kommer att bli med kdbus och dess integration med systemd på Linux-kärnnivå http://kroah.com/log/blog/2014/01/15/kdbus-details/

        1.    elav sade

          Om det kan vara. Dessutom planerar jag att officiellt dra mig ur diskussionerna om Systemd. Vad som än måste hända 🙂

      2.    yukiteru sade

        @rolo misslyckandet är dokumenterat, han har fått flera felrapporter, de presenterar honom en video och nu säger de att den är förfalskad. Om du vill vara säker, följ stegen och se vad som händer. Nu är det mer information om saken, uppfann buggar? Jag tror inte det.

        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 och hans fantastiska förklaringar)
        https://bugzilla.redhat.com/show_bug.cgi?id=974132
        https://bugzilla.redhat.com/show_bug.cgi?id=1157350

      3.    emmanuel sade

        Vad videon nämner är verkligen nyfiken. Som utvecklare får vi alltid höra att en detalj inte ska påverka hela systemet / programmet, till exempel om en vald fråga till databasen misslyckas, varför skulle hela programmet krascha? Det är samma sak med SystemD, om det misslyckas eftersom andra misslyckas vet jag inte hur bra gjort det är. Uppenbarligen finns det fall där ett fel praktiskt taget är ett systemfel, men ju mer internt isolerade programegenskaperna är, desto bättre blir produkten.
        Att attackera programvara från dess svaga sida är inte nytt, det är snarare en mycket vanlig praxis och att det faktiskt borde göras med alla program, så att se SystemD falla för journalen är ett giltigt bevis på att SystemD Det är inte vad som är sa eller ledde till tro.
        Ju mer saker blir beroende av varandra med SystemD, desto värre blir det. Om montering av en enhet inte kraschade systemet förut, kanske det inte ser så bra ut nu.
        SystemD är inte dåligt, jag hatar inte det, men det är inte vad många vill ha dig att tro. Det har fördelar, men ingenting som Upstart inte hade eller kunde ha, naturligtvis var Canonical inblandad och ingen ville uppmärksamma längre.
        Hälsningar.

      4.    Rolo sade

        men i den videon vet jag inte att systemet kraschar. vad typen gör är att ändra binären för journalinformation för att generera felet, men poängen är att varje gång den går in i systemd.
        Enligt vad jag förstår, om du begränsar storleken på den binära journalen, när den når gränsen skapar den en ny och så vidare. minskar möjligheten att skada all data.

      5.    Jorge sade

        Låt oss vara tydliga ... Vem skulle också kunna tänka sig att ändra loggfilen? xD

      6.    anonym sade

        @Jorgicio 4 december 2014 6:03
        Låt oss vara tydliga ... Vem skulle också kunna tänka sig att ändra loggfilen? xD

        Om du sa det på ett ironiskt sätt ... okej, förstod jag :)), men om du verkligen frågade ger jag min åsikt.

        För mig är det klart att det inte är ett fel, det är en funktion !! Tanken är att om det sker en eskalering av privilegier i en fjärråtkomst, skulle det vara mycket lätt för dem som går med på att ta bort loggen genom att helt enkelt redigera den för att skada den och för systemd att ta bort den som korrupt och därmed bli av med att upptäckas i den fjärråtkomst.
        Berätta för mig paranoid, men jag har inget annat sätt att tänka ... det är inte ett fel, det är en funktion och det är därför de inte accepterar att fixa det.

  5.   daryo sade

    uff nu gör alla Linux-bloggar 200 artiklar om systemd till den punkten att jag redan vet nästan alla argument mot och för xD.

    och så småningom har jag blivit övertygad om några av anti-sistemd-argumenten och bland dem som jag har sett (om det är något fel snälla korrigera mig)

    Jag såg till och med en artikel om hur man kraschar hela systemet när en binär logg redigeras och att den inte ger någon information om att filen är korrupt.

    bristen på tydlighet i stockarna

    ett utvecklingsteam som ofta ignorerar felrapporter

    Att vara så stor och inkludera så många saker inuti en init gör systemet mycket mer instabilt och om vi lägger till buggar som det som nämns ovan, gör det ett system utan den stabilitet som Linux kännetecknar så mycket.

    det sägs modulärt men delar av det kan inte fungera utan andra delar av samma systemd

    en utveckling som på sikt genererar beroenden vid programmering, vilket gör programvara som gnome knappast bärbar för system utan systemd.

    den ersätter delar (nätverksd, logind etc) som har arbetat och fått underhåll i flera år och ändrar dem för nya utan behov som tenderar att ha många fler buggar.

  6.   mat1986 sade

    Från den tidpunkt då jag har använt Arch-baserade distros (Manjaro, Bridge Linux, Antergos) som uppenbarligen använder systemd, måste jag säga att jag inte har några klagomål angående dess användning och hantering. Att starta tjänster är enkelt - ännu mer i Bridge, där Bluetooth eller modemmanager är inaktiverade som standard. Bortsett från ett fel relaterat till hwdb.bin (https://bbs.archlinux.org/viewtopic.php?id=189536) Jag har inte haft många problem. Självklart tror jag inte att det är allas åsikt, men personligen har jag inga klagomål 🙂

  7.   Solrak Rainbowarrior sade

    Jag gillar inte tanken att ett företag (Red Hat) som anklagas för att samarbeta med NSA (bakdörrar och amerikansk kontroll) skapar ett system med vilket allt kontrolleras. En ring för att kontrollera dem alla, för att binda dem i mörkret vid behov ..

    Å andra sidan måste jag erkänna att Intel IRIS PRO 5200 fungerar bättre för mig och nästan aldrig, om inte längre, bryts mitt grafiksystem när jag startar openSUSE 13.1. Och ja, allt är bättre, det startar och stängs av mycket snabbare. Hur en enkel användare har gynnat mig.

    1.    johnfgs sade

      den anklagade att samarbeta med NSA

      Jag lyfter fram den viktiga delen

      Om någon anklagar dig för att sälja droger, är du automatiskt en droghandlare?

      1.    anonym sade

        @juanfgs
        Droghandlare nej ... en medbrottsling ja.

      2.    johnfgs sade

        Droghandlare nej ... en medbrottsling ja.

        Gud ... jag skulle förolämpa dig men dina egna ord gör det åt dig.

  8.   Raphael Castro sade

    Förtydliga bara att systemd är skrivet, och det är så det ska göras.

    Stavning

    Ja, det är skrivet systemd, inte system D eller System D eller till och med SystemD. Och det är inte heller system d. Varför? Eftersom det är en systemdemon och under Unix / Linux är de med gemener och får efterföljande med små bokstäver d. Och eftersom systemd hanterar systemet kallas det systemd. Det är så enkelt. Men igen, om allt som verkar för enkelt för dig, ring det (men stava det aldrig!) System Five Hundred eftersom D är den romerska siffran för 500 (detta klargör också förhållandet till System V, eller hur?). Den enda situationen där vi tycker att det är OK att använda en stor bokstav i namnet (men inte gillar det heller) är om du börjar en mening med systemd. På högsemester kan du också stava det sÿstëmd. Men då är Système D inte en acceptabel stavning och något helt annat (men ganska passande).

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

    1.    elav sade

      Även här? Du lägger det i GUTL .. men man, alla säger Linux och inte GNU / Linux, så med SystemD detsamma.

  9.   Germán sade

    Jag säger till dig att det inte är nödvändigt att använda loggsystemet eller cron som systemD tillhandahåller, du kan följa syslog-ng och cronie för detta eller andra alternativ
    Jag använder systemD i ArchLinux eftersom jag var i aur och det verkar enklare att hantera än debian- och redhat-härledda form, det har många konsolkommandon som sparar dig från att redigera textfilerna och förenklar montering av skript. Installationskonfiguration (kom ihåg att i arch är allt installerat av konsolen)
    Och inte minst startar systemet snabbt, i arch kan du starta tjänster parallellt när du startar systemet men det var riskabelt

  10.   Santiago sade

    Vad jag tycker är dåligt med problemet är att de flesta tar sida, eller om du är pro-systemd eller anti-systemd, och jag tycker att det har sina bra och dåliga saker, jag är en användare och jag började spela lite med systemd, verkligen De goda sakerna är, uppstarten är snabbare och mindre komplex än resten av initiativet, även om numret på tidskriften också stör mig mycket.
    Jag förstår att de som verkligen kan berätta om det är bra eller dåligt är sysadminerna eller experterna i ämnet men det verkar för mig att systemets krångel för ett tag sedan slutade vara något tekniskt och blev något mer "show-stop", för min del är jag lite emot men jag anser mig inte anti eller proffs

  11.   yukiteru sade

    @KZKG_Gaara

    Jag ser att mycket av det du kommenterar här är detsamma som Lennart har publicerat på sin blogg, mer exakt i det här inlägget: http://0pointer.de/blog/projects/the-biggest-myths.html.

    Naturligtvis har inlägget haft vissa "förtydliganden" och har avsatt visst tekniskt innehåll för att vara lätt att smälta information för dem som ska läsa den, men vi kommer att vara seriösa och uppriktiga, även om sanningen är gör ont: systemd har många saker som Lennart förnekar att den inte gör, det och mycket mer faktiskt. Och i den meningen förklarar jag delvis.

    1. - Lennart säger att han inte är uppsvälld och att han inte har ett högt NIH-syndrom (Not Invented Here Syndrome). Förklara i så fall någon för mig: Varför en init ska ha nätverkskontroll (systemd-networkd), dns (systemd-networkd), m-dns (systemd-networkd), logs (journald), coredumps (systemd -coredump), debugs (systemd-coredump och journald), acpi (logind), privilegium eskalering (logind), kontroll av ntp (systemd-timesyncd), kontroll över dev (systemd tog all funktion av udev), kontroll av / dev / random (slumpmässigt nummer generator) och den senaste kontrollen över TTY (systemd-tröstad)? Var det inte MÅNGA verktyg skapade för sådana ändamål att systemd nu lägger till sina egna några med exklusiv åtkomst (journald case)? Vilken logisk och acceptabel förklaring ger du mig för att en init ska kunna bryta kärndebuggen och cmdline? För att lägga till kontroll över kdbus, nästa IPC som kommer att integreras i kärnan. Visst kommer de att säga till mig här: «Men du kan installera ett annat verktyg för att kontrollera allt detta». Och om det är sant, men många av dessa verktyg får bara en dataström som kastas av systemd, som i fallet med syslog och rsyslog, som ansluter till en data / ström som journald tillhandahåller så att andra verktyg kan se vad journald driver i slutändan betyder det bara att du har två verktyg som gör samma sak, och ett av dem är en pandoras låda. (Berätta inte för mig att koden kan granskas, för jag bjuder in någon att "röka" journald-koden och dess ramverk med systemd och andra relaterade verktyg)

    2. - Lennart berättar också att systemd erbjuder stöd för SysV- och LSB-skript. Detta är en "halv sann" en "vit lögn" så att säga, för sanningen är att systemd-214 inte erbjuder stöd för bash-skript, SysV eller LSB och det är relaterat i dess release-anmärkningar för den versionen.

    3.- Vilket systemd är inte bärbart? Det är en annan svag punkt. I BSD fungerar det inte bra, i BSD finns det inga Cgroups bland andra verktyg som systemd behöver köra. Men det är av systemd designskäl, inte för att det inte är bärbart. Tills BSD-kärnan inte uppfyller det minsta för att stödja den, kommer systemd inte att fungera på den plattformen och det är inte någons fel, bara att BSD inte har något intresse, inte heller Lennart. Det är så enkelt. Nu är stödet för andra C-bibliotek en annan sak, välkända är glibc-problem (gör bara en kärna för hand för att se mängden alternativ och lösningar som har gjorts för att undvika dessa detaljer, särskilt för glibc 2.3, 2.5 och 2.11, bland andra brister som glibc har dragit med sig genom åren) men det slutar inte där det slutar inte, Lennart själv har sagt att han föredragit att skapa sitt eget libc-bibliotek, för för sin grupp är det mycket snabbare att göra det som detta än att läsa kod som redan har skapats (och dokumenteras förresten), men det stannar inte där, de planerar att ta bort glibc och använda sin libc inte bara för systemd utan också för Fedora, vilket gör det standard för konstruktionen av alla deras paket. NIH Var? Det verkar som om gamla gamla Lennart gillar att trolla och stort.

    4.- Det systemd är inte monolitiskt eftersom det är uppdelat i 69 binärer. Ja ja, det här är diskutabelt. systemd har 69 binärer, som utför olika uppgifter, men dessa binärer skickar sin uppgiftsinformation till systemd, så om en misslyckas ökar chanserna att bryta systemet ganska dramatiskt. Detta är väldokumenterat, felrapporter finns i överflöd med problem som dessa och ännu enklare problem, dumt enkelt faktiskt. systemd kan delas in i hundratals binärer, men så länge din kärna har kontrollen fortsätter risken för ett avbrott och ökar, och om du inte tror mig, läs bugrapporterna och ha kul.

    Observera att här har jag inte kommenterat något som systemd är skräp, jag har bara gjort bara "tekniska" kommentarer (det är uppenbart att tekniska saker blir väldigt komplicerade) och giltiga, stödda av information lätt tillgänglig på internet. Nu: Vilken Linux behöver en standardinit? Ja, det skulle verkligen vara något av stort värde för samhället. Vilken systemd är lösningen? Nej, även om det är nära har det verkligen många positiva saker, men dess virusspridning och antalet saker det ökar risken för vad som kan gå fel och hamna i samhället.

    PS: Jag lämnar material där du kan bekräfta vad jag säger, läs det kommer att vara ganska illustrativt och se att jag inte inkluderar bloggar eller något liknande, ren personlig och baserad kritik. Hälsningar.

    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 kanske du känner dig identifierad)
    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 sade

      Amen bror .. amen ..

    2.    pamp sade

      Jag ser fortfarande inga giltiga skäl att inte anta systemd. Du tolkar helt enkelt det du ser med rädsla, vilket leder till överdrifter. Varken tydliga och väldefinierade fördelar eller nackdelar.
      Dessutom möjliggör integrationen den standardisering som du till och med talade om. Inte bara Red Hat fungerar på systemd, men olika företag och volontärer från andra distributioner.
      Jag tror att felet är att driften av systemd inte studeras ordentligt.

      1.    Xiep sade

        Jag ser giltiga skäl i Yukiterus analys. Lägg märke till att istället för rädsla ser jag noggrannhet, precision och tydlighet. Det måste vara en ögonläkare fråga.

      2.    yukiteru sade

        Det är inte rädsla (jag är inte rädd för en kodkod) och de är inte heller överdrivningar (allt jag har sagt här är dokumenterat och jag har skickat tillräckligt med information som bekräftar den, information som förresten kommer från listorna och från sinnet / rösten Lennarts egen handskrift, och inte från en bloggers kommentarer), det är VÄRLDEN.

        systemd gör allt det och mycket mer, och det är något BEKRÄMT (ett annat koncept än att vara rädd) eftersom det verkligen tar attribut och gör saker som just nu kan göras på andra sätt och som förresten fungerar bättre och är mer stabila . systemd är väldigt Windows-liknande, och det kan inte döljas, vet bara vad userinit.exe, svchost.exe, smss.exe och andra beroenden gör och jämför dem med systemd, likheten är så stor att det är en dålig idé. Nu kan säkerligen systemd ha en bättre kvalitet än dess motsvarighet till Windows (eller motsatsen kan hända, ingen vet riktigt, om du inte programmerar för Microsoft) men du kan inte anklaga mig för EXAGGERATED och FARABLE när du läser Lennart själv I en lista och talar att skapa ett helt nytt C-bibliotek, för han är trött på Glibc, och att napa, släng in det lilla och obetydliga tipset, att libc kan användas för att bygga alla Fedora-paket. Och om du tror att det är en lögn och att jag är överdriven, lämnar jag meddelandet i denna länk: http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html (på engelska)

        Berätta för mig om det är en överdrift att säga framför alla dessa saker, att när Linus väl beslutat att CONFIG_VT som det är, måste han lämna kärnan (situation som har funnits länge) och skicka den till användarutrymmet, händer inte en galen sak som om systemd-consoled är ett starkt beroende för nästan vilken Linux-installation som helst (något måste hantera VT, tror du inte?), som inte skulle sätta olika icke-systemd distroer i rampljuset för att tvinga en omkopplare. Om du tycker att det är en sträcka, låt mig berätta att du inte har någon aning om vad Lennart kan och gör, eftersom hans senaste förändringar påverkar utvecklingen av udevgaffeln, Gentoo eudev, och han kommer att fortsätta göra det med sina hot under tabellen (för att senare klaga som han gjorde på Google+)

      3.    yukiteru sade

        @xiep Jag kan inte hålla mer med din kommentar.

      4.    johnfgs sade

        Che Yukiteru, ditt långa uttalande utelämnar det faktum att e-postmeddelandet som du länkade till libc är ett aprilskämt, titta på fotnot och titta på datumet (31 mars, förmodligen 1 april i Lennarts tidszon)

        [1] Vi kan lägga till en kärna senare efter att GNU / Hurd lyckats
        närma sig.

        Öva din engelska-fu eftersom den är vattnig och ifrågasätter all din "forskning".

      5.    yukiteru sade

        @juanfgs du verkar vara den enda som läser, åtminstone jag applåderar dig för det, men du måste läsa något mycket viktigt som finns i min kommentar, det spelar ingen roll jag lägger det här:

        »NIH Var? Det verkar som om den gamla gamla Lennart gillar att trolla och stort. "

        Jag tror inte att han skrev det av en oskyldig anledning, han var medveten om det faktum att det var ett annat Lennart-skämt för aprilens dårens dag (dåligt humör), liksom hans passion för att konvertera /, / etc och allt annat till / Linux. 🙂

        PS: Tack men jag behöver inte träna min engelska, jag har använt språket sedan jag var 6 år gammal
        aaahh och allt annat är sant, verifiera det 🙂

      6.    johnfgs sade

        Jag tror inte att han skrev det av en oskyldig anledning, han visste att det var ett annat skämt från Lennart för aprilens Fool Day (dåligt humör) nalist galen

        Det här är helt sensationalism, du säger att du bygger på fakta men i verkligheten följer du din aning om att killen är dålig och vill ta över världen och du vrider fakta för att återspegla ditt tal. Det här är det som stör mig mycket om anti-systemd människor, de hakar inte ord när det gäller att vrida fakta och berätta halva sanningar, naturligtvis laddade med deras åsikt.

        Min "tumregel" i dessa fall är helt enkelt följande logiska uppdelning, med utgångspunkt från att
        - Jag är en webbutvecklare / skrivbordsapp eller cli
        - Jag har aldrig skrivit ett init-system.
        - Jag håller inte en distro.

        kontrollera om samtalspartnern har:
        - skapat ett init-system
        - är en aktiv underhållare av init-systemet för en distro

        och verkligheten är att de flesta av anti-systemd misslyckas med detta test, de är fortfarande en handfull människor som av någon anledning VET MER än människorna bakom: Debian, Fedora, Archlinux, Linux-kärnan, hela GNOME-projektet, förmodligen KDE-projekt också eftersom de inte har klagat på systemd, SUSE och länge etc.

        Trots det är hans giftiga och vitrioliska tal det enda han uppnår att skapa splittring, problem och andra. Sådan är punkten att jag inte kan vänta på att de äntligen byter till BSD eftersom de har hotat från Xorg, NetworkManager, PulseAudio och jag vet inte om på grund av ren teknisk okunnighet eller för att de inte skulle klaga på det.

      7.    yukiteru sade

        @juanfgs, jag tar dig på ditt ord specifikt om detta:

        «Och verkligheten är att de flesta av anti-systemd inte klarar detta test, även om det finns en handfull människor som av någon anledning VET MER än folket bakom: Debian, Fedora, Archlinux, Linux-kärnan, hela GNOME projekt Förmodligen KDE-projektet också eftersom de inte har klagat på systemd, SUSE och länge etc.

        Trots det är hans giftiga och vitrioliska tal det enda han uppnår att skapa splittring, problem och andra. Sådan är punkten att jag inte kan vänta på att de äntligen byter till BSD eftersom de har hotat från Xorg, NetworkManager, PulseAudio, och jag vet inte om på grund av ren teknisk okunnighet eller för att de inte skulle klaga på det. "

        Så I enlighet med dig är vi alla anti-systemd giftiga och glaskänsliga att det enda vi uppnår är splittring, problem och så vidare. Låt mig berätta att det är den största upprördheten jag har kunnat läsa här. Jag vet inte varför pro-systemet bryr sig, när ett systems strukturella problem framkallas, vilket uppenbarligen kommer att påverka dem någon gång, för ingenting kan ha hänt dem nu, men någon gång kommer de att göra det. det kommer, och då kommer en del antisystemd att påminna dem om orden de sa många gånger och ingen stoppade dem, och kanske någon annan antisystemd ger dem en hand.

        Personligen gillar jag inte systemd, men det betyder inte att jag inte använder init, jag måste, för just om jag måste röra vid en maskin med den init måste jag ha kunskap om hur man hanterar den. Dessutom har jag personligen också använt det sedan jag kom till Archlinux och till och med i Debian och Gentoo, så säg inte att min vision är snedställd genom att inte använda systemd, jag har använt den och jag vet att den haltar och om jag måste hjälpa någon här i FromLinux-forumet eller på IRC eller Debian-listan (som är den distro där jag har varit längst och fortfarande använder i mitt arbete) kommer jag att göra det med nöje, för just om något gläder mig av Linux-communityn, är att det trots skillnaden alltid hjälper.

        Nu för att byta till BSD är det möjligt, men jag kommer bara att göra det om systemd blir så virulent att det inte tillåter mig att använda något annat alternativ, under tiden stannar jag kvar på Linux och inaktiverar all den galenskapen, inklusive många av de Gruppen grupperar saker.

      8.    johnfgs sade

        och verkligheten är att mest anti-systemd

        !=

        Så enligt alla anti-systemd

        Återigen vrider du orden så att de passar ditt tal. Du är mycket bra material för en politiker / journalist.

      9.    johnfgs sade

        Jag klargör, mitt problem är inte att de nämner tekniska problem med Systemd, poängen är att de många gånger laddar sitt tal med lögner, nämligen:

        Att om systemd tvingar dig att använda en microhttpd-server (som är en valfri modul som INTE är installerad som standard), att om systemd är en enda binär, kommer den systemd att stängas eftersom lennart betalas av microsoft, att binära loggar De är obligatoriska. Ingen vill ha systemd och dess antagande sker av en politisk lobby.

        Det är det som chockar, lögnerna. Om det var en rimlig diskussion skulle det vara värt det, men det är bara bra FUD.

        Att du inte gillar det verkar perfekt för mig, jag gillar inte mycket programvara, inte ens programmeringsspråk, distros och andra, men jag uppfinner inte saker om det och jag läser inte heller det jag vill läsa och laddar mina uttalanden med personliga känslor för att skada bilden av människor som utvecklar det.

      10.    yukiteru sade

        @juanfgs ledsen, men jag är inte den som kallar en viss grupp människor "giftiga och vitrioliska" helt enkelt för att de inte gillar en mjukvara.

      11.    johnfgs sade

        Ändå hans tal giftiga och glaskroppar det enda det uppnår är att skapa splittring, problem och andra.

        Återigen, vrida meningar för att bli ett offer.

      12.    yukiteru sade

        @juanfgs igen säger jag dig, det sa du, kolla dina ord, jag förvränger inte dina ord, jag skapade bara en kopia / klistra in dina ord i kommentar 59.

      13.    johnfgs sade

        Jag citerar min textkommentar capo, den som du måste läsa igen är du för att du inte vill förstå, eller om du inte vet hur man debatterar. Du tar saker ur sitt sammanhang och tolkar dem när de sjunger för dig. Så om du vill välja att leva i en värld där du känner dig förolämpad eftersom dina argument är ifrågasatta, Lennart, Red Hat och Microsoft förföljer dig, beror det på att du väljer att tro det.

        Kort här för att jag inser att du inte är en rimlig person för att du inte vill förstå, du vill tolka saker som du tycker passar.

        Om du vill bli förolämpad, ta anstöt, men det är ditt problem, inte resten av världen.

      14.    yukiteru sade

        @juanfgs Jag bryr mig inte om dina kommentarer, sanningen är att jag ser ingen anledning, vi argumenterar, civiliserade människor argumenterar utan att behöva bry sig om det (det är vad jag tycker).

        Om du nu vill märka, föregripa (eller vad du än vill kalla det) människor för deras tal eller handlingar (kanske du bör läsa min kommentar # 64 och mäta bredden på den), det är ditt problem, begränsa dig till dessa handlingar mot dig själv och lämna andra ur väskan.

        Hälsningar.

      15.    Xiep sade

        "De flesta av anti-systemd", "nästan alla", "alla", "någon del av anti-systemd" ... vi avviker, Mariano, vi avviker. I det aktuella fallet: Jag ser inte någonstans att Yukiteru har hållit ett sensationellt tal baserat på hunches (med hänvisning till hans analys på detta sätt har något vridit), tvärtom har han utvecklat solida argument om nackdelarna med systemd baserat på lämpliga frågor och material hämtade från e-postlistor och bugspår (liksom på ett artigt och civiliserat sätt). Möjligen av denna anledning irriterar han vissa och de attackerar honom vid den första kommentaren, för att diskreditera och diskvalificera honom (den här gången på ett giftigt sätt).

        Om du ser att diskursen för de flesta anti-systemd är giftig och vitriolisk, är det jag ser i diskursen av vissa pro-systemd (jag vet inte om de är majoritet eller minoritet) hysteri och förföljelse av dem som, exakt, de gör solida argument bland allt buller. Vi kallar det i mitt land trakasserande oenighet.

        Går systemd bra för dig? Bra, det verkar bra för mig, men låt de som inte tycker samma uttrycka sina reservationer (operativsystemet kanske inte fungerar på samma sätt).

        hälsningar

    3.    pamp sade

      Åh, förresten, varför sprängs något systemd-fel så att hela komponenten slösas bort, men andra som GCC, glibc eller till och med kärnan har inte kritiserats till den punkten för många av deras buggar?
      Du sa det själv, glibc har dragit på sig problem under lång tid. Llvm har över tiden visat sig ha fördelar jämfört med GCC. Och här ser jag inte samma kritik.
      Varför inte göra detsamma med andra projekt?
      Det är helt enkelt kollektiv och irrationell rädsla för mig.

      1.    yukiteru sade

        Glibc har sina buggar ingen kan dölja dem, det finns enorma Glibc-buggar som påverkar kärnan och hundratals körbara filer. Skillnaden mellan Glibc och systemd är att den förra är en bas från vilken tusentals programvaruprojekt kan omvandlas till binära filer, medan systemd är en init, vars syfte är att vara en stabil, beprövad och praktiskt taget ofelbar bit. Inte bara det, Glibc måste anpassa sig till hundratals olika hårdvaruarkitekturer (CPU), till olika optimeringsflaggor och unika egenskaper hos CPU: n, till olika former av mjukvaruoptimering, ett mycket svårare och svårare arbete än det för systemd också. Jag ser inte riktigt något sätt att presentera en jämförelse mellan de två projekten i samma skala.

        Detsamma gäller GCC, GCC är en kompilator som förresten stöder många språk (totalt 13 räknar de inofficiella), och har egenskaper som liknar Glibc, stöder många arkitekturer (70 arkitekturer för version 4.9), binär optimering flaggor, CPU-optimeringsflaggor och många andra funktioner. Nu är de på samma svårighetsgrad, en kompilator med en init. Svaret är mer än uppenbart, från och med att systemd är i C, och mycket av GCC-koden finns i assembler eller så måste du använda assembler för att få saker att fungera i binär, något "svårt att göra".

        Vad är fel med GCC och Glibc? Säker. Till och med Linus har gett dem sin attack, men i GCC och Glibc har de något positivt att de i systemd ofta glömmas bort, och det vill säga ett fel rapporterat, ett fel sett, ett fel fixat.

    4.    Rolo sade

      - snälla förklara någon för mig: Varför en init ska ha kontroll över:
      nätverk (systemd-nätverkd),
      dns (systemd-networkd),
      m-dns (systemd-networkd), l
      ogs (journalförd),
      coredumps (systemd-coredump),
      debugs (systemd-coredump och journald),
      acpi (logind), escalation av privilegier (logind),
      ntp(systemd-timesyncd),
      dev (systemd tog all funktionalitet från udev),
      de / dev / random (slumpgenerator)
      TTY (systemd-tröstad)?

      Ett tema 100000 som upprepas och upprepas, vad du behöver säga är att systemd kan fungera utan dem, faktiskt i debian är de inte ens hälften av de du nämner

      likaså är det bara ett kännetecken för dess breda synsätt

      lennart: Tja systemd delar upp vad den har att göra i många olika komponenter (90+ binärer idag). Var och en kör med minst möjliga privilegier.
      Jag föreställer mig att detta inte är för mycket skillnad coreutils, som också har ett stort antal komponenter i ett paket. Och coreutils är förmodligen ett av de stora projekten som gör att Linux känns som ett UNIX-liknande operativsystem, eller hur?
      Men ja, systemd är mer komplex än sysvinit, ingen fråga. Under de senaste 40 åren av datorer har mycket förändrats, och många av dem kräver faktiskt en viss nivå av komplexitet för att hantera ... Det finns väldigt lite väg runt det.

      Eftersom du inte blir så kompromisslös med freebsd, vilket gör exakt samma sak men med sina verktyg och utan att låta andra användas, vilket inte är fallet med systemd.

      - Var det inte MÅNGA verktyg skapade för sådana ändamål att systemd nu lägger till sina egna, några med exklusiv åtkomst (journald case)?

      Jag kommer inte att förneka att journaltema sparar informationen i en binär är det svagaste att försvara, men det är inte världens ände, de kan sparas i klartext

      - Vilken logisk och acceptabel förklaring ger du mig att en init kan bryta kärnfelsökningen och cmdline?

      Mmmmmmmmmmm …………………. bryta kärnan ... 5000000 saker kan bryta kärnan

      - Lägg till den kontrollen över kdbus, nästa IPC som kommer att integreras i kärnan.

      Enligt lennart Detta har en positiv relation för utvecklare och systemd kommer att ge verktyg för att öppna dbus för administratörer, det kommer också att ge journal- och nätverksd-bussgränssnitt

      - Visst kommer de att säga till mig här: "Men du kan installera ett annat verktyg för att kontrollera allt detta." Och om det är sant, men många av dessa verktyg får bara en ström av data som kastas av systemd, som i fallet med syslog och rsyslog, ... det betyder bara att du har två verktyg som gör detsamma, och ett av dem är en Pandoras låda. (Berätta inte för mig att koden kan granskas, för jag bjuder in någon att "röka" journald-koden och dess ramverk med systemd och andra relaterade verktyg)

      här går vi in ​​i konspirationsteorin !!!!! det är mager fri programvara ingenting är dolt

      3.- Vilket systemd är inte bärbart? Det är en annan svag punkt. I BSD fungerar det inte bra, i BSD finns det inga Cgroups bland andra verktyg som systemd behöver köra. Men det är av systemd designskäl, inte för att det inte är bärbart. Tills BSD-kärnan inte uppfyller det minsta för att stödja den, kommer systemd inte att fungera på den plattformen och det är inte någons fel, bara att BSD inte har något intresse, inte heller Lennart.

      Det stämmer inte helt, bsd-utvecklarna gör något som liknar systemd, något som Lennart själv markerade i sitt g + -konto

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

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

      4.- Det systemd är inte monolitiskt eftersom det är uppdelat i 69 binärer. Ja ja, det här är diskutabelt. systemd har 69 binärer, som utför olika uppgifter, men dessa binärer skickar sin uppgiftsinformation till systemd, så om en misslyckas ökar chanserna att bryta systemet ganska dramatiskt. Detta är väldokumenterat, felrapporter finns i överflöd med problem som dessa och ännu enklare problem, dumt enkelt faktiskt. systemd kan delas in i hundratals binärer, men så länge din kärna har kontrollen fortsätter risken för ett avbrott och ökar, och om du inte tror mig, läs bugrapporterna och ha kul.

      Om du använder sysvinit och din TTY dev acpi ntp går sönder ditt system också, så inte skräck.

      Monolit är freebsd och du säger ingenting

      1.    anonym sade

        @rolo
        Lista mig nu vilka distros som tog systemd och skapade de 90 binärerna i separata paket, det skulle vara 91 paket med systemd.
        Och när jag installerar systemd ber det mig inte om något av de 90 paketen som beroenden.

        På allvar, och igen insisterar jag ... snälla skicka mig alternativen för –configure-help som jag vill göra 91 paket som sammanställs för hand med make.

        Det finns ingen värre blind än den som inte vill se ... pojkar det här är vatten och olja, det verkar som om det fortfarande finns envisa människor som inte ser verkligheten av vad redhat är efter.

      2.    yukiteru sade

        @rolo Jag vill att du installerar systemd och tar bort journald, systemd-udev och coredump, och använder alternativ som eudev och syslog direkt för att se om du kan.

        Den här kommentaren kunde inte få mig att skratta mer på allvar, jag dör. 😀

        Allvarligt nog gör de verkligen svårt att läsa lite, istället för att hålla fast med strålen i ögat.

      3.    yukiteru sade

        Dessutom glömmer ingen att Kay Sievers inte bara bröt kärnan cmdline, utan ville stänga den, trots allt "generisk är generisk".

    5.    Dariem sade

      Med andra ord, enligt dig, det faktum att två processer överför information gör dem så kopplade att det faktum att en misslyckas gör att den andra har stor sannolikhet för fel ... från vilken programvaruutvecklingsteori fick du det? Jag håller med @pamp att du talar från irrationell och partisk rädsla.

      Och din andra stora fråga, varför måste systemet kontrollera så många saker? Enkelt svar: för med sysvinit och alla andra initfördelar som nyligen introducerats i Linux-kärnan slösas bort, så länge ingen använder dem i användarutrymme, är de "förbannade" (som vi säger på Kuba ... Tja, bortkastade) utan någon använder jag dem och de ger mycket goda fördelar i effektiv användning av hårdvaruresurser (CPU, RAM, I / O, etc.) inklusive cgroups. Vad systemd gör är att sätta dessa bra funktioner Linux-kärnan till tjänst för användaren, men för det måste han vara den som startar demonerna.

      1.    yukiteru sade

        Jag tror att du läste och analyserade fel (att analysera är viktigt) eller att du inte ens gav dig själv en chans att göra det. Att två processer skickar information är inte en anledning för ett system att bryta, men när du har binärer med dynamisk åtgärd som nätverkskontroll, loggar eller coredump, vidarebefordrar information direkt till init kan saker gå fel och de kommer att gå fel, för om några av binärfilerna går sönder är chansen att bryta resten mycket högre, och det är ganska realistiskt, och det har hänt, kärnan cmdline kraschade nyligen, acpi-problemen som Nvidia devs hade tack vare systemd-212, allt som är ett prov på vad jag säger.

      2.    anonym sade

        @Dariem
        Om du inte kan kompilera var och en av dessa binärer i enskilda paket tvingar du att eftersom du vill ha en installerad måste du installera alla, när du installerar dem alla visar det sig att du kliver på andra paket som inte kan installeras eftersom delar av systemd upptar dessa platser.
        Vilken mening är det att dela upp en stor körbar i flera mindre körbara filer om du i slutet inte har ett paket för var och en som låter dig installera dem individuellt.
        Jag återvänder för att göra en allmän begäran till alla avancerade systemanvändare, för att berätta för mig hur man sammanställer de 90 modulerna och skapar 90 paket som om jag känner för att installera dem och annars använder jag de program jag har använt.
        Mycket dålig mjölk allt detta ... det verkar som folk i systemd tror att alla GNU / Linux-användare är dårar.
        För ordens skull använder jag gentoo-testning och för några månader sedan hade jag bytt till systemd och jag kunde inte med journald, vilket fick mig att återgå till openrc snabbare än det tog att byta till systemd.
        För att fortsätta se hur det går med systemd har jag archlinux på en bärbar dator som snart kommer att släppas till gentoo .... Visst stabilt.

      3.    yukiteru sade

        @anonym, jag vill bara se hur TTY-frågan kommer att utvecklas i Linux. När CONFIG_VT-koden kommer ut, för att dela VT i två väldifferentierade delar (kernelspace och userpace) behöver vi något verktyg för att styra VTs från userpace och där system-tröst kan spela i att vara ett starkt beroende som drar resten av distros till behovet av att behöva installera systemd-komponenterna, bara för att göra det möjligt för systemet att fungera. Det jag säger är inte en överdrift, det är en mycket, mycket stor möjlighet och verkligen oroande. Det finns andra projekt, som KMSCon, men om de flesta stationära datorer och distributioner går till systemd kan saker som KMSCon dö snabbare än många tror.

      4.    anonym sade

        @Yukiteru 3 december, 2014 8:49
        Jag är inte rädd för det, Mr. Linus kommer inte att ta bort standardalternativen från en version till en annan, han kommer att ställa in det nya systemet som NYTT och låta dig välja mellan det gamla och det nya.
        När det gäller användarutrymmets del kan du skapa ett paket som gör det självständigt, om systemd gör det, varför kunde inte ytterligare 50 till? Vad mer, de olika sätten att göra det gör att de olika terminalerna antar olika sätt alla med USEs för att aktivera och inaktivera som vi är vana vid.
        Detsamma gäller kdbus, att Linus erkänner det i 3.19 som han säger, det betyder inte att man måste ha det aktivt ja eller ja.
        Jag är väldigt nöjd med openbox + compton, skrivborden för mig kan försvinna så att de inte kommer att påverka mig åtminstone.

      5.    yukiteru sade

        @anonym är frågan att ta bort CONFIG_VT är något som i slutändan blir totalt (från vad jag har läst), det vill säga i kärnan kommer bara primitiverna att finnas kvar, medan resten av verktygen kommer att finnas i användarutrymmet, detta är inte illa, tvärtom tar det bort mycket gammal kod från kärnan, gör det lättare att underhålla och mycket mer konfigurerbar (fullständigt KMS / DRM-stöd för konsolen). Visst i början kommer det att finnas båda systemen, men på lång sikt (15-20 versioner) kommer det eventuellt att lämna kärnan, eller ännu tidigare, många verktyg stöder inte längre sådan kod till förmån för nyare och bättre kod som stöds.

        Nu säger du att om systemd gör det, för 50 fler kan inte göra det (jag föreställer mig 50 fler applikationer). Om vi ​​ser de starka beroenden hos KMSCon (det äldsta projektet i denna mening) är de libudev (kod som snart kommer att kopplas till systemd, det kommer inte att stödjas och kommer i konflikt med systemd om det fungerar på egen hand), libdrm , libxkbcommon, libtsm och systemd för att hantera multi-seat, så när du ser detta inser du hur saker och ting tar form när de tar för sig själva många verktyg som krävs för att ett GNU / Linux OS ska fungera utan problem.

      6.    anonym sade

        @Yukiteru 3 december, 2014 9:46
        Här i gentoo är libudev en virtuell pekande på sys-fs / eudev, så gentoo-folket kommer att ta hand om att ändra eudev för att följa det API som dikteras av det nya kärnsystemet.
        Så jag tror att andra distributioner än systemd (hej devuan) kommer att använda om eller om eudev.
        Vad som hände med den ursprungliga udev kommer att hända, systemd slog upp det, men här är kärnan den som diktats av API för att gränssnitt med konsoler med DRM / KMS ... Jag ville redan se en urxvt med detta ... hehe
        Det jag accepterar är att den som använder systemd inte kommer att ha möjlighet att ändra någonting ... full och hård införande och som jag sa tidigare ... att gråta till kyrkogården.

      7.    yukiteru sade

        @ anonym verkligen vad du säger är den andra möjligheten, eudev kommer att ta större styrka i detta avseende och kommer att hålla alternativen öppna för att välja olika verktyg.

        PS: Som du säger skulle det vara intressant att se hur VT: er tar fördelarna med KMS / DRM tillsammans med fbdev 😀

      8.    Dariem sade

        Du har exakt upprepat konceptet att jag kritiserade dig, för jag pratade inte alls om systemet, jag talade om kommunikation mellan processer, och jag upprepar igen, var får du det för att två processer kommunicerar, en död innebär att den andra har gott om möjligheter att dö? Förklara för mig hur två processer, som finns i separata minnesutrymmen, kan ömsesidigt påverka varandras interna beteende. Låt oss se om jag förklarar mig själv, ur en av dessa processers synvinkel är det bara att komma åt en IPC-mekanism (oavsett vad det är som definierades för att kommunicera till systemd-processerna). Om programmeraren var så dålig att inte inkludera kod som kan hantera oväntad in- och utmatning, är det något annat, men det har ingenting att göra med en process som påverkar internt i en annan. Om systemd-networkd kraschar behöver den inte döda journald eller systemd, som med den gamla sysvinit, det faktum att inetd-kraschar inte borde påverka det, de är separata processer.

      9.    yukiteru sade

        @dariem förklarade på ett enkelt sätt för att se om du fick idén:

        Vad du säger är verkligen det beteende som alltid förväntas av modulära program och processer. Modularitet implementerades för det ändamålet, att separera två processer och att de upptar sina egna minnesutrymmen, och att de kommunicerar på något sätt (IPC, etc.), så att om något går fel, händer inget dåligt. Och kan fortsätta att fungera utan avbrott. En teori som säkert har haft stort stöd på grund av dess potential och den enorma marginal tillförlitlighet som den har gett för aktuell databehandling. Detta är inte alltid sant (livet är inte alltid vackert), och jag tror att du säkert har blivit ett offer för dessa händelser vid ett eller annat tillfälle (detta gäller säkert för alla oavsett operativsystem du använder), och jag kommer att ge ett par exempel.

        Den första går med Xorg (som är en modulär process precis som systemd), som ibland blir galen med en drivrutin och bara kraschar och lämnar dig utan grafik, medan resten av systemet fortsätter att fungera som förväntat (Salig modularitet 😀). Så långt så bra fungerar vår teori att modulära processer inte behöver bryta systemet bra. Men (det finns alltid några men) ibland ger Xorg något mer än galenskap och av någon konstig anledning (som kan sträcka sig från muskontroll till grafikdrivrutin) kraschar inte bara Xorg, men det ger dig också den vackraste av kärnpanikerna ( och ett graffiti på bildskärmen som Picasso) som du kan föreställa dig, och sedan inser du att oavsett hur modulärt det är, om en process interkommunikerar och utbyter information / data med en annan, och något går fel i en av dem, och för av någon anledning kan felet inte hanteras korrekt, chansen att de berörda processerna påverkas ökar, för det enkla faktum att uppgifterna är felaktiga eller helt enkelt korrupta, och då kommer det katastrofen.

        Om du tror att detta inte kan hända, lämnar jag några felrapporter (en är min i Debian och har ett par fotografier) ​​av ett gammalt fel som finns i Xorg, mesa, nouveau och kärnans drm / kms-förare, bearbetar det trots springa ** separat och vara modulära **, tillsammans går de inte så bra, åtminstone inte under omständigheterna.

        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 andra exemplet jag ska ge dig med systemd. Vår gamla Sysvinit hade en särdrag att trots att den var gammal, var den väldigt pålitlig, till den punkten att om din / etc / fstab hade en partitionsinmatning (inte viktigt för systemet, förstå a / mnt / Disk160GB) och det är det inte kunde ' för att vara monterad av någon anledning hoppades fästet helt enkelt över, gav dig ett varningsmeddelande och fortsatte med startprocessen. Nu är systemd en annan historia, trots dess modularitet, om du har en post i / etc / fstab och systemd av någon anledning ser att det är omöjligt att montera det, väntar det inte bara på att partitionen ska vara tillgänglig (det normala programmerade beteendet ) för montering, men om tiden är slut stoppas ditt system och du kan inte göra mer än att gå in i återställningsläge och ta bort den raden från / etc / fstab, något misslyckas faktiskt. Den där lilla detaljen inte mer under automatiseringen i start och hela processen slutar, först (systemd-) var den lilla detalj fulare, eftersom dumpningen bara dykt upp och du var tvungen att starta om. Någon som har gått igenom detaljerna berättar för dig.

        Ett annat exempel jag kan ge är coredumpd i systemd. coredumpd skickar som standard all sin information till journald för att den senare ska skriva den fångade informationen till hårddisken, hittills så bra, vi använder systemd-modulerna till vår fördel. Men det händer ibland, när coredumps är väldigt stora, bara så stora, att de kan ta upp flera GB, och i färd med att överföra information från coredump till journald och sedan till disk, händer konstiga saker som Xorg slutar fungera och till och med kärnan får panik. Det händer inte bara med system naturligtvis, men hur det är utformat ökar felfaktorn och skapar andra obehagliga detaljer (bland annat ökad minneskonsumtion, loggkorruption, ofullständiga dumpningar), som har varit tvungen att arbeta Med en KDE-coredump har du har säkert gått igenom flera avsnitt som dessa, och du har förstått vikten av att ha synkroniseringsalternativet i / etc / fstab för din dumpningspartition, och du kommer säkert att hata det faktum att du inte kan använda något annat alternativ för att hantera dumpningarna, om du har installerat system. Ett exempel på vad som kan hända med systemd-coredumpd.

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

        Nu, för att avsluta:

        Ska de inte vara modulära program och processer? Ja, de är modulära. Kärnan är den enda monolitiska saken jag har pratat om här, men den accepterar också moduler (LKM), så det skulle vara en slags hybridkärna även om dess basdesignform inte är utformad i den typen av struktur, och det gör den till en lite instabil under vissa omständigheter.

        Den modulariteten borde inte tillåta mig att hindra mina processer och system från att krascha om något går fel? Det är sant, modularitet är ett mått som är utformat för att uppnå en hög grad av stabilitet och tillförlitlighet, men det är inte ett 100% ofelbart mått, för om något kan gå fel kommer det helt enkelt att gå fel, oavsett hur modulärt det är verklighet.

        Vilket systemd måste ha kontroll över allt för att möjliggöra användningen av cgroups och andra alternativ som läggs till i kärnan? Helt falskt. Det är inte nödvändigt alls, systemd kunde ha lämnats med ett gränssnitt för att styra start och tilldelning av cgroups till de processer och demoner som kommer att finnas i systemet, utan att behöva ta över antalet tjänster det nu har, och bästa exemplet på det är; att OpenRC också kan använda cgroups och det är inte av den anledningen så invadera att utföra den uppgiften.

        Vad är jag partisk och rädd när jag pratar om systemd? Jag har ingen aning om var han kommer ifrån, för som ni ser mitt svar är jag inte rädd för det, jag pratar bara om aspekter som jag inte tycker om systemd och redan, utan att förlita mig på yttranden från tredje part.

        Slutligen säger du att: "Om programmeraren var så dålig att inte inkludera kod som kan hantera oväntad in- och utdata, är det något annat ..."

        Visst att säga att programmeraren för att inte inkludera en kod som hanterar ALLA möjliga sätt på vilket hans program kan brytas på grund av felaktig datainmatning, är DÅLIG, det verkar för mig en upprördhet. Oavsett hur bra en programmerare han är, en person kan inte designa ett ofelbart och felsäkert program, kommer det ALLTID att vara ett fel, vilket på ett eller annat sätt kommer att dyka upp, och när det gör det kommer det att vara tack vare ett slumpmässigt fel under dess användning, av en hackare eller smällare som utnyttjar en sårbarhet, genom en kodgranskning och granskning eller på annat sätt som programmeraren kan lita på. Bättre att mäta orden innan du säger en sådan sak.

        Hälsningar.

      10.    Dariem sade

        Exemplet du ger om Xorg är minst lämpligt eftersom alla som har genomgått övergången till KMS / DRM vet att problemet orsakas av buggar i kärnmodulerna för att kontrollera KMS som tillhandahålls av utvecklarna av Xorg-drivrutinerna. Ett fel i en KMS-modul är detsamma som en kärnpanik, det har inget att göra med kommunikation mellan processer, för i så fall är det Xorg som gör ett systemanrop (syscall) så att kärnan ändrar skärmläge, det vill säga där är bara en process involverad (Xorg) som kallar kärnan, inget att göra med det vi har att göra med här.

        Det nuvarande beteendet hos systemd när man inte hittar monteringspunkten är irrelevant oavsett det faktum att det är en funktion som någon kanske inte gillar, som löses genom att be att de stöder det andra beteendet, att ignorera det misslyckade fästet. Coredumpen som inträffade tidigare kan bero på olika orsaker som bara kunde spekuleras, men det faktum att körningen inte fortsatte kan bero på ett önskat beteende, eftersom du säger att den måste startas om, inte att det fanns en kärna panik eller en automatisk omstart. Eftersom jag inte har gått igenom det kan jag inte ge ett yttrande.

        När det gäller problemet som du satte med systemd-coredumpd och länken till felrapporten, tyder allt på att detta problem i Arch Linux berodde på komprimeringen som de aktiverade systemd när de kompilerade det för den distributionen. Det ser mer ut som ett problem med kompressionsalgoritmen än med systemd själv. Operativsystemet kraschar inte, snarare kompressionsalgoritmen som används för att lagra coredumps verkar tömma systemet och det är fel från Arch Linux-utvecklarna som kompilerade systemd. Systemd har dock inställningar för att begränsa resursförbrukningen och aktivera / inaktivera fångsten av alla kärnmumpar som rapporterats av kärnan. Kanske bör Arch-underhållare av systemd och de som använder KDE ta en titt på dem.

        Du säger att OpenRC också använder cgroups utan att vara invasiva. Problemet är detta: hur känner OpenRC igen namnet på daemon-körbara filer för att veta exakt vilken resursallokering som är mest lämplig? Jag är inte riktigt säker på om detta är en av anledningarna till att systemd tar hand om så många saker och ger körbara filer ett välkänt namn, men jag misstänker att saken går så. Dessutom eliminerar det bördan att ha streck i mitten för att köra var och en av dessa tjänster genom att direkt anropa körbarheten.

        Jag kommer inte att förneka att systemd kan ha många buggar, men därifrån för att tillskriva dem alla hur det är tänkt, tror jag inte det. När det gäller sysvinit var det superstabilt, en mogen mjukvara, systemd har precis börjat.

  12.   Raphael Mardechai sade

    Hur de spränger bollar med systemD, xD Om du hatar det så mycket, skapa din egen distro, vilket är vad fri programvara är för é_é

    1.    Alexander den stora sade

      Det handlar inte om hat, det handlar om att försvara din gemenskap.
      Förresten om det finns distributioner Oberoende "underground":
      http://gutl.jovenclub.cu/neonatox-un-linux-iconoclasta
      Respekter

  13.   wacos sade

    för att jämföra allt med microsoft att det beter sig som windows .. om saker fungerar bra och det är för utveckling och utveckling av linux vad är problemet ... varje projekt i början kan ha ändringsfel om programvaran etc. var perfekt, Vi är mänskliga, men det är därför vi har misstag.

    att om systemd misslyckas, kommer systemet att krascha ... och om kärnan, xorg, grub misslyckas ... det finns människor som uppdaterar kärnan på sin dator eller bärbara dator, förlorar systemet ... då för insisteringen på perfektion av något ...

    som om något system som har kommit ut inte hade haft fel buggar eller något i början eller ens i sin mognad har fel

  14.   lf sade

    Systemd infördes som en standard med smutsigt spel, det är ett obligatoriskt beroende för många paket eftersom många program absorberades av systemd antingen för att de behöll dem eller för att de långsamt eliminerade dem eftersom de inte längre var relevanta eftersom systemd redan tillhandahöll något liknande.
    Detta begränsar valfriheten, det vill säga distros kan inte välja att INTE använda systemd, de kan försöka motstå som gentoo, men det är mer en tillfällig lösning på systemd, openrc är bara en sysv-supportadministratör för init och i distro inskrifter , systemd ger mer funktionalitet än openrc och har ny funktion varje dag. Den nya programvaran stöder systemd och kräver att implementera något liknande som slutar göra de andra inits mer komplexa och mer lik systemd vilket är vad du inte vill ha.
    Systemd gör många saker jämfört med den gamla init som helt enkelt läser ett par rader från / etc / inittab och sedan laddar var och en av inskrifterna och deras konfigurationer enligt körnivån. Det gamla tillvägagångssättet var mycket enklare och mer oberoende. Vi befinner oss i ett övergångsskede mot en ny era av homogenitet, det finns ingen lösning, hur det råder är ostoppbart.
    Om några år kommer det att vara praktiskt taget ingen skillnad mellan att använda debian, använda arch eller fedora, identiteten för varje distro kommer att gå förlorad om vi fortsätter så här och systemd kommer att bli mer påträngande varje dag att det till och med kommer att bli en del av systemnamnet (systemd / gnu / linux)

    1.    MSX sade

      LOL

      Att gråta till kyrkan>: D

  15.   MSX sade

    Vad säger Don KZKG, jag lämnar dig detta: https://blog.desdelinux.net/systemd-vs-inteligencia/#comment-127648

    1.    lf sade

      Problemet är att du är argentinsk (det är jag också) men sättet att uttrycka sig att de flesta argentinska Linux-användare jag läser är verkligen oroande, även om det också sägs att världen av fri programvara lockar vissa människor. Det jag räddar är att du inte antar att du är argentinsk, men det visar tyvärr ligor.

    2.    x11tete11x sade

      uyyuyy .. pojken föll med tungt artilleri ..

    3.    WACOS sade

      stark kommentar !!

    4.    rawBasic sade

      Juju .. ..pochoclos .. xD

  16.   Tito sade

    Det följer av den här artikeln att allt de gör är att "införa" ett system. Jag går inte in för att bedöma om det är bättre (vilket det inte är) eller värre. Vad jag säger, upprepar jag, jag betonar och betonar, är att jag egentligen inte vill ha något påtvingat mig.
    Fraser som: "Vi använder dem bara inte för startprocessen, för vi tror att de inte är det bästa verktyget för det specifika syftet."
    Och vem ska du berätta för mig om jag vill använda det här eller det här verktyget?
    Där var. Jag använder det bara inte, punkt, och även om jag kanske inte gör det kommer jag inte.
    Signerad. En taliban.
    (Det är att jag roar mig av upptåg)

  17.   kuktos sade

    ofta huvudvärk med det ämnet !!!! X_X

  18.   Tabris sade

    Jag hanterade servrar med Centos 6 och att gå till 7 med systemd kostade mig ingenting, gråter inte, livet fortsätter.

  19.   Jokar sade

    Ursäkta mig, men jag läser många saker som påminner mig om den klassiska diskussionen "Windows-server - Certified Man VS Linux-server - OpenSource Man".

    1: a - om du tvingar ett fel är det normalt att det misslyckas. Var och en av de videor som jag har sett är tvingade fel. Det är som om jag gör ett program som matar in nyckelord i syslog-loggen och samtidigt försöker jag köra ett grep-baserat skript för att extrahera information från loggen ... naturligtvis kommer det att misslyckas, jag har orsakat det.

    Det är som att hälla socker i en dieselmotor och säga "Titta ... bensin är bättre !!!" eller som Windows gör, skriv en konfigurationsfil fel och klagar över att demonen inte börjar säga "med Windows så händer det inte."

    2: a - Det systemd innehåller många saker som du inte får använda? Tja, vad är problemet? Det är att det är samma tomma argument som Windows använder mot Linux-sådana ... "Varför vill jag att en ren text ska lägga tusen och ett alternativ när du inte ska använda dem?"

    Jag hör fortfarande IBM-killarna med sina monilitiska program som skäller för flera år sedan om mysql när jag läste några saker. Jag tackar och applåderar mångfalden i GNU / Linux och dess community. Om du ger mig 50 sätt att göra något väljer jag vid varje ögonblick det som fungerar bäst för mig eller som passar vad jag behöver. Ser du verkligen ett problem i det här?

    Tredje - Av konversationsnivån drar jag slutsatsen att du har en tillräcklig nivå för att arbeta med någon distribution eller skapa din egen och behålla den själv. Varför vill du lägga systemd och ta bort saker från det? Är det inte lättare att fortsätta med din init eller openRC?

    Till de människor som har bett mig att lära dem grunderna i linux säger jag alltid samma sak ... GNU / LINUX är inte WINDOWS, försök inte göra samma saker eller tänk som om det vore. Varför antar du att sistemd är detsamma som initd eller att det fungerar på samma sätt? Är det inte lättare att assimilera driften av systemd och använda dess potential än att försöka göra funktioner som init eller OpenRC? Det är normalt att du inte gillar det.

    4: e - Vad är fel med komplexiteten? Visst kommer du fortfarande ihåg när du gav linjär programmering och att du säkert någon gång sa ... «Och varför vill jag lära mig att arbeta med objekt om jag nu kan göra allt och annat de låter mig använda gå till?» ... (Facepalm ett par månader senare är bra om xD)

    Låt oss vara tydliga. Den nuvarande init (och jag inkluderar systemd) har många brister som bara kan fyllas genom att lägga till komplexitet. Det finns ingen annan, för att ett sammankopplat system ska växa måste det växa i komplexitet med risken att ha någon svag del, men det är bättre än att stanna.

    Det tar en lång väg att gå och om ... sistemd inte är lösningen på allt. Men varken bor hos SysVinit.

    1.    skämt sade

      PS: Lägg märke till ironin att jag har använt min kollegas PC "Jag klamrar mig till windows-server-försvarare" så att han kan läsa den förresten. xD

      Bara en sak, till försvararna av andra INITs som ger tekniska data och länkar ... CHAPO !!! Jag älskar att se argument och data så här. Bara en anteckning, uppgifterna före oktober 2014 är bara historiska.

      Många saker som diskuteras har redan fixats och många testbäddar som publicerades 2013 har redan granskats.

  20.   SynFlagga sade

    @rolo

    Om det är sant, om du såg videon, som du INTE gjorde, ser du att loggen är 8 MB, ingenting mer och så vidare och allt blir förstört, förresten, kan du skicka utgången från journald till syslog i vanlig text? Ja, men ändå om du rör vid loggarna som skapats av journald, så händer det, systemet hänger och, förståeligt nog, låt oss se, journal hänger på PID1 tillsammans med saker så komplexa som systemd, det misslyckas, det verkar som om det inte har en del av koden som inte tillåter redigering av något annat än samma PID i journald såväl som den inte har förmågan att fortsätta skriva bortom loggen är skadad, vilket visar att förutom att tänka i Windows-läge är LP dåligt programmerare.

    Berätta inte för mig att det bara kommer att vara i centos, den mest stabila versionen av distro som använder systemd, klon av RHEL7, och jag rapporterar inte eller planerar att rapportera felet.

    Sanningen är att ju mer jag läser pro systemd-kommentarerna inser jag att de verkligen är som en religion, eller att du är för eller att du är fienden, men av dessa ISIL-religioner, de av den islamiska staten, helt extremist, faktiskt vet jag av erfarenhet, systemd-älskare, de tror det, eller om du är med dem eller så är du fienden. Det är vad Lennart främjar med sin arrogans och snälla snälla inte knulla mig med Linus som stöder honom, systemd var inte detta, DET VAR INTE, jag använde systemd så snart det kom ut i Fedora 15 och det var bara en snabbare init, det ersatte inte GNU / Linux-modulariteten.

    Om jag dödar rsyslog, förstör loggarna eller ersätter den med en ritning, inget annat, bara att jag har slut på loggen, ingenting hänger, systemet påverkas inte.

    @Rafael Mardojai

    Det är vad Devuan gör, det är vad Void Linux gjorde och andra som håller sig borta från systemd.

    @Yukiteru

    Visst läser ingen dig, som de säger till mig talibanerna, de läser dig inte för att du använder windows eller om du kommenterade det och för att jag tror att få av systemälskarna förstår den tekniska delen av det du säger och där ligger problemet.

    ======

    Sanningen är att jag fortfarande tror att en person som var känd redan 2006 hade rätt i något:

    "Jag vill inte att folk ska använda Linux eller att veta det, dessa Ubuntu-killar har mina bollar fulla"

    Jag- "Varför?"

    "När något blir känt och för massorna, skit det, det knullar upp, och det finns prover i massor av det"

    Jag- "som vilka?"

    "Se vad som hände med Debian, nu har han en dum son som heter Ubuntu och kom ihåg att om några år kommer vi att ha" hackare "och" nördar "som suger Ubuntu och de kommer inte att veta hur man skiljer Ext3 från NTFS"

    Något stämde…. systemd triumferar bland dem som vet, som Allan McRae säger, för han bryr sig inte hur hans maskin startar, för honom är det, knapp, magi och jag har en uppmaning. Bland dem som inte är intresserade av mer än att "arbeta" med fina funktioner, totalt, för serveranvändning LFS eller Gentoo eller BSD verkligen och sedan de som älskar det eftersom det slår på sin dator snabbare med färgade lampor, vackra ljud och hasardspel , men de vet inte vad en syscall är.

    1.    yukiteru sade

      @SynFlag om de inte läser det är det genom beslut av sig själva, som för operativsystemet jag använder, om jag är på mitt arbete och kommenterar från en Windows-dator är det för att det är det enda jag har till hands, förutom servern det är i Debian Wheezy och uppenbarligen från servern kan jag inte kommentera här.

      Till och med hemma har jag tvingats använda min systers dator eftersom min dator har dött (MB och strömkällan konspirerade mot mig), och ändå när jag har tid monterar jag en LiveCD och använder Sabayon (med OpenRC) för att kommentera här, som jag gör precis när jag skriver dessa ord.

      Om de säger till mig eller tror att jag är en anti-system taliban så spelar det ingen roll för mig. Som jag sa har jag använt systemd och jag vet att det haltar, inte bara det, jag läser vanligtvis systemd-listan mycket för att ta reda på saker som kommer i nya versioner, och för att vara medveten om de förändringar som görs och de diskussioner som äger rum där. Nu om någon systemd-älskare förstår den tekniska aspekten av det jag pratar om och jag lägger i mina länkar (länkar till systemd git repo mestadels), och ändå inte kan se verkligheten, det låter mig bara tänka att jag säljer det i deras ögon och extremismen i deras sätt att se / tänka / känna / älska / förhärliga / berömma / dyrka systemd är så stor att det spelar ingen roll om ens Linus själv sparkar **** ur systemd, de kommer vara fortfarande förankrade i sina idéer om att de är korrekta.

  21.   Hesekiel sade

    Hej! Jag är inte en mycket expert, och jag skulle vilja veta vad det här "systemd" är för och varför talas det så mycket om, vad är problemet och vilket alternativ finns det? tack

  22.   Tito sade

    SynFlagskommentaren! Jag är från "geeks", "geeks" och "pro linuxeros" till samma sak.
    Och det är framtiden som väntar oss; Ubuntu även i soppan; Linux-bärbara datorer för att bara komma åt Steam och spela det senaste heta spelet. Och legioner av små nördar som inte vet vad podden handlar om.
    Efterskrift: systemds bakgrundskoncept suger.

  23.   Hannibal Smith sade

    ADK- och forumknapparna syns inte på huvudsidan

  24.   Dariem sade

    Så enligt @SynFlag nu är alla som inte är anti-systemd en n00b, extremistisk religiös fanatiker och pesten som korrumperar GNU / Linux. Med en så smal åsikt som denna vet jag inte om det här ämnet är värt att diskutera. Bättre att låta vattnet rinna och på lång sikt kommer vad som måste hända att hända.

    1.    Rolo sade

      Det är sant, det kommer en punkt som inte kan diskuteras längre. bara tiden kommer att berätta om sytemd kommer att vara något positivt för världen av fri programvara eller inte.

      Det ger mig också idén att om den här debianbaserade distributionen som inte kommer att använda systemd blir verklighet, kommer det att hjälpa till att lugna andarna hos dem som inte vill veta något om systemd.

      som när gnome 3 uppträdde och ett enormt motstånd byggdes, tills "gaffel" kanel och enhet uppträdde så att du kunde fortsätta använda gnome-applikationerna på ett skrivbord med fler konfigurationer och en design mer tänkt för datorn och inte så mycket för beröring

      1.    Xiep sade

        Kanske det, Rolo (utseendet till Devuan), kan vara en konsensuspunkt. Jag tror att vi alla behöver det för att innehålla en polariserad och krånglig diskussionsmiljö. Devuan kommer att vara ett utrymme för skapande och kontinuitet av ett sätt att göra och som kommer att hjälpa till att lugna andarna. Processen som vi har bott i Debian har varit smärtsam, men vi måste möta situationen, det finns inget annat val än att acceptera separationen. Det här blir lite som skilsmässor. Denna gaffel kan vara ett transkript av ett fredsavtal och en punkt och del. Det fanns naturligtvis alternativ, Slackware, Gentoo, Funtoo, Crux, PCLinux OS, nu Manjaro (för att nämna några) ... men "deb" -scenen krävde ett alternativ utan systemd. Det verkar tydligt att ingen kommer att övertyga någon, argumenten ligger på bordet och det finns ingen enighet (trots att systemd har goda idéer och de faror som denna programvara medför är uppenbara). Det är dags att gafflar och få användaren frihet (för det här handlar om fri programvara, eller hur?).

        En faktor som påverkar processen har varit känslan av "besvikelse" hos vissa av oss som litar på Debian. Det är därför Devuan presenteras som en gaffel och inte som ett derivat. Det finns spänning eftersom ingen gillar vad som har hänt; varken pro-systemd (därmed vissa rasande attacker som försöker ärekränka) eller antisystemd (som har valt gaffeln). I miljön finns det «hur mycket talang kan vi förlora?», Både å ena sidan och å andra sidan.

        Alla Debian-användare tittar på distro på ett "visst sätt" (detta kan även tillämpas på andra distributioner). Det finns de som beundrar dess tekniska kvalitet, andra dess sociala kontrakt, dess inflytande i Linuxvärlden, respekten den har uppnått genom åren, dess stabilitet i kritiska produktionsmiljöer ... I vissa användare har denna uppfattning förändrats med besvikelse. . Besvikelse, besvikelse, kall det vad du vill. Därifrån till separationen är det bara ett litet steg.

        Debians skilsmässa liknar vad som hände med NetBSD och OpenBSD. Även om tiden kommer att visa. Jag ser många förväntningar i gaffeln och det får mig att tänka att det inte blir en flyktig och steril distribution. Just idag var det en medlem av gnome-teamet som kommenterade Devuans e-postlista (även om han har gjort det obekvämt), detta, enligt min mening, antyder att Devuan genererar intresse och vill, på något sätt, för dialog.

        Hur som helst, bra helg.

      2.    SynFlagga sade

        @rolo

        Att säga att videon kan luras eller att mjukvaran är en total misstag och förolämpning, i mitt PU ** liv lurade jag något för att skapa en myt, aldrig, jag skryter av att ha sett det misslyckandet med mina medel, inte av mina tricks. De går alla till **** än ***** och jag tänker inte lägga mer på systemdebatter eftersom det är helt för fjädrarna, ingen vill förstå någonting och det är som ett nedflykt, som, Jag hatar, för allt är det genom tros dogma. Var nöjd med systemd.

      3.    Rolo sade

        @SynFlag våld ljuger

        Vad den här videon visar är falskheten i påståendet att om en av systemd-modulerna förstörs, orsakar den att systemd kraschar, eftersom uppenbarligen från det som din video visar som inte hände, xddddd och förresten journal körs som root, Därför skulle jag inte oroa mig för systemd utan snarare för din dators säkerhet om en tredje part kommer in och skadar skadligt journaljournalen. xdddddd. Slutligen i ämnet för videon, replikera det som visas redigering med nano filen /var/log/journal/24f02f5b2b16758b820ea6a751ed6efb/system.journal och när du startar om kommer du att det finns ett nytt system.journal och ett system @@ 24f02f5b2b16758 @ @ 820f6f751bXNUMXbXNUMX. Journal som är korrupt binär.

        Det vill säga, journal inser att filen är korrupt, så den byter inte namn på den och skapar en ny igen, jag ser inte vad problemet är i det ?, Samma som om filen system.journal raderas, journal returnerar den för att skapa.

        Jag undrar vad som skulle hända om jag förstörde en vanlig loggfil med en hexadecimal redigerare, säkert tills du inser att filen var skadad, skulle all information förstöras Oo

        Låt oss prata lite om journal, som är en av de vanligaste kritikerna av systemd.
        journal är en mycket viktig komponent i systemd, som fångar Syslog-meddelanden, kärnloggmeddelanden, RAM och initiala startmeddelanden, liksom meddelanden skrivna i STDOUT / TDERR och gör all denna information tillgänglig för användaren.

        Men viktigast av allt, journal kan användas parallellt eller som en ersättning för en traditionell syslog-demon, som rsyslog eller syslog-ng, därför kan en försiktig sysadmin ha rsyslog eller syslog-ng som ett andra frågeverktyg, förutom att omvandla journal registreras i klartext om binärfiltret skadas

        Ett annat viktigt faktum om journal är att om mappen / var / log / journal inte skapas, sparas information bara tillfälligt, vilket går förlorat vid varje omstart.
        till exempel när jag angav systemd i debian var loggens logg inte aktiv så jag var tvungen att manuellt skapa journalmappen

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

  25.   anonym sade

    De som kan engelska kan inte missa samtalen som äger rum mellan utvecklarna av devuan, jaromil dimkr max2344, bland annat på freenode IRC-kanalen #devuan.
    Jättekul att läsa undersökningarna av systemkoden eftersom de har spridit den avsiktligt för att infektera (skapa onödiga beroenden).

  26.   sircacaroto sade

    Systemd irriterar mig ... rakt fram ... det är svårt. Liten dokumentation eller den jävla smala kör bara KDM eller gdm och i ett ljust system vill jag ha smal lxdm stöder inte det eller kompilerar det ... .. Allvarligt att jag redan innan ... jag var nöjd med att de borde. Sanningen är att jag började använda openrc som de säger i gentoo och det hjälpte ... Mycket

  27.   synflagg sade

    @rolo

    Du är en oförskämd och nyhetsbristare att säga det. Det är den värsta förolämpningen att du säger till mig att jag ljuger eller förfalskar data, det äcklar mig verkligen för att försvara något du attackerar människor som gör allvarliga poC som jag. Loggen är skadad, systemet kraschar, omstart av tjänsten fungerar inte så det finns inget annat val än att starta om maskinen, vilket inte är det bästa i en hackad server, du kommer att säga till mig att om säkerheten komprometteras, det bästa är att starta om eller installera om igen och det är det enda jag borde oroa mig för eftersom systemet säger att ursäkta sig och inte göra en het analys av VAD HÄNDES? för att komma till den punkten? Uppenbarligen är du ytterligare en produkt av det nya sysadminen om du kommer till det som höjdes med ubuntu och har säkerheten för en DOS 5.0 på din dator, så vad du säger jag tar det som vem det kommer ifrån, det stör mig att du tvivel också Den som förfalskar är du, svarade du på samma operativsystem med uppdateringarna den dagen? Säkert inte, så prova en annan lögnare. Vilken brist på kapacitet du har, gå till jobbet som taxichaufför för mer än att jag tvivlar på att det kommer att ge dig, sluta spela med linux och fortsätt titta pr0n

    1.    Rolo sade

      Låt oss se duva (synflag), pappa kommer att visa dig hur du får tidskriften att fortsätta arbeta efter att vår binära journalloggfil har skadats av någon anledning utan att du behöver starta om datorn.

      I det här exemplet börjar vi från en basinstallation av debian 8 jessie.

      Som standard kommer systemd-journal.service med funktionen "lagring = automatisk", så för att ha en bestående registrering av loggarna är det nödvändigt att skapa filen i / var / log / journal / tidigare.

      # mkdir -p / var / log / journal /

      För att journal ska kunna börja skriva loggarna behöver du INTE starta om datorn, bara gör:

      # systemctl ladda om systemd-journal.service
      o
      # systemctl force-reload systemd-journal.service

      ### nu ska vi simulera att tidningens binära logg är skadad ###

      # cd / var / log / journal
      #ls
      24f02f5b2b19808b820ea0a980ed6efb
      # cd 24f02f5b2b19808b820ea0a980ed6efb
      # nanosystem.journal
      ### nu ändrar vi någon rad i filen för att simulera att den är skadad
      # journalctl
      ### som förväntat händer ingenting
      #### måste datorn startas om för att journal ska kunna skapa en ny binär? NEJ
      # systemctl force-reload systemd-journal.service
      #ls
      system@24f02f5b2b19808b820ea0a980ed6efb-0000000000000001-0005069a53abf581.journal
      system.journal
      # journalctl
      ### Som vi kan se skapar journal en ny binär loggfil och vi kan nu komma åt informationen igen utan att behöva starta om datorn när som helst

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

      slutsats: synflag eller du är okunnig, eller du är en fabler
      låt det garnera dig ändligt

      1.    Rolo sade

        för skrivfel och missbruk av kopiera och klistra skrev jag systemd-journal.service när tjänsten i själva verket kallas systemd-journald.service

      2.    SynFlagga sade

        Pichon?, ... hur fel är du mager, allvarligt .. Jag visste det redan, rapportera felet i röd hatt för att se vad de sa, jag slår svaret, se om du fångar:

        Om du tar bort utdatafilen eller skriver över delar av filen kan inte demonen göra något åt ​​det: om en angripare har behörighet att ändra utdatafilen har hon redan vunnit. Demonen kunde kontrollera några av dessa saker, men det skulle vara ganska ineffektivt och inte riktigt användbart för någonting. Om du vill kan du ställa in en periodisk kryptografisk signatur med 'journalctl – setup-keys'. Se journalctl mansidan.

        Journalctl beror på rsyslog, det startar inte om sig själv vid ett fel i loggen, vilket rsyslog inte behöver, totalt, du måste använda fordward för att skicka till rsyslog och på det sättet skrivs det trots allt och journalloggen regenereras , det är en designfel av journald. Om du inte vill se det, spräng mig.

      3.    anonym sade

        @rolo

        I videon (jag vet inte om du gjorde det) ser jag att i minut 2:11 används ls och inte ls -l vilket gör det möjligt att se storleken som filen system.journal ursprungligen hade, sedan redigerar de den med nano och lägg till tomma rader, starta om tjänsten för hand och vid minut 3:15 gör de ls igen och inte ls -l, sedan vid minut 3:20 ser de loggen med journalctl, detta visar den aktuella loggen som är bra.

        Nu kommer mina frågor:
        1 - eftersom ls används och inte ls -l, för att se originalstorleken på loggen innan den redigeras
        2 - vad hände med den gamla stocken? var placerade systemd det i den korrupta binära loggen?
        3 - med vilket systemd-kommando du kan reparera din korrupta binära logg ... som du inte ska radera

        hälsningar

      4.    Rolo sade

        @anonym

        Nu kommer mina frågor:
        1 - eftersom ls används och inte ls -l, för att se originalstorleken på loggen innan den redigeras
        2 - vad hände med den gamla stocken? var placerade systemd det i den korrupta binära loggen?
        3 - med vilket systemd-kommando du kan reparera din korrupta binära logg ... som du inte ska radera

        1 sanningen att jag inte tänkte på det, använd bara ls för att se vilka filer som fanns i katalogen, men om du är intresserad kan du replikera det, proceduren är detaljerad och jag gjorde det i virtualbox (installation av en debianbas är lite rörigt)
        2 den gamla loggen förblir i samma katalog, endast systemd byter namn på den med en massa siffror och bokstäver (visas i videon)
        3 I vilket fall som helst kan du försöka använda tredjepartsapplikationer (någon hex-editor antar jag) eftersom om systemd kunde reparera den korrupta filen skulle den inte byta namn på den eller skapa en ny. I vilket fall som helst, och som jag redan har nämnt vid andra tillfällen i det här inlägget, kan en försiktig sysadmin använda rsyslog eller syslog-ng som ett andra frågeverktyg, bortsett från att omvandla journalposter till vanlig text om binären blir skadad.

        Jag menar, det är inte idén att övertyga någon att använda systemd (jag skulle till och med gärna ha möjlighet att välja int i debian-installationsprogrammet). men jag kommer inte att hålla tyst när jag läser okunniga eller fantastiska som fortsätter att upprepa lögner om systemd, eftersom det finns en blogg, när man ser att dessa ord inte sammanfaller med verkligheten. och som Aristoteles sa, den enda sanningen är verkligheten 😉

  28.   anonym sade

    @rolo

    Jag har tittat på videon igen och om den listades där var det bara det numeriska namnet så länge att jag såg det, jag trodde att det var katalogen ... Suveränens namn.
    När det gäller reparation av binär, ja, det är logiskt vad du säger ... om jag kunde reparera det skulle jag inte skapa en ny.
    Slutligen sitter jag kvar med att det inte borde vara ett binärt så att detta inte händer och att kunna se det utan specialverktyg med journalctl ... Jag förstår fortfarande inte vad som fick det att använda ett binärt format.

    Hälsningar och tack för svaret

    1.    SynFlagga sade

      Rolo, ägna dig åt något annat:

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

      Jag visste det utan att veta att…. Hur märker du skillnaden mellan en som provar saker och en annan som bara gör fartvideor

  29.   SynFlagga sade

    Jag kommer för att stänga ocote de Rolo, felet som syns i min poC hade rapporterats, så stäng ocote pichon:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393

  30.   Rolo sade

    Låt oss se fantastiska:
    1 Du uppgav att för att journal skulle kunna lösa problemet var det nödvändigt att starta om datorn som i Windows HELT FALSK
    Jag visade dig att det var en lögn och i videon som du gjorde vid något tillfälle använder du kommandot systemctl force-reload systemd-journald.service för om du hade använt det skulle ditt argument krascha (eller så visste du inte kommandot , som skulle visa att du är okunnig eller medvetet inte använde den, vilket skulle visa att du är en berättare)

    2 Du säger att det finns felrapporter, å ena sidan är det helt irrelevant eftersom vanligtvis människor rapporterar mycket nonsens som ett fel (för att du ska förstå att inte alla felrapporter är en riktig fel) till och med ger mig idén att du rapporterade det själv samma sak. Och å andra sidan har alla program buggar (hur många rapporterade buggar har sysvinit (ett program som är cirka 20 år gammalt)) och det bra med rapporten är att det hjälper utvecklare att upptäcka och lösa problem (några snabbare, andra långsammare)

    3 Du säger att med felet du genererar i journal, när du startar om systemet kraschar det eftersom du i videon kan se att du måste tvinga om virtualboxen. HELT FALSKT
    Sanningen är att systemd inte kraschar eftersom systemet startar perfekt (om det inte startade systemd skulle det ge dig en kärnpanik och du måste gå in i återställningsläge)
    Vad som händer med dig är att systemet kontrolleras när du försöker redigera en binär med en textredigerare och faktorerna kan vara många, såsom tilldelat minne, status för operativsystemet (i videon tar systemet lång tid att starta och stänga av vad som tyder på att det inte är en ren installation av 0 (vilket rekommenderas för denna typ av fall)), etc. Jag kan bara berätta att den binära som jag redigerade ungefär 10 eller 20 gånger och den aldrig kontrollerades. Detta visar också att du antingen är okunnig eller berättare.

    4 Nu säger du att journal beror på rsyslog HELT FALSK, faktum är att vem som helst kan verifiera det genom att installera eller avinstallera rsyslog och se att journal fungerar perfekt

    Jag skulle mycket uppskatta det om du lämnar den ohälsosamma besattheten med mig, det är inte mitt fel att du är okunnig eller fantastisk

    Slutsats:
    Du vill inte använda systemd, jag tycker att det är jättebra, nu har du inget behov av att sprida terror med lögner för att få anhängare till ditt anti-systemd korståg. Jag bodde och lät leva, att det finns en plats för alla i världen av fri programvara 😉

    1.    Rolo sade

      ett förtydligande av punkt 3 skulle någon berätta för mig att eftersom systemd är i pid1, skulle en krasch innebära att systemhjälmen. Två saker, först här vad som nämnts är att systemd kraschade på grund av journalfel, men i själva verket finns det en kontroll för att ange en binär (som används i realtid) med en textredigerare, jag klargör också att i alla tester som jag utförde kontrollerade aldrig den virtuella maskinen. För det andra kan ingen med sitt rätta sinne påstå att linux inte är märkt xddd,

    2.    SynFlagga sade

      Fantastisk?, Mager, håll lite tillbaka, fantastisk din gamla kvinna som säger att jag slänger gummit när jag inte rör vid det med en pinne, jag återvänder till respekt:

      1.- Du måste starta om eller tvinga omstart av tjänsten, vilket inte är perfekt och i CentOS 7 när jag försökte omstart av tjänsten inte gjorde något, glöm inte att det är version 208 inte den nya 217 eller 216 av Fedora.

      2.- Irrelevant och de som rapporterar fel? ... du är en idiot, jag svarar inte ens dig

      3.- UNHAPPY, versionen som jag försökte den dagen av videon, som du kan se, hela operativsystemet kraschade, varför tror du att den orto olyckliga lögnen? Jag är inte en ljugande apa, gå för att ta cindor pajero.

      4.- Det beror på att självregenerera sig själv, det gör det inte av sig självt. Jag föreslog det till systemd devs som en funktion, att det regenererar sig själv utan att stoppa loggningen om inte tjänsten startas om, de tog det som vad de är att lägga till, så suga min kuk och säg mig tack pappa för att du samarbetar medan jag tittar på porr.

      Hej mager, jag blev trött på att prata med apor för att jag föredrar att gå till djurparken, när du är på nivån för min anus vi pratar.

      1.    Rolo sade

        @SynFlag Jag ber om ursäkt, jag visste inte att du var sjuk, jag trodde verkligen att du var en fantastisk och okunnig, men med det du precis skrev inser jag att du faktiskt är illusion.

        ja ingenting, jag hoppas att du tar din medicin bättre och kommer tillbaka till verkligheten, kraft! du kan!!!

  31.   pedro sade

    Jag läste och läste och läste om men jag förstår ingenting, jag vet bara att sedan Xubuntu 14.04.1 hittills har jag inte haft några problem med min bärbara dator eller med min hp 1102 laserskrivare vet jag inte någonting alls, jag är en användare och jag vet inte om systemd är sämre eller inte lämplig för init, men jag upprepar att jag inte har några problem med xubuntu. 🙂

  32.   Den verkliga sade

    Jag läser, läser och läser igen och jag vet bara att jag återupplever ett gammalt ämne. XD