Araw-araw ang aming mga computer ay bumubuo ng isang mas mahalagang bahagi ng ating buhay, kung mayroon itong ilang uri ng problema nakakaapekto ito sa ating kalooban, ating katatawanan hehe. Oo naman, ang mga gumagamit ng Windows ay mas madaling kapitan ng takot na pag-atake, kaysa sa kung mga virus (mabuhay ang linux!), paano kung defragmenting ang HDD, paano kung maghanap at mai-install ang Malinis na Master para sa PC (bagaman dito sa Linux kailangan pa nating linisin ang system, ang BleachBit ay isa sa mga ginustong alternatibo). Kamakailan lamang ang mga gumagamit ng Linux ay may (ilang) isang tiyak na sakit ng ulo na tinatawag na: systemd
Sa puntong ito, nabasa ko ang isang nakawiwiling artikulo systemd, na tila uso sa hindi matagal.
SistemaD, na tila sa ilang mga tulad ng (at gagamitin ko ang mga salita ng kaibigan), isang sing-sing para pamunuan silang lahat ... Sa iba hindi lamang ito darating o pupunta, hangga't ang computer ay gumagana nang maayos, hindi mahalaga kung init ang X o Y na mga bagay, o kung ginagamit ang systemd. Sa isang ito na nagsusulat, mabuti ... sabihin nating mas gusto ko ang init, mas madali ko itong nakita 🙂
Iniwan ko ang artikulo dito:
Bago simulan dapat kong sabihin na hindi ko gusto ang desisyon na baguhin ang mga bagay sa Debian ngunit, sa anumang oras ay plano kong talikuran ang aking minamahal na kalikasan. Sinubukan ko lang iyon, kung tatalakayin natin ang isang paksa, kahit papaano ginagawa namin ito bilang handa hangga't maaari kahit na ako mismo ay hindi isinasaalang-alang ang aking sarili na pro-systemd. Upang makamit ang demystification ng systemd ay umaasa ako sa isang website kung saan binibigyan ng mga developer ang kanilang pananaw na dumating sa aking kamay ng isang kasamahan na tila pro-systemd kahit na hindi siya isang gumagamit ng Debian. Sa nasabing sinabi sa palagay ko maaari akong magpatuloy sa pagsubok na ma-demystify kung ano ang sinasabi tungkol sa systemd.
ang systemd ay batay sa binary
Marahil ito ay isa sa mga aspeto na pinaka-shock sa amin, kung ang lahat ay batay sa binary, paano namin sinusubaybayan ang mga bagay na karaniwang ginagawa natin sa pamamagitan ng mga troso? Wala akong ideya kung paano ipinanganak ang alamat na ito, ngunit hindi ito ganap na totoo.
Ang systemd ay naka-configure halos eksklusibo sa pamamagitan ng mga simpleng file ng teksto. Ang ilang mga setting na maaari ring mabago sa linya ng utos ng kernel at sa pamamagitan ng mga variable ng kapaligiran. Walang binary sa iyong pagsasaayos (hindi kahit XML). Isang simple, prangka at madaling basahin ang text file lamang.
Ang bagay na iyon ay monolitik at kinokontrol ang lahat
Bago maabot ang nabanggit na website, ipinagtapat ko na naisip ko sa ganitong paraan ang aking sarili, ngunit pagkatapos basahin ang sinasabi ng mga developer nito, may binago ang aking opinyon ...
Kung magtatayo ka ng systemd sa lahat ng mga pagpipilian sa pagsasaayos ay pinagana ang iyong bubuo 69 indibidwal na mga binary. Naghahatid ang mga binary na ito ng iba't ibang mga gawain, at maingat na pinaghihiwalay para sa isang bilang ng mga kadahilanan. Halimbawa, ang systemd ay dinisenyo na may kaisipang siguridad, samakatuwid ang karamihan sa mga daemon ay tumatakbo nang may hindi gaanong mga pribilehiyo (halimbawa, gumagamit ng mga kakayahan sa kernel) at responsable para sa napaka tiyak na mga gawain, upang mabawasan ang kanilang bakas sa paa. Kaligtasan at epekto. Gayundin, ang mga paralel ng systemd ay nagba-boot ng higit sa anumang nakaraang solusyon. Ang "parallelization" na ito ay nilikha sa pamamagitan ng pagtakbo iba`t ibang mga proseso kahanay. Samakatuwid ito ay nakikita na ang systemd ay napakahusay na nahahati sa maraming mga binary at samakatuwid proseso. Sa katunayan, marami sa mga binary na ito ay naghiwalay nang maayos na ang mga ito ay napaka kapaki-pakinabang sa labas ng systemd.
Halos tawagan ang isang pakete na may kasamang 69 na indibidwal na mga binary monolitik. Gayunpaman, kung ano ang kakaiba sa mga nakaraang solusyon ay nagpapadala kami ng higit pang mga bahagi sa isang solong tarball, at pinapanatili ang mga ito sa kadena sa isang solong lalagyan na may pinag-isang pag-ikot ng paglabas.
Hindi yun mukhang Unix
Tiyak na may ilang katotohanan doon. Ang mga file ng mapagkukunang systemd ay hindi naglalaman ng isang solong linya ng code mula sa orihinal na mga linya ng UNIX. Gayunpaman, ang inspirasyon ay nagmula sa UNIX, at sa gayon mayroong maraming UNIX sa systemd. Ang isang halimbawa ay ang ideya ng UNIX na "lahat ay isang file" na makikita sa systemd lahat ng mga serbisyo ay nakalantad sa runtime sa isang kernel file system, ang cgroupfs. Kaya, ang isa sa mga orihinal na tampok ng UNIX ay suporta sa multi-seat, batay sa built-in na suporta sa terminal. Sa systemd nagdala kami ng suporta ng multi-seat na katutubong muli, ngunit sa oras na ito na may buong suporta para sa hardware ngayon, sumasaklaw sa mga graphic, daga, audio, webcams, at marami pa. Sa katunayan ang disenyo ng systemd bilang isang suite ng pinagsamang mga tool na ang bawat isa ay may kani-kanilang mga layunin ngunit kung ginamit nang sama-sama ay higit pa sa kabuuan ng mga bahagi, na higit pa o mas mababa sa core ng pilosopiya ng UNIX. Kaya't ang paraan ng paghawak ng aming proyekto (ibig sabihin, ang pagpapanatili ng karamihan sa operating system kernel sa isang solong repository) ay mas malapit sa modelo ng BSD (na isang tunay na UNIX, taliwas sa Linux) upang magawa ang mga bagay-bagay (kung saan ang karamihan sa mga pangunahing operating system ay itinatago sa isang solong CVS / SVN repository) na hindi kailanman naging kaso sa Linux.
Sa huli, ang tanong kung ang isang bagay ay UNIX o hindi mahalaga. Ang pagiging mahusay sa teknolohiya ay halos hindi ito natatangi sa UNIX. Para sa amin, ang UNIX ay isang pangunahing impluwensya (sa katunayan, ang pinakamalaking), ngunit mayroon din kaming iba pang mga impluwensya. Samakatuwid, sa ilang mga lugar na systemd ay magiging napaka UNIX, at sa iba ay medyo mas kaunti.
Napaka kumplikado niyan ...
Tiyak na may ilang katotohanan doon. Ang mga modernong computer ay kumplikadong mga hayop at ang operating system na tumatakbo sa mga ito ay malinaw na magiging, kaya't kailangan nilang maging kumplikado. Gayunpaman, ang systemd ay tiyak na hindi mas kumplikado kaysa sa nakaraang pagpapatupad ng parehong mga bahagi. Mas simple ito, at may mas kaunting kalabisan. Sa kabilang banda, ang pagbuo ng isang simpleng operating system na nakabatay sa systemd ay magsasangkot ng mas kaunting mga pakete kaysa sa tradisyunal na paggamit ng Linux. Mas kaunting mga pakete ang nagpapadali sa pagbuo ng iyong system, tinatanggal nito ang mga pagtutulungan at marami sa magkakaibang pag-uugali ng lahat ng mga kasangkot na sangkap.
Hindi ako papayagang gumamit ng mga shell script
Ito ay ganap na hindi totoo. Nang simple Hindi namin ginagamit ang mga ito para sa proseso ng pag-boot, dahil sa palagay namin hindi sila ang pinakamahusay na tool para sa tukoy na hangarin na iyon, ngunit hindi ito nangangahulugang hindi tugma ang systemd sa kanila. Madali mong mapapatakbo ang mga shell script bilang mga systemd service o daemon, maaari mong patakbuhin ang mga script na nakasulat anumang wika bilang mga serbisyo ng systemd dahil ang systemd ay walang pakialam kahit ano ang nasa loob ng naisasagawa na ito. Sa kabilang banda, higit sa lahat ginagamit namin ang mga script ng shell para sa aming sariling mga layunin, para sa pag-install, pagbuo, pagsubok ng systemd. At maaari mong i-paste ang mga script sa maagang proseso ng pagsisimula, ginagamit ang mga ito para sa normal na serbisyo, maaari silang patakbuhin sa huling hintuan, halos walang mga limitasyon.
Sa puntong ito ipinapalagay ko na ang ilan sa mga pangunahing paniniwala ay maaaring na-linaw, sa kabila ng hindi pakiramdam tulad ng isang tagataguyod para sa pagbabago at pagkakaroon ng aking mga pagdududa tungkol sa "isang demonyo upang makontrol ang kanilang lahat"Sa palagay ko na sa huli walang maglakas-loob na sabihin na kahit papaano hindi ito gumagana, alam ko rin ang ilang mga gumagamit na napansin na sa systemd" mas mabilis na tumatakbo ang PC "ngunit iyon ang iba pang mga bagay na maaaring pag-usapan. Sa sandaling ito, mananatili lamang para sa akin na anyayahan kang talakayin dito ang mga punto ng pananaw na mayroon ka tungkol sa startup manager na pinagtibay ng maraming pamamahagi, bagaman ngayon ang pinakamalaking reaksyon ay nakikita sa loob ng komunidad ng Debian, na kung saan ay ipinanganak na isang bagong tinidor sa Lahat ng ito. Kung nais mo ito o hindi ay isang bagay para sa lahat, para sa aking bahagi nais ko lang gawin ang aking kaunti sa demystifying systemd na sa kalaunan ay makikita kay Jessie, ang susunod na matatag na bersyon ng Debian.
Nakita ko ang artikulo sa GUTL (na siya namang kinuha Mula kayAbreus)
Systemd kasalukuyang?
Isa ako sa mga hindi nakakabasa ng maraming balita kapag may bumubuo ng labis na kontrobersya, mas gusto kong manatili sa maraming mga detalyeng pang-teknikal. Iyan ba…. Minsan nararamdaman ko na ang ilang mga paksa ay hihinto sa pagiging isang teknikal na talakayan o debate lamang, at naging katulad ng isa sa mga tsismis na kilalang tao 🙁
Una ang isang bukas na hilera mula sa isang gumagamit patungo sa systemd na tinawag systemd VS intelligence, pagkatapos ay sinabi iyon ni Linus Torvalds Ang systemd ay hindi gaanong masama kung paano nila ito pininturahanat ilang kadahilanan kung mayroon siya), tinawag ang isang tinidor walang kwentad ... Walang mga puna ... at sa wakas Devuan.
Hindi ko sasabihin kung ito ay masama tulad ng sinasabi nila, mas masama o mas masahol pa. Gumagana ang system para sa akin nang walang mga problema, subalit para sa personal na panlasa ay mas gusto ko ang init, dahil ang paraan nito ng pag-oorganisa ng iba't ibang mga bagay (tulad ng mga log halimbawa) mas gusto ko, ngunit hey, kung ang systemd ay tatawaging isang kabayo at dapat palitan sa init (Ito ba ang aming pack mule, alin ang ginagawa ngunit mabagal?) Sa gayon ... tao, hangga't ang pagbabago ay hindi labis na biglang, ang mga gumagamit ay maaaring umangkop nang walang gaanong problema at ang system ay gumagana nang mas mahusay (oo, mas mabuti, hindi ito sulit!), Maligayang pagdating 😀
Napakagandang artikulo, nakasama ko ang Linux Mint 17.1 Rebecca na may systemd sa loob ng ilang araw at pakiramdam ko mas likido kaysa sa mga nakaraang bersyon, hindi ko alam ang tungkol dito dahil ako ay isang pangkaraniwang gumagamit na natututo tungkol dito ngunit Malalaman ko, ito ang unang artikulong nabasa ko na hindi nagsasalita ng mga pests ng systemD.
Para sa isang bagay, siya ang magiging una sa iyong nabasa na hindi nagsasalita ng mga peste tungkol sa kanya at sa kabilang banda, sabihin mo sa akin, ginagamit mo ba ang iyong Mint bilang isang server? Ibig kong sabihin, hindi ka nito maaabala kung mayroon itong bug mula sa oras-oras, hindi? Iyon ang dahilan kung bakit mo ginagamit ang Mint, at iyon ang dahilan kung bakit hindi ito makagambala sa iyo, hindi mo gusto ito ngunit hindi ka din naiipit ng systemd. Kapag mayroon kang mga bug at dahil doon mayroon kang mga seryosong problema sa mga seryosong kapaligiran, makagambala ito sa iyo.
Kaibigan, inirerekumenda mo ang ilang Debian Stable based distro? Maaari kong gamitin ang Debian, ngunit kailangan mong i-configure ang maraming mga bagay sa sandaling naka-install, mga codec, atbp. Alin sa iyong inirerekumenda? salamat
At paano mo namamahala upang makakuha ng systemd sa Linux Mint? Nais kong subukan na ilagay ito ngunit hindi ko alam kung kailangan kong gumawa ng isang karagdagang bagay (sa kung ano, sa teorya, dinala na ng Ubuntu), kung mayroon kang anumang gabay sa ito o isang bagay na maaari mo akong ipasa, gagawin ko pahalagahan ito
Napakagandang artikulo. Tingnan natin kung binasa ito ng Taliban anti-SystemD (ngunit duda ako)
Sa anumang kaso, sa isang taon mula ngayon makikita ko sila na gumagamit ng SystemD at tatanggihan nila ang sinabi nila noong isang taon. Kaya sila. Lumalaban sa pagbabago? Sigurado oo.
Isinasaalang-alang mo ako na isang Taliban para sa ayaw na tanggapin ang Systemd, pagkatapos ay isinasaalang-alang kita ng isang Taliban para sa ayaw mong tanggapin na ayokong tanggapin ang Systemd. Nasa kamay na tayo 😉
Gayunpaman, tulad ng sinasabi nito sa pagtatapos ng iyong mga artikulo:
«elav: Blog Personal / Twitter / G+ / Usuario de ArchLinux. Informático, melómano, blogger y diseñador web. Administrador y Fundador de DesdeLinux.net. »
iyon ay, gumagamit ka ng isa sa mga unang pamamahagi na pinagtibay ng SystemD.
Regards
OK, bata.
Nang walang mga salita !!!!, patuloy na maglaro, ang buhay na iyon ay rosas.
Para sa mga komentong katulad mo, mahal na Giskard, ito ang dahilan kung bakit tinatanggihan ko ang SystemD at kung ano ang ibig sabihin nito.
At kung pagkatapos ng 20 taon na paggamit at pagtatrabaho kasama at para sa Linux, ako ay isang Taliban; Kaya, ganon din.
Sa isang taon ay naguusap kami. At elav, hindi kita binanggit. Pinatay mo ang iyong sarili bilang Chacumbele.
Tingnan natin, ang mga tao ay nagbabasa at HUWAG basahin. Mayroon bang o walang Taliban laban sa SystemD? Meron! At may iba pa sa kabilang panig, ang mga nagtatanggol dito ngipin at kuko na para bang ito ay isang panlunas sa sakit. Ano sila lahat? Hindi! Hindi talaga! Mayroong mga nakikiramay sa isa o sa iba pa at nakikita ang mabuti at masama kapwa nila at ng iba. Sa mga maaari kang makipag-usap nang walang problema. Ngunit hindi nila itatanggi na mayroong mga Taliban. At mula sa gilid hanggang sa gilid. At kung ang isang tao ay nasaktan niyan nang hindi nauunawaan na maaari silang maging HINDI maging isang Taliban, pinahihintulutan ko ang aking kaso dahil sa ebidensya na sila ay nagkasala.
Kung nakikipag-usap ako sa isang tao tungkol sa SystemD at mula sa pasimula ang taong iyon ay hindi tumatawag sa kanya sa kanyang pangalan ngunit Systemshit o isang katulad na bagay, nais kong sabihin sa akin kung posible na magkaroon ng isang pag-uusap sa gayong tao na sa una ay hindi na kinwalipika ang kalaban. Hindi pwede.
Gayunpaman, kailangan mong basahin. Tingnan natin, kung pupunta ako at sasabihing "mayroon bang ilang eschejfhduf (naimbento na salita) na pinalo ang mga bata kapag umalis sila sa paaralan" at iilan ang dumarating upang ipagtanggol ang "eschejfhduf" hindi ba naisip na sila mismo?
Kaya, kung ang sinumang lumitaw diyan (hindi Taliban, mangyaring, at hindi alinman sa eschejfhduf) ay nais na pag-usapan ang tungkol sa mga kalamangan at kahinaan ng init at SystemD (na kapwa may mabuti at masama) Masaya akong nasa paligid.
Pagbati.
Ang Taliban anti systemd? at sabihin mo sa akin, ano ka ang maka-systemd na Taliban?, Sa kabilang banda, bakit ipinapalagay mo na hindi kami magbabasa ngunit direktang magkomento?, sino ang saradong taliban na Taliban na hindi aminin ang talakayan at nagsasalita tulad ng LP :: «Ito ang pinakamahusay, magtiwala ka sa akin, alam ko ang ginagawa ko ". ?
Nabasa ko ang buong artikulo at masasabi ko sa iyo:
Ang systemd ay batay sa binary: Totoo
Ang demystification: Mali
Ang LP ay maling paglalarawan sa sinabi, na kung saan ang core ng systemd ay mga binary, marami, masyadong maraming upang mag-hang mula sa PID1, na malakas na magkakaugnay sa bawat isa, kaya't inaanyayahan ko kayo na tingnan ang #devuan kung paano nagkalinis halimbawa, pag-log ng systemd at ang natitirang mga pakete sa Debian, na ibinigay kung paano nakatali ang pag-log na pumapalit sa PAM sa system.
Ang pagsasaayos ay maikli at hindi pinapayagan ang LAHAT na hindi ko nais, tulad ng, pagdi-deactivate ng journal, dahil hindi mo maaaring patayin ang PID, o pigilan ito o anupaman, iyon ay modularity?, Parehong pagsisimula.
===========
"Ang bagay na iyon ay monolitik at kinokontrol ang lahat."
Ito ay, lampas sa pagiging 2 o 69 na mga binary, nakikipag-ugnay sila sa bawat isa sa dbus at sa gayon sa buong OS, hindi pinapayagan silang maging madaling nauugnay, ang pinakamalinaw na kaso ay journald, na hindi mo ito maaaring i-deactivate, pati na rin, ang pagsisimula ng mga daemon o mga serbisyo ay ginagawa sa pamamagitan ng "mga yunit" na mga file ng teksto, ngunit wala nang higit pa sa na, na-parse ng systemd at voila, walang mga pagbabago o pag-hack sa mga serbisyo na lampas sa itinatag.
=======
"Parang hindi UNIX"
Sagutin ko ito ng maikli. Hindi ito sumusunod sa LSB, ni sa POSIX at ngayon ang isang developer ng fedora na tumutulong sa #devuan, ay nagsabi: «Totoo hindi, hindi mahalaga, ang mahalaga ay maaari itong magpatakbo ng mga bagay na POSIX, ang magpahinga, tiyak na hindi ako interesado sa kung anong OS o kung anupaman, basta gumana ito at may magagandang tampok ». At bakit dapat ito ay tulad ng UNIX o UNIX: Gumawa ng isang bagay at gawin ito nang maayos, isang bagay na hindi nagagawa ng systemd.
===========
Gayunpaman, ang systemd ay tiyak na hindi mas kumplikado kaysa sa nakaraang pagpapatupad ng parehong mga bahagi. Mas simple ito, at may mas kaunting kalabisan »
Hindi gaanong kalabisan? Hinihiling nila sa iyo na mag-install ng ISA pang syslog para sa payak na teksto at hiniling nila ito para sa malayuang pag-log bago magkaroon ng systemd-journald-remote, iyon ay, inilagay nila ito sa produksyon nang hindi nakakagawa ng isang malayong pag-log nang hindi nakasalalay sa rsyslog, isang pangunahing bagay tulad ng sentralisadong pag-login. Kahit na, wala itong kakayahan, isang simpleng boolean upang ipahiwatig kung nais namin ang output sa binary o sa simpleng teksto at gayun din, kung gagamit ito ng binary, bakit hindi isang bagay na kilala bilang berkeley DB upang mabasa ito mula sa anumang UNIX o Linux system?
Simple?, Talaga? tingnan kung gaano kadali ito: http://wiki.gentoo.org/wiki/Comparison_of_init_systems
Tingnan ang dami ng mga linya ng code at mga file.
=========================
"Hindi ako papayagang gumamit ng mga shell script"
Ito ay hindi totoo, ngunit muli itong maling paglalarawan, hindi ito pinintasan na hindi pinapayagan ang paggamit ng bash script, ngunit sa hindi paggamit ng mga ito upang magsimula ng mga serbisyo, kaya't hindi ito nababago, nai-hack at nababaluktot tulad ng nasa simula o sysvinit. At sa pamamagitan ng hackable ibig sabihin kong harcoded.
============================
Iniisip mo pa rin na:
1.- Wala naman akong dahilan
2.- Wala akong nabasa at ako ay isang Taliban?
Nagtataka ako ... kailangan ko bang magtiwala sa sinabi ni Lennart? Kung ang isang taong walang kinikilingan ay nagsasabi sa akin na maaari kong isaalang-alang ang ilang mga bagay, ngunit pareho ito sa akin habang naglathala ang Red Hat ng isang bagay upang ipagtanggol ang Systemd
Wow, hanggang sa ang isang tao sa paligid dito ay nagsabi ng isang bagay na makatwiran at hindi lamang takot at maling impormasyon.
Ang artikulo ay ang salin sa Espanya ng sinulat ni Lennart.
Walang pagkakasala, ngunit ang pagsasalin ay tila ginawa ng bersyon ng Google Translator beta… 🙁 Nahirapan akong maintindihan ang ilang mga talata; gayon pa man ang impormasyon ay pinahahalagahan.
@ Charlie-Brown, ito ay dahil hindi alam ni Lennart kung paano ipahayag nang husto ang kanyang sarili sa Ingles. Ito ay kung gaano ito kapangit sa pamamagitan ng pagbabasa ng orihinal.
Ang mga kadahilanang ibinigay ay may bisa, subalit, sa palagay ko ang ilan ay maaaring makabuo ng maraming mga katanungan. Sa anumang kaso, ang aking rekomendasyon sa mga may pagkakataon: pumunta sa orihinal na mapagkukunan ng impormasyon http://0pointer.net/blog/projects/the-biggest-myths.html (sa kasamaang palad para sa ilan, nasa Ingles ito) na higit na kumpleto at binibigyang katwiran hanggang sa 30 mga kadahilanan kung bakit ang paggamit ng SistemD ay itinuturing na kanais-nais.
Ang artikulong iyong binanggit ay isinulat ng tagalikha ng Systemd. Siyempre, walang sinumang mas mahusay kaysa sa kanya upang ipagtanggol ang kanyang trabaho, gayunpaman, inaanyayahan kita na panoorin ang video na ito http://hackingthesystem4fun.blogspot.com/2014/12/systemd-journald-centos-7-totally.html at sasabihin nila sa akin ang kanilang mga konklusyon tungkol dito. Hindi ko na sasabihin pa.
elav ang isyu ng mga journal ng journal na nasa isang binary ay isa sa mga pinintasan na puntos, kahit si linus mismo ang nagtataas nito, nang sa isang ulat kung saan inamin niya na ang systemd ay hindi gaanong masama. Ipinaliwanag din ni linus mismo na maaari kang lumikha ng isang script upang makuha ang data ng journal at ilagay ito sa payak na teksto.
Pinapayagan ka rin ng systemd na i-configure ang laki ng binary journal, binabawasan ang peligro ng isang posibleng pagkabigo.
Sa totoo lang, ang sining na iyong sinipi ay napaka-unserious, dahil wala itong isang pahiwatig ng pagiging mapagtutuunan, at kahit na ito ay nagtataka sa akin kung ang mali na ipinakita nito ay totoo o ito ay hindi totoo (magkantot ng pagmamay-ari na software upang mabigyan nito ang error).
ang lahat ng mga programa ay may mga bug sa ilang mga punto, ngunit tila palaging sila ay naghahanap para sa ikalimang binti ng pusa upang makahanap ng isang bagay na mali sa systemd.
Halimbawa: sa debian napagpasyahan na ang systemd ay magiging default init, ngunit hindi nito pinipigilan ang paggamit ng sysvinit o openrc o upstart at sasabihin mo sa akin ng mabuti oo ngunit hindi mo lubos na aalisin ang systemd, at ang aking sagot ay ito ang katulad ng nangyari sa debian wheezy kung saan maaari kang magpatakbo ng openrc, systemd o upstart ngunit sa ilalim ng sysvinit
PS: Ayokong isipin kung gaano kabaliw ang makukuha nila sa kdbus at ang pagsasama nito sa systemd sa antas ng linux kernel http://kroah.com/log/blog/2014/01/15/kdbus-details/
Kung pwede. Bukod dito, balak kong opisyal na umalis mula sa mga talakayan patungkol sa Systemd. Kahit anong mangyari 🙂
@rolo ang kabiguan ay naitala, naipakita sa kanya ang maraming mga ulat sa mga bug, ipinakita sa kanya ng isang video at ngayon sinabi nila na ito ay nasira. Kung nais mong siguraduhin, sundin ang mga hakbang at tingnan kung ano ang nangyayari. Ngayon narito ang karagdagang impormasyon tungkol sa bagay na ito, naimbento na mga bug? Sa tingin ko hindi.
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 at ang kanyang mahusay na mga paliwanag)
https://bugzilla.redhat.com/show_bug.cgi?id=974132
https://bugzilla.redhat.com/show_bug.cgi?id=1157350
Kung ano ang nabanggit ng video ay tiyak na nakaka-usisa. Bilang isang developer palagi kaming sinasabihan na ang isang detalye ay hindi dapat makaapekto sa buong system / programa, halimbawa kung ang isang piling query sa database ay nabigo, bakit dapat mag-crash ang buong programa? Pareho ito sa SystemD, kung nabigo ito dahil nabigo ang iba, hindi ko alam kung gaano ito kahusay. Malinaw na, may mga kaso kung saan ang isang kabiguan ay praktikal na pagkabigo ng system, ngunit kung mas nakahiwalay ang panloob na mga katangian ng programa, mas mabuti ang magiging produkto.
Ngayon, ang pag-atake ng software mula sa mahina nitong panig ay hindi bago, ito ay isang pangkaraniwang kasanayan at sa katunayan dapat itong gawin sa bawat programa, kaya't nakikita ang pagkahulog ng SystemD para sa journald, ay isang wastong patunay na ang SystemD Hindi ito ang sinabi o pinaniniwalaan.
Ang mas maraming mga bagay na naging nakasalalay sa SystemD, ang mas masamang bagay ay makukuha. Kung bago ang pag-mount ng isang aparato ay hindi binagsak ang system, ngayon ang mga bagay ay maaaring hindi maganda ang hitsura.
Ang SystemD ay hindi masama, hindi ko kinamumuhian ito, ngunit hindi ito kung ano ang nais mong paniwalaan ng marami. Mayroon itong mga kalamangan, ngunit wala sa Upstart na wala o maaaring magkaroon, syempre, ang Canonical ay kasangkot at wala nang nagnanais na magbayad ng pansin.
Pagbati.
ngunit sa video na iyon nang walang oras alam ko na nag-crash ang system. kung ano ang ginagawa ng uri ay baguhin ang binary ng impormasyon sa journal upang makabuo ng error, ngunit ang punto ay sa tuwing pumapasok ito sa systemd.
Mula sa naiintindihan ko, kung nililimitahan mo ang laki ng binary journal, kapag naabot nito ang limitasyon lumilikha ito ng isa pa at iba pa. pagbawas ng posibilidad na masira ang lahat ng data.
Linawin natin ... Sino ang mag-iisip na baguhin ang log file din? xD
@Jorgicio 4 Disyembre, 2014 6:03 PM
Linawin natin ... Sino ang mag-iisip na baguhin ang log file din? xD
Kung sinabi mo ito sa isang nakakatawa na paraan ... sige, naiintindihan ko :)), ngunit kung talagang tinanong mo, binibigyan ko ang aking pananaw.
Para sa akin malinaw na ito ay hindi isang bug, ito ay isang tampok !! Ang ideya ay na kung may pagdami ng mga pribilehiyo sa isang malayuang pag-access, napakadali para sa mga sumasang-ayon na tanggalin ang log sa pamamagitan lamang ng pag-edit nito upang masira ito at para sa systemd na tanggalin ito bilang masama at sa gayon ay mapupuksa ang napansin sa remote access na iyon.
Sabihin mo sa akin na paranoid, ngunit wala akong ibang paraan ng pag-iisip ... hindi ito isang bug, ito ay isang tampok at iyon ang dahilan kung bakit hindi nila tinanggap upang ayusin ang bug na iyon.
Uff ngayon lahat ng mga linux blog ay gumagawa ng 200 mga artikulo tungkol sa systemd hanggang sa puntong alam ko na ang halos lahat ng mga argumento laban at para sa xD.
at unti unti ay nakumbinsi ako ng ilan sa mga anti sistemd na argumento at bukod doon nakita ko (kung may mali mangyaring iwasto ako)
Nakita ko pa ang isang artikulo tungkol sa kung paano mag-crash ang buong system kapag nag-e-edit ng isang binary log at hindi ito nagbibigay ng anumang impormasyon na ang file ay sira.
ang kawalan ng kalinawan sa mga troso
isang koponan sa pag-unlad na madalas na hindi pinapansin ang mga ulat sa bug
Ang pagiging napakalaki at kasama ang maraming mga bagay sa loob ng isang init ay ginagawang mas hindi matatag ang system at kung magdagdag kami ng mga bug tulad ng nabanggit sa itaas, gumagawa ito ng isang sistema nang walang katatagan na labis na nailalarawan ng linux.
sinasabing modular ngunit ang mga bahagi nito ay hindi maaaring gumana nang wala ang ibang mga bahagi ng parehong systemd
isang pag-unlad na sa pangmatagalan ay bumubuo ng mga dependency kapag nagprograma, na ginagawang software na tulad ng gnome na mahirap bitin sa mga system na walang systemd.
pinapalitan nito ang mga bahagi (networkd, logind atbp) na nagtatrabaho at tumatanggap ng pagpapanatili ng maraming taon at binabago ang mga ito para sa mga bago nang walang anumang pangangailangan na may posibilidad na magkaroon ng maraming mga bug.
Mula sa oras na gumagamit ako ng mga distro na nakabatay sa Arch (Manjaro, Bridge Linux, Antergos) na malinaw na gumagamit ng systemd, dapat kong sabihin na wala akong mga reklamo tungkol sa paggamit at paghawak nito. Ang pagsisimula ng mga serbisyo ay madali - kahit na higit pa sa Bridge, kung saan ang Bluetooth o modemmanager ay hindi pinagana bilang default. Bukod sa isang bug na nauugnay sa hwdb.bin (https://bbs.archlinux.org/viewtopic.php?id=189536) Wala akong maraming problema. Malinaw na sa palagay ko hindi ito opinyon ng lahat, ngunit sa personal wala akong mga reklamo 🙂
Hindi ko gusto ang ideya na ang isang kumpanya (Red Hat) na inakusahan na nakikipagtulungan sa NSA (mga pintuan sa likod at kontrol ng US) ay gumagawa ng isang sistema kung saan kinokontrol ang lahat. Isang singsing upang makontrol ang lahat, upang maitali sa madilim kung kinakailangan ..
Sa kabilang banda, kailangan kong tanggapin na ang intel IRIS PRO 5200 ay mas mahusay na gumagana para sa akin at halos hindi na, kung hindi na, masisira ang aking sistema ng grapiko kapag sinimulan ko ang openSUSE 13.1. At oo, ang lahat ay mas mahusay, nagsisimula ito at napapabilis nang mas mabilis. Paano nakinabang sa akin ang isang simpleng gumagamit.
Itinatampok ko ang mahalagang bahagi
Kung may nag-akusa sa iyo na nagbebenta ng droga, awtomatiko ka bang tagabebenta ng droga?
@juanfgs
Ang drug trafficker no .... isang kasabwat oo.
Diyos ... sisirain kita ngunit ang iyong sariling mga salita ang gumagawa para sa iyo.
Linawin lamang na ang systemd ay nakasulat, at iyon ang dapat gawin.
Baybay
Oo, nakasulat ito na systemd, hindi system D o System D, o kahit na SystemD. At hindi ito system d alinman. Bakit? Sapagkat ito ay isang system daemon, at sa ilalim ng Unix / Linux ang mga iyon ay nasa mas mababang kaso, at napapalooban ng isang mas mababang kaso d. At dahil pinamamahalaan ng systemd ang system, tinatawag itong systemd. Ganun kasimple. Ngunit muli, kung ang lahat na lumilitaw na masyadong simple sa iyo, tawagan ito (ngunit huwag mo itong baybayin!) System Five Hundred dahil ang D ay ang Roman numeral para sa 500 (nililinaw din nito ang kaugnayan sa System V, tama ba?). Ang tanging sitwasyon kung saan nahanap naming OK na gumamit ng isang malalaking titik sa pangalan (ngunit hindi rin ito gusto) ay kung nagsisimula ka ng isang pangungusap na may systemd. Sa mataas na pista opisyal maaari mo ring baybayin ito sÿstëmd. Ngunit muli, ang Système D ay hindi isang katanggap-tanggap na baybay at isang bagay na ganap na naiiba (kahit na medyo angkop).
http://freedesktop.org/wiki/Software/systemd/
Dito rin Inilagay mo iyan sa GUTL .. ngunit tao, lahat ay nagsasabi ng Linux at hindi GNU / Linux, kaya't pareho ang SystemD.
Sinasabi ko sa iyo na hindi kinakailangan na gamitin ang log system o ang cron na ibinibigay ng systemD, maaari mong sundin ang syslog-ng at cronie para dito o sa iba pang mga kahalili
Gumagamit ako ng systemD sa ArchLinux mula noong nasa aur ako at tila mas simple itong hawakan kaysa sa debian at redhat derivative na paraan, mayroon itong maraming mga utos ng console na nagse-save sa iyo mula sa pag-edit ng mga file ng teksto at gawing simple ang pagpupulong ng pag-install ng mga script (tandaan na sa arko ang lahat ay naka-install sa pamamagitan ng console)
At hindi bababa sa mabilis na nagsisimula ang system, sa arko maaari kang magsimula sa mga serbisyo nang kahanay kapag sinisimulan ang system ngunit mapanganib ito
Ang sa palagay ko ay masama tungkol sa isyu ay ang karamihan sa mga panig, o ikaw ay pro-systemd o anti-systemd, at sa palagay ko mayroon itong mabubuti at masamang bagay, ako ay isang gumagamit at nagsimula akong maglaro nang kaunti sa systemd, talaga Ang mga magagandang bagay ay, ang pagsisimula ay mas mabilis at mas kumplikado kaysa sa natitirang init, bagaman ang isyu ng journal ay nakakaabala din sa akin ng marami.
Naiintindihan ko na ang mga tunay na makapagsasabi kung ito ay mabuti o masama ay ang mga sysadmin o eksperto sa paksa ngunit sa palagay ko na ang pag-aalsa ng systemd ay tumigil sa pagiging isang bagay na panteknikal noong una at naging isang bagay na mas "show-stopping", para sa aking bahagi ay medyo laban ako ngunit hindi ko isinasaalang-alang ang aking sarili na anti o pro
@KZKG_Gaara
Nakikita ko na ang karamihan sa iyong nai-puna dito ay kapareho ng na-publish ni Lennart sa kanyang blog, mas tiyak sa post na ito: http://0pointer.de/blog/projects/the-biggest-myths.html.
Siyempre, ang post ay mayroong tiyak na "paglilinaw" at nagtabi ng ilang tiyak na nilalamang panteknikal, upang madaling makahunaw ng impormasyon para sa mga babasa nito, ngunit magiging seryoso at taos-puso kami, kahit na ang katotohanan Masakit: ang systemd ay may maraming mga bagay na tinanggihan ni Lennart na wala ito, iyon at marami pang iba. At sa puntong ito ipinapaliwanag ko sa pamamagitan ng bahagi.
1.- Sinabi ni Lennart na hindi siya namamaga at wala siyang mataas na NIH syndrome (Not Invented Here Syndrome). Kung gayon mangyaring may magpaliwanag sa akin: Bakit ang isang init ay dapat magkaroon ng kontrol sa network (systemd-networkd), dns (systemd-networkd), m-dns (systemd-networkd), mga log (journald), coredumps (systemd -coredump), debug (systemd-coredump at journald), acpi (logind), privilege escalation (logind), control ng ntp (systemd-Timesyncd), control over dev (kinuha ng systemd ang lahat ng pagpapaandar ng udev), control of / dev / random (random number generator) at ang pinakabagong kontrol sa TTY (systemd-consoled)? Hindi ba mayroong maraming mga tool na nilikha para sa mga naturang layunin na ang systemd ngayon ay nagdaragdag ng sarili nitong ilang may eksklusibong pag-access (journald case)? Anong lohikal at katanggap-tanggap na paliwanag ang ibibigay mo sa akin para sa isang init upang ma-break ang kernel debug at cmdline? Idagdag sa kontrol na iyon sa kdbus, ang susunod na IPC na isasama sa kernel. Tiyak na sasabihin nila sa akin dito: «Ngunit maaari kang mag-install ng isa pang tool upang makontrol ang lahat ng iyon». At kung totoo ito, ngunit, marami sa mga tool na iyon ay nakakatanggap lamang ng isang stream ng data na itinapon ng systemd, tulad ng kaso ng syslog at rsyslog, na kumokonekta sa isang data / stream na ibinibigay ng journald upang ang iba pang mga tool ay MAKITA kung anong drive ng journald , sa huli, nangangahulugan lamang ito na mayroon kang dalawang mga tool na gumagawa ng parehong bagay, at ang isa sa mga ito ay isang kahon ng pandora. (Mangyaring huwag sabihin sa akin na ang code ay maaaring ma-awdit, sapagkat inaanyayahan ko ang isang tao na "usokin" ang code ng journal at ang balangkas nito sa systemd at iba pang mga kaugnay na tool)
2.- Sinasabi din sa amin ni Lennart na nag-aalok ang systemd ng suporta para sa mga script ng SysV at LSB. Ito ay isang "kalahating totoong" isang "puting kasinungalingan" kung gayon upang magsalita, sapagkat ang totoo ay ang systemd-214 ay hindi nag-aalok ng suporta para sa mga bash script, SysV o LSB at na nauugnay sa mga tala ng Paglabas nito para sa bersyon na iyon.
3.- Anong systemd ang hindi portable? Ito ay isa pang punto ng moot. Sa BSD hindi ito gumana nang maayos, sa BSD walang Cgroups bukod sa iba pang mga tool na kailangang tumakbo ng systemd. Ngunit ito ay para sa isang kadahilanan ng disenyo ng systemd, hindi dahil hindi ito portable. Hanggang sa hindi matugunan ng kernel ng BSD ang minimum upang suportahan ito, hindi gagana ang systemd sa platform na iyon at hindi iyon kasalanan ng sinuman, tanging ang BSD ay walang interes, o alinman rin kay Lennart. Ito ay simple. Ngayon, ang suporta para sa iba pang mga aklatan ng C ay isa pang bagay, kilala ang mga problema sa glibc (gumawa lamang ng isang kernel sa pamamagitan ng kamay upang makita ang dami ng mga pagpipilian at mga workaround na ginawa upang maiwasan ang mga detalyeng ito, lalo na para sa glibc 2.3, 2.5 at 2.11, bukod sa iba pang mga kamalian na na-drag ng glibc sa paglipas ng mga taon) ngunit hindi ito nagtatapos doon hindi ito nagtatapos, sinabi mismo ni Lennart na mas ginusto niyang lumikha ng sarili niyang libc library, sapagkat para sa kanyang pangkat na mas mabilis ang paggawa nito, kaysa sa ang code ng pagbabasa ay nalikha na (at naitala sa pamamagitan ng paraan), ngunit hindi ito titigil doon, balak nilang alisin ang glibc, at gamitin ang kanilang libc hindi lamang para sa systemd, kundi pati na rin para sa Fedora, ginagawa itong pamantayan para sa pagtatayo ng lahat ng kanilang mga package. NIH Saan Mukhang ang mabuting matandang si Lennart ay mahilig mag-troll at malaki.
4.- Ang systemd na iyon ay hindi monolithic sapagkat nahahati ito sa 69 na binary. Oo nga, maaari itong debate. Ang systemd ay mayroong 69 binaries, na gumagawa ng iba`t ibang mga gawain, ngunit ang mga binary ay ipinapasa ang kanilang impormasyon sa gawain sa systemd, kaya kung nabigo ang isang tao, ang mga pagkakataong masira ang system ay tumaas nang lubos. Ito ay mahusay na dokumentado, ang mga ulat ng mga bug ay masagana sa mga problemang tulad nito at kahit na mas simpleng mga problema, talagang may kabobohan talaga. Ang systemd ay maaaring masira sa daan-daang mga binary, ngunit hangga't ang iyong kernel ay nasa kontrol, ang panganib ng isang pahinga ay patuloy at tataas, at kung hindi ka naniniwala sa akin, basahin ang mga ulat sa mga bug at magsaya.
Tandaan na dito hindi ako nagkomento sa anumang bagay na ang systemd ay basura, gumawa lamang ako ng mga "teknikal" na komento (malinaw naman na pinag-uusapan ang tungkol sa mga teknikal na bagay ay nagiging kumplikado) at wasto, sinusuportahan ng impormasyong madaling ma-access sa internet. Ngayon: Ano ang kailangan ng Linux ng isang standard na init? Oo tiyak na ito ay magiging isang bagay na may malaking halaga sa pamayanan. Anong systemd ang solusyon? Hindi, kahit na malapit ito, tiyak na maraming positibong bagay, ngunit kumalat ang viral at ang bilang ng mga bagay na ito ay nagdaragdag ng panganib na maaaring magkamali at magwakas sa pamayanan.
PS: Iniwan ko ang materyal na kung saan maaari mong patunayan ang sinasabi ko, basahin ito ay lubos na mailalarawan, at makita na hindi ko isinasama ang mga blog o anumang katulad nito, purong personal at nakabatay sa pagpuna. Pagbati.
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 marahil sa tingin mo nakilala ka)
https://code.google.com/p/d-bus/source/browse/kdbus.txt
https://github.com/gregkh/kdbus
http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html
Amen kapatid .. amen ..
Wala pa rin akong nakitang mga wastong dahilan na huwag magpatibay ng systemd. Pasimple mong binibigyang kahulugan ang iyong nakikita nang may takot, na nagreresulta sa pagmamalabis. Ni malinaw at mahusay na natukoy na mga pakinabang o dehado.
Bilang karagdagan, pinapayagan ng pagsasama na iyon ang pamantayan na kung saan mo pa nagsalita. Hindi lamang ang Red Hat ang gumagana sa systemd, ngunit ang iba't ibang mga kumpanya at mga boluntaryo mula sa iba pang mga pamamahagi.
Sa palagay ko ang error ay ang pagpapatakbo ng systemd ay hindi pinag-aralan nang maayos.
Nakikita ko ang wastong mga dahilan sa pagsusuri ni Yukiteru. Pansinin na sa halip na takot ay nakikita ko ang pagkahigpit, katumpakan at kalinawan. Ito ay dapat na isang isyu sa doktor ng mata.
Ito ay hindi takot (Hindi ako natatakot sa isang piraso ng code) at hindi rin sila mga nagpapalabis (lahat ng sinabi ko dito ay naitala at naipasa ko ang sapat na impormasyon na nagpapatibay dito, ang impormasyon na sa pamamagitan ng paraan ay nagmula sa mga listahan at mula sa ang isip / boses / sariling sulat-kamay ni Lennart, at hindi mula sa mga komento ng isang blogger), ito ang KATUNAYAN.
Ginagawa ng systemd ang lahat ng iyon at marami pang iba, at iyon ay isang bagay na nag-aalala (ibang konsepto kaysa takot) sapagkat tiyak na tumatagal ng mga pagpapatungkol at gumagawa ng mga bagay na sa sandaling ito ay maaaring gawin ng ibang paraan at na sa pamamagitan ng mas mahusay na paggana at mas matatag. ang systemd ay tulad ng Windows, at hindi maitago, alamin lamang kung ano ang ginagawa ng userinit.exe, svchost.exe, smss.exe at iba pang mga dependency at ihambing ang mga ito sa systemd, napakahusay ng pagkakapareho na ito ay isang masamang ideya. Ngayon, tiyak na ang systemd ay maaaring magkaroon ng isang mas mahusay na kalidad kaysa sa Windows counterpart nito (o maaaring mangyari ang kabaligtaran, wala talagang nakakaalam, maliban kung nagprogram ka para sa Microsoft) ngunit hindi mo ako maakusahan ng EXAGGERATED at FEARABLE kapag binasa mo mismo si Lennart Sa isang listahan, nagsasalita ng paglikha ng isang buong bagong C library, sapagkat siya ay nagsawa na sa Glibc, at sa napa, itapon ang maliit at walang gaanong tip, na ang libcong iyon ay maaaring magamit upang maitayo ang lahat ng mga pakete ng Fedora. At kung sa palagay mo ay kasinungalingan ito at na ako ay sobra-sobra, iiwan ko sa iyo ang mensahe sa link na ito: http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html (sa Ingles)
Ngayon sabihin sa akin kung ito ay isang pagmamalabis na sabihin sa harap ng lahat ng mga bagay na ito, na sa sandaling napagpasyahan ni Linus na CONFIG_VT na ito, kailangan niyang lumabas sa kernel (sitwasyon na matagal nang nasa paligid) at ipasa ito sa Userspace, huwag mangyari ang isang nakatutuwang bagay tulad ng kung ang systemd-consoled ay isang malakas na pagtitiwala para sa halos anumang pag-install ng Linux (ang isang bagay ay kailangang hawakan ang mga VT, sa palagay mo ba?), Hindi nito mailalagay ang iba't ibang mga di-systemd na distro sa pansin ng pansin pilitin ang isang switch. Kung sa palagay mo ay isang kahabaan, hayaan mong sabihin ko sa iyo na wala kang ideya kung ano ang kaya at ginagawa ni Lennart, dahil ang kanyang pinakabagong pagbabago ay nakakaapekto sa pag-unlad ng udev fork, Gentoo eudev, at patuloy niyang gagawin ito sa kanyang mga banta sa ilalim ng talahanayan (upang magreklamo sa paglaon tulad ng ginawa niya sa Google+)
@xiep Hindi ako masasang-ayon sa iyong komento.
Che Yukiteru, ang iyong mahabang pahayag ay tinanggal ang katotohanan na ang email na na-link mo sa libc ay isang hangal na biro noong Abril, tingnan ang talababa at tingnan ang petsa (Marso 31, marahil Abril 1 sa timezone ni Lennart)
Sanayin ang iyong English-fu sapagkat ito ay puno ng tubig at pinag-uusapan ang lahat ng iyong "pagsasaliksik".
@juanfgs parang ikaw lang ang nagbabasa, kahit papaano pinupuri kita para doon, ngunit kailangan mong basahin ang isang napakahalagang bagay na nasa aking komento, hindi mahalaga na ilalagay ko ito dito:
»NIH Saan? Tila ang mabuting matandang Lennart ay mahilig mag-troll at malaki. "
Sa palagay ko hindi niya ito sinulat para sa isang inosenteng kadahilanan, alam niya ang katotohanan na ito ay isa pang biro ni Lennart para sa Fool Day ng Abril (masamang kalagayan), pati na rin ang kanyang hilig sa pag-convert /, / atbp at lahat ng iba pa sa / Linux. 🙂
PS: Salamat ngunit hindi ko kailangang sanayin ang aking Ingles, ginagamit ko ang wika mula noong ako ay 6 na taong gulang
aaahh at lahat ng iba totoo, i-verify ito 🙂
Ito ay tahasang kahindik-hindik, sinabi mong nakabatay ka sa mga katotohanan ngunit sa totoo lang sinusunod mo ang iyong kutob na ang tao ay masama at nais na sakupin ang mundo at iikot mo ang mga katotohanan upang ipakita ang iyong pagsasalita. Ito ang nakakaabala sa akin ng marami tungkol sa mga anti-systemd na tao, hindi nila tinitilian ang mga salita pagdating sa pag-ikot ng mga katotohanan at pagsasabi ng mga kalahating katotohanan, na puno ng kanilang opinyon syempre.
Ang aking "panuntunan sa hinlalaki" sa mga kasong ito ay ang sumusunod lamang na lohikal na pagkasira, na nagsisimula sa premise na
- Isa akong web developer / desktop apps o kliyente
- Hindi pa ako nakasulat ng isang init system.
- Hindi ako isang nagpapanatili ng isang distro.
suriin kung ang kausap ay may:
- Lumikha ng isang init system
- ay isang aktibong nagpapanatili ng init system ng isang distro
at ang realidad ay ang karamihan sa anti-systemd na nabigo sa pagsubok na ito, ngunit sila ay isang maliit na bilang ng mga tao na sa ilang kadahilanan ALAM Dagdag pa kaysa sa mga tao sa likod: Debian, Fedora, Archlinux, ang Linux kernel, ang buong proyekto ng GNOME, marahil ang proyekto ng KDE din dahil hindi sila nagreklamo tungkol sa systemd, SUSE, at mahabang etc.
Kahit na, ang kanyang lason at vitriolic na pagsasalita ang tanging bagay na nakamit niya ay upang makabuo ng pagkakawatak-watak, mga problema at iba pa. Iyon ang puntong hindi ko maghintay para sa kanila na sa wakas ay lumipat sa BSD dahil sa nagbanta sila mula sa Xorg, NetworkManager, PulseAudio at hindi ko alam kung dahil sa sobrang kamangmangan sa teknikal o dahil hindi nila ito magreklamo tungkol dito.
@juanfgs, sasabihin ko sa iyo ang iyong salita na partikular dito:
«At ang totoo ay ang karamihan sa mga anti-systemd ay hindi pumasa sa pagsubok na ito, kahit na mayroong ilang mga tao na sa ilang kadahilanan ALAM Dagdag pa kaysa sa mga tao sa likuran: Debian, Fedora, Archlinux, ang Linux kernel, ang buong GNOME proyekto, marahil ang proyekto ng KDE din dahil hindi pa sila nagreklamo tungkol sa systemd, SUSE, at mahaba atbp.
Kahit na, ang kanyang lason at vitriolic na pagsasalita ang tanging bagay na nakamit niya ay upang makabuo ng pagkakawatak-watak, mga problema at iba pa. Iyon ang puntong hindi ko maghintay para sa kanila na sa wakas ay lumipat sa BSD dahil sa nagbanta sila mula sa Xorg, NetworkManager, PulseAudio, at hindi ko alam kung dahil sa sobrang kamangmangan sa teknikal o dahil hindi nila ito magreklamo tungkol dito. "
Kaya AYON sa iyo, lahat tayong anti-systemd ay nakakalason at vitriolic na ang tanging nakakamtan lamang natin ay hindi pagkakaisa, mga problema at iba pa. Hayaan mong sabihin ko sa iyo na iyon ang pinakamalaking pagkasuko na nabasa ko dito. Hindi ko alam kung bakit nag-abala ang pro-systemd, kung ang mga problema sa istruktura ng isang sistema ay inilabas, na malinaw na sa ilang mga punto ay makakaapekto sa kanila, dahil maaaring walang nangyari sa kanila ngayon, ngunit sa ilang mga punto, gagawin nila ito. ay, at pagkatapos ang ilang mga anti-systemd ay magpapaalala sa kanila ng mga salitang sinabi nila nang maraming beses at walang pumigil sa kanila, at marahil ang ilang iba pang anti-systemd ay magbibigay sa kanila ng kamay.
En lo personal, no me gusta systemd, pero eso no significa que no use el init, tengo que hacerlo, porque precisamente en mi trabajo si tengo que tocar alguna maquina con ese init, debo tener conocimiento de como manejarlo. Además en lo personal también lo he usado desde que llego a Archlinux e incluso en Debian y Gentoo, así que no me venga a decir que mi visión es sesgada por no hacer uso de systemd, yo le he usado, y se de que pata renquea, y si tengo que ayudar a alguien acá en el foro DesdeLinux o en IRC o la lista de Debian (que es la distro donde yo más tiempo he estado y aún uso en mi trabajo) lo haré con gusto, porque precisamente si algo me agrada de la comunidad Linux, es que pese a la diferencia siempre se ayuda.
Ngayon upang lumipat sa BSD, posible, ngunit gagawin ko lamang ito kung ang systemd ay magiging napakahinahon na hindi ako pinapayagan na gumamit ng anumang iba pang pagpipilian, pansamantala mananatili ako sa Linux, hindi pinapagana ang lahat ng kahibangang iyon, kabilang ang marami sa mga Cgroups na bagay .
!=
Muli mong iniikot ang mga salita upang magkasya sa iyong pagsasalita. Napakahusay mong materyal para sa isang politiko / mamamahayag.
Nilinaw ko, ang aking problema ay hindi na binabanggit nila ang mga teknikal na problema ng Systemd, ang punto ay maraming beses na na-load nila ang kanilang pagsasalita ng mga kasinungalingan, lalo:
Na kung pipilitin ka ng systemd na gumamit ng isang microhttpd server (na isang opsyonal na module na HINDI naka-install bilang default), na kung ang systemd ay isang solong binary, ang systemd na iyon ay isasara dahil ang lennart ay binabayaran ng microsoft, ang mga binary log Mandatory ang mga ito. Walang sinuman ang nais ng systemd at ang pag-aampon nito ay sa pamamagitan ng isang pampulitikang lobby.
Iyon ang nakakagulat, ang mga kasinungalingan. Kung ito ay isang makatwirang talakayan ito ay sulit, ngunit ito lamang ang mabuting FUD.
Na hindi mo gusto na mukhang perpekto ito sa akin, hindi ko gusto ang maraming software, kahit na ang mga wika sa pagprograma, distrito at iba pa, ngunit hindi ako nag-imbento ng mga bagay tungkol dito at hindi rin ako masunod na basahin ang nais kong basahin at pagkarga ng aking mga pahayag ng personal na damdamin upang makapinsala sa imahe ng mga taong bumuo nito.
Paumanhin si @juanfgs, ngunit hindi ako ang tumatawag sa isang tiyak na pangkat ng mga tao na "lason at vitriolic" dahil lang sa hindi nila gusto ang isang piraso ng software.
Muli, pag-ikot ng mga pangungusap upang maging biktima.
@juanfgs muli sinasabi ko sa iyo, iyon ang sinabi mo, suriin ang iyong mga salita, hindi ako maling paglalarawan ng iyong mga salita, gumawa lang ako ng isang kopya / i-paste ng iyong mga salita sa puna 59.
Kinukuha ko ang aking tekstong komentong capo, ang isa na kailangan mong basahin muli ay ikaw dahil ayaw mong maunawaan, o hindi mo alam kung paano makipagdebate. Kinukuha mo ang mga bagay na wala sa konteksto at binibigyang kahulugan ang mga ito habang inaawit sa iyo. Kaya kung nais mong piliing mabuhay sa isang mundo kung saan sa tingin mo ay ininsulto ka dahil pinagtatalunan ang iyong mga argumento, inuusig ka nina Lennart, Red Hat at Microsoft, ito ay dahil pinili mo na maniwala doon.
Maikli dito sapagkat napagtanto kong hindi ka isang makatuwirang tao sapagkat ayaw mong maunawaan, nais mong bigyang-kahulugan ang mga bagay ayon sa nakikita mong akma.
Kung nais mong masaktan, magalit, ngunit ito ang iyong problema, hindi ang ibang bahagi ng mundo.
@juanfgs Hindi ako nababagabag sa iyong mga komento, ang totoo wala akong nakitang dahilan, nagtatalo kami, ang mga sibilisadong tao ay nagtatalo nang hindi kinakailangang abalahin ito (iyon ang sa palagay ko).
Ngayon kung nais mong lagyan ng label, prejudge (o kung ano man ang nais mong tawagan ito) mga tao para sa kanilang mga talumpati o pagkilos (marahil ay dapat mong basahin ang aking puna # 64 at sukatin ang lawak nito), iyon ang iyong problema, limitahan ang iyong sarili sa mga aksyon na iyon patungo sa iyong sarili at iwanan ang iba sa bag na iyon.
Pagbati.
"Karamihan sa anti-systemd", "halos lahat", "lahat", "ilang bahagi ng anti-systemd" ... lumihis kami, Mariano, lumihis kami. Sa kasalukuyang kaso: Hindi ko makita kung saan man si Yukiteru ay gumawa ng isang kahindik-hindik na pananalita batay sa mga hunches (na tumutukoy sa kanyang pagtatasa sa ganitong paraan ay may isang bagay na baluktot), sa kabaligtaran, nakabuo siya ng matatag na mga argumento tungkol sa mga kawalan ng systemd batay sa naaangkop na mga katanungan at materyal na kinuha mula sa mga listahan ng pag-mail at mga bakas ng bug (pati na rin sa isang magalang at sibilisadong paraan). Posibleng para sa kadahilanang ito na inis niya ang ilan at inaatake nila siya sa unang komento, upang siraan at disqualify siya (sa oras na ito, sa isang lason na paraan).
Kung nakikita mo na ang diskurso ng karamihan sa anti-systemd ay lason at vitriolic, kung ano ang nakikita ko sa diskurso ng ilang maka-systemd (hindi ko alam kung sila ay karamihan o isang minorya) ay hysteria at pag-uusig ng mga taong, tiyak, gumawa sila ng matatag na mga argumento sa gitna ng lahat ng ingay. Na sa aking lupain tinawag namin na nakakaabala na hindi pagsang-ayon.
Ang systemd ay gumagana nang maayos para sa iyo? Mahusay, mukhang mahusay sa akin, ngunit hayaan ang mga hindi nag-iisip ng parehong ipahayag ang kanilang mga reserbasyon (maaaring hindi gumana sa parehong paraan ang operating system).
Regards
Oh sa pamamagitan ng paraan, bakit ang anumang systemd bug ay hinipan hanggang sa punto ng pag-aaksaya ng buong bahagi, ngunit ang iba tulad ng GCC, glibc, o kahit na ang kernel ay hindi pinintasan sa puntong iyon para sa marami sa kanilang mga bug?
Sinabi mo mismo, ang glibc ay matagal nang nag-drag sa mga problema. Ang Llvm ay sa paglipas ng panahon ay napatunayan na may mga kalamangan kaysa sa GCC. At dito hindi ko nakikita ang parehong pamimintas.
Bakit hindi gawin ang pareho sa iba pang mga proyekto?
Ito ay simpleng kolektibo at hindi makatuwiran na takot para sa akin.
Ang Glibc ay mayroong mga bug walang sinumang maaaring maitago ang mga ito, maraming mga Glibc bug na nakakaapekto sa kernel at daan-daang mga maipapatupad. Ang pagkakaiba sa pagitan ng Glibc at systemd ay ang dating ay isang batayan kung saan libu-libong mga proyekto ng software ang maaaring mabago sa mga binary, habang ang systemd ay isang init, na ang hangarin ay maging isang matatag, napatunayan at praktikal na hindi nagkakamali na piraso. Hindi lamang iyon, dapat ayusin ang Glibc sa daan-daang iba't ibang mga arkitektura ng hardware (CPU), sa iba't ibang mga flag ng pag-optimize at natatanging mga katangian ng CPU, sa iba't ibang mga paraan ng pag-optimize sa software, isang mas mahirap at mahirap na trabaho kaysa sa systemd, pati na rin. Hindi talaga ako nakakakita ng anumang paraan upang maipakita ang isang paghahambing sa pagitan ng dalawang mga proyekto sa parehong sukat.
Ang parehong napupunta para sa GCC, ang GCC ay isang tagatala na sa pamamagitan ng paraan ay sumusuporta sa maraming mga wika (13 sa kabuuang pagbibilang ng mga hindi opisyal), at may mga katangian na katulad sa Glibc, na sumusuporta sa maraming mga arkitektura (70 mga arkitektura para sa bersyon 4.9), binary optimization mga watawat, flag ng pag-optimize ng CPU, at maraming iba pang mga tampok. Ngayon sila ay nasa parehong antas ng kahirapan, isang tagatala na may isang init. Ang sagot ay higit pa sa halata, simula sa systemd na iyon ay nasa C, at maraming code ng GCC ay nasa assembler o kailangan mong gumamit ng assembler upang makuha ang mga bagay na gumana sa binary, isang bagay na medyo mahirap gawin.
Ano ang mga pagkakamali ng GCC at Glibc? Malinaw Kahit na si Linus ay binigyan sila ng kanyang pag-atake, ngunit sa GCC at Glibc mayroon silang positibong bagay na sa systemd madalas silang nakalimutan, at iyon ay, isang bug na iniulat, nakita ang isang bug, naayos ang isang bug.
- mangyaring may ipaliwanag sa akin: Bakit dapat magkaroon ng kontrol ang isang init ng:
mga network (systemd-networkd),
dns (systemd-networkd),
m-dns (systemd-networkd), l
OGS (journald),
coredumps (systemd-coredump),
debug (systemd-coredump at journald),
acpi (pag-logind), pagdaragdag ng pribilehiyo (pag-logind),
ntp (systemd-Timesyncd),
dev (kinuha ng systemd ang lahat ng pag-andar mula sa udev),
mula sa / dev / random (random number generator)
TTY (systemd-console)?
Ang isang tema na 100000 na paulit-ulit at paulit-ulit, kung ano ang kailangan mong sabihin ay ang systemd ay maaaring gumana nang wala sila, sa katunayan sa debian walang kahit kalahati ng mga binanggit mo
gayun din ito ay isang katangian lamang ng malawak na diskarte nito
lennart: Nahahati ang systemd kung ano ang dapat nitong gawin sa maraming iba't ibang mga bahagi (90+ na mga binary ngayon.) Ang bawat isa ay nagpapatakbo ng may kaunting mga posibleng pribilehiyo.
Naiisip ko na ito ay hindi labis ng isang pagkakaiba sa mga coreutil, na mayroon ding isang malaking bilang ng mga bahagi sa isang pakete. At ang mga coreutil ay marahil isa sa mga pangunahing proyekto na nagpapadama sa Linux ng isang tulad ng UNIX na operating system, tama?
Ngunit oo, ang systemd ay mas kumplikado kaysa sa sysvinit, walang tanong. Sa huling 40 taon ng pag-compute ng marami ay nagbago, at marami sa kanila ang talagang nangangailangan ng isang tiyak na antas ng pagiging kumplikado upang makitungo ... May napakakaunting paraan sa paligid nito.
Dahil hindi ka nakakakuha ng sobrang kompromiso sa freebsd, na eksaktong eksaktong bagay ngunit sa mga tool nito at hindi pinapayagan na magamit ang iba, na hindi ganoon ang kaso sa systemd.
- Wala bang maraming mga tool na nilikha para sa mga naturang layunin na nagdadagdag ngayon ang systemd, ang ilan na may eksklusibong pag-access (journald case)?
Hindi ko tatanggihan na nai-save ng tema ng journal ang impormasyon sa isang binary ay ang pinakamahina na ipinagtanggol, ngunit hindi ito ang katapusan ng mundo, maaari silang mai-save sa payak na teksto
- Anong lohikal at katanggap-tanggap na paliwanag ang ibibigay mo sa akin na ang isang init ay may kakayahang masira ang kernel debug at cmdline?
Mmmmmmmmmmm …………………. basagin ang kernel ...... 5000000 na mga bagay ang maaaring masira ang kernel
- Idagdag sa kontrol sa paglipas ng kdbus, ang susunod na IPC na isasama sa kernel.
Ayon kay lennart Ito ay may positibong ugnayan para sa mga developer at magdadala ang systemd ng mga tool upang buksan ang dbus sa mga administrador, bibigyan din nito ang mga interface ng journal at networkd bus
- Tiyak na sasabihin nila sa akin dito: "Ngunit maaari kang mag-install ng isa pang tool upang makontrol ang lahat ng iyon." At kung totoo ito, ngunit, marami sa mga tool na iyon ang nakakatanggap lamang ng isang stream ng data na itinapon ng systemd, tulad ng kaso ng syslog at rsyslog,… .. nangangahulugan lamang ito na mayroon kang dalawang mga tool na pareho ang ginagawa, at isa sa ang mga ito ay isang kahon ng Pandora. (Mangyaring huwag sabihin sa akin na ang code ay maaaring ma-awdit, sapagkat inaanyayahan ko ang isang tao na "usokin" ang code ng journal at ang balangkas nito sa systemd at iba pang mga kaugnay na tool
ipinasok namin dito ang teorya ng sabwatan !!!!! ito ay payat na libreng software walang nakatago
3.- Anong systemd ang hindi portable? Ito ay isa pang punto ng moot. Sa BSD hindi ito gumana nang maayos, sa BSD walang Cgroups bukod sa iba pang mga tool na kailangang tumakbo ng systemd. Ngunit ito ay para sa isang kadahilanan ng disenyo ng systemd, hindi dahil hindi ito portable. Hanggang sa hindi matugunan ng kernel ng BSD ang minimum upang suportahan ito, hindi gagana ang systemd sa platform na iyon at hindi iyon kasalanan ng sinuman, tanging ang BSD ay walang interes, o alinman rin kay Lennart.
Sa gayon hindi iyon ganap na tama, ang mga developer ng bsd ay gumagawa ng isang bagay na katulad sa systemd na na-highlight mismo ni Lennart sa kanyang g + account
https://plus.google.com/115547683951727699051/posts/g78piqXsbKG
https://www.youtube.com/watch?v=Mri66Uz6-8Y
4.- Ang systemd na iyon ay hindi monolithic sapagkat nahahati ito sa 69 na binary. Oo nga, maaari itong debate. Ang systemd ay mayroong 69 binaries, na gumagawa ng iba`t ibang mga gawain, ngunit ang mga binary ay ipinapasa ang kanilang impormasyon sa gawain sa systemd, kaya kung nabigo ang isang tao, ang mga pagkakataong masira ang system ay tumaas nang lubos. Ito ay mahusay na dokumentado, ang mga ulat ng mga bug ay masagana sa mga problemang tulad nito at kahit na mas simpleng mga problema, talagang may kabobohan talaga. Ang systemd ay maaaring masira sa daan-daang mga binary, ngunit hangga't ang iyong kernel ay nasa kontrol, ang panganib ng isang pahinga ay patuloy at tataas, at kung hindi ka naniniwala sa akin, basahin ang mga ulat sa mga bug at magsaya.
Kung gumagamit ka ng sysvinit at nasisira din ng iyong TTY dev acpi ntp ang iyong system, masisindak din.
Ang Monolithic ay freebsd at wala kang sasabihin
@rolo
Ilista ako ngayon kung alin ang mga distro na kumuha ng systemd at nilikha ang 90 na mga binary sa magkakahiwalay na mga pakete, magiging 91 na mga pakete na may systemd.
At kapag nag-install ng systemd hindi ito hihilingin sa akin para sa anuman sa 90 na mga pakete bilang mga dependency.
Seryoso, at muli iginiit ko ... mangyaring ipasa sa akin ang mga pagpipilian ng –configure-help na nais kong gumawa ng 91 mga pakete sa pag-iipon ng kamay gamit ang paggawa.
Walang mas masamang bulag kaysa sa hindi nais na makita ... mga lalaki ito ay tubig at langis, tila mayroon pa ring mga taong matigas ang ulo na hindi nakikita ang katotohanan ng hinahabol ng redhat.
@rolo Nais kong i-install mo ang systemd at alisin ang journald, systemd-udev at coredump, at gumamit ng mga pagpipilian tulad ng eudev at syslog nang direkta, upang makita kung maaari mo.
Ang komentong ito ay hindi maaaring tumawa sa akin nang mas seryoso, namamatay ako. 😀
Sapat na seryoso, napupunta talaga sila sa problema sa pagbabasa nang kaunti, sa halip na dumikit ang sinag sa mata.
Bukod, walang nakakalimutan na Kay Sievers hindi lamang sinira ang kernel cmdline, ngunit nais na isara ito, pagkatapos ng lahat ng "generic ay generic".
Sa madaling salita, ayon sa iyo, ang katotohanang ang dalawang proseso ay nagpapasa ng impormasyon sa paggawa ng mga ito na kaisa na ang katotohanang ang isang nabigo ay gumagawa ng isa pa ay may isang mataas na posibilidad na mabigo ... mula sa aling teorya sa pag-unlad ng software mo nakuha iyon? Sumasang-ayon ako sa @pamp na nagsasalita ka mula sa hindi makatuwiran at bias na takot.
At ang iyong iba pang malaking katanungan, bakit kailangang makontrol ng systemd ang napakaraming mga bagay? Simpleng sagot: dahil sa sysvinit at lahat ng iba pang mga kalamangan na init na ipinakilala kamakailan sa Linux kernel ay nasasayang, hangga't walang naglalagay sa kanila na gamitin sa puwang ng gumagamit, "naiinis" sila (tulad ng sinasabi natin sa Cuba ... mabuti , pag-aaksaya) nang walang sinuman na ginagamit ko ang mga ito at nagbibigay sila ng napakahusay na kalamangan sa mahusay na paggamit ng mga mapagkukunan ng hardware (CPU, RAM, I / O, atbp.) kasama ang mga cgroups. Ang ginagawa ng systemd ay, tiyak, inilalagay ang mga magagandang pag-andar na ito ng Linux kernel sa serbisyo ng gumagamit, ngunit para doon kailangan niyang maging isang nagpapasimuno sa mga demonyong iyon.
Sa palagay ko mali ang nabasa at pinag-aralan mo (mahalaga ang pag-aaral) o hindi mo lang binigyan ang iyong sarili ng pagkakataong gawin iyon. Ang dalawang proseso na ipapasa ang impormasyon ay hindi isang dahilan para masira ang isang system, gayunpaman, kapag mayroon kang mga binary na may dinamikong pagkilos tulad ng kontrol sa network, mga log o coredump, direktang pagpasa ng impormasyon sa init, ang mga bagay ay maaaring magkamali at magkamali sila, dahil kung Ang ilan sa mga binary ay nasira, ang mga pagkakataong masira ang natitira ay mas mataas, at iyon ay makatotohanang, at nangyari ito, ang pag-crash ng kernel cmdline kamakailan lamang, ang mga problema sa acpi na pinasalamatan ng mga devs ng Nvidia ay salamat sa systemd-212, lahat iyon ay isang sample ng sinasabi ko.
@Dariem
Kung hindi mo mai-compile ang bawat isa sa mga binary na ito sa indibidwal na mga pakete, pinipilit mo iyon dahil gusto mo ng isang naka-install, kailangan mong i-install ang lahat ng ito, kapag na-install mo ang mga ito, lumalabas na naapakan mo ang iba pang mga package na hindi mai-install dahil ang mga bahagi ng systemd ay sumasakop sa mga lugar na iyon.
Ano ang kahulugan upang hatiin ang isang malaking maipapatupad sa maraming mas maliit na maipapatupad kung sa huli wala kang isang pakete para sa bawat isa na nagpapahintulot sa iyo na i-install ang mga ito nang paisa-isa.
Bumalik ako upang gawin ang pangkalahatang kahilingan sa lahat ng advanced na gumagamit ng systemd, upang sabihin sa akin kung paano mag-ipon ng 90 module na iyon at lumikha ng 90 mga pakete na kung gusto kong i-install ang mga ito at kung hindi man ay ginagamit ko ang mga program na ginagamit ko.
Napakasamang gatas lahat ng ito ... tila naisip ng mga tao ng systemd na lahat ng mga gumagamit ng gnu / linux ay maloko.
Para sa talaan, gumagamit ako ng pagsubok ng gentoo at ilang buwan na ang nakakaraan lumipat ako sa systemd at hindi ko magawa sa journald, na bumalik sa openrc nang mas mabilis kaysa sa kinakailangan upang lumipat sa systemd.
Upang magpatuloy na makita kung paano ang mga bagay ay nangyayari sa systemd mayroon akong archlinux sa isang notebook na malapit nang mailabas sa gentoo .... Tiyak na matatag.
@anonymous, nais ko lamang makita kung paano magbabago ang isyu sa TTY sa Linux. Kapag lumabas ang code na CONFIG_VT, pabor sa paghahati ng VT sa dalawang bahagi na mahusay na naiiba (kernelspace at Userspace) kakailanganin namin ang ilang tool upang makontrol ang mga VT mula sa mga gumagamit at doon ay maaaring maglaro ng systemd-consoled sa pagiging isang malakas na pagtitiwala na hinihila ang natitirang ang mga distrito sa pangangailangan ng pagkakaroon upang mai-install ang mga sangkap ng systemd, upang posible itong gumana ang system. Ang sinasabi ko ay hindi isang pagmamalabis, ito ay napakahusay na posibilidad, at talagang nag-aalala. Mayroong iba pang mga proyekto, tulad ng KMSCon, ngunit kung ang karamihan sa mga desktop at distrito ay pumapabor sa systemd, ang mga bagay tulad ng KMSCon ay maaaring mamatay nang mas mabilis kaysa sa iniisip ng marami.
@Yukiteru 3 Disyembre, 2014 8:49 PM
Hindi ako natatakot doon, hindi aalisin ni G. Linus ang mga default na pagpipilian mula sa isang bersyon patungo sa isa pa, ilalagay niya ang bagong system bilang BAGO at papayagan kang pumili sa pagitan ng luma at bago.
Tungkol sa bahagi ng mga gumagamit, maaari kang gumawa ng isang pakete na ginagawa iyon nang nakapag-iisa, kung gagawin ito ng systemd, bakit hindi pa 50 pa? Ano pa, ang iba't ibang mga paraan ng paggawa nito ay gagawing iba't ibang mga paraan ang iba't ibang mga terminal sa lahat ng mga USE upang maisaaktibo at i-deactivate tulad ng nakasanayan natin.
Gayundin ang kdbus, na aminado ito ni Linus sa 3.19 tulad ng sinasabi niya, hindi ito nangangahulugan na kailangan ng isa itong aktibo oo o oo.
Tuwang-tuwa ako sa openbox + compton, maaaring mawala ang aking mga desktop dahil hindi nila ako maaapektuhan kahit kaunti.
@anonymous ang tanong ay ang pag-aalis sa CONFIG_VT ay isang bagay na sa huli ay magiging kabuuan (mula sa nabasa ko), iyon ay, sa kernel ang mga primitibo lamang ang mananatili, habang ang natitirang mga tool ay nasa lugar ng mga gumagamit, ito ay hindi masama, sa kabaligtaran, aalisin nito ang maraming lumang code mula sa kernel, gawing mas madaling mapanatili, at higit na mai-configure (buong suporta ng KMS / DRM para sa console). Tiyak na sa simula, magkakaroon ng parehong mga system, ngunit sa pangmatagalang (15-20 naglalabas) maaari itong lumabas sa kernel, o kahit na mas maaga, maraming mga tool ang hindi na sumusuporta sa naturang code sa pabor sa mas bago at mas mahusay na sinusuportahang code.
Ngayon, sinabi mo na kung gagawin ito ng systemd, dahil 50 pa ang hindi makakagawa nito (naiisip ko na 50 pang mga application). Kaya, kung nakikita natin ang matitibay na pagtitiwala ng KMSCon (ang pinakalumang proyekto sa puntong ito) ang mga ito ay libudev (code na isasama sa systemd sa lalong madaling panahon, ay hindi suportado at makikipag-agawan sa systemd kung gagana ito sa sarili nitong), libdrm, libxkbcommon, libtsm at systemd mismo upang hawakan ang multi-upuan, kaya't kapag nakita mo ito, napagtanto mo kung paano nagkakaroon ng paraan ang mga bagay sa pagkuha para sa kanilang sarili ng maraming mga tool na kinakailangan para gumana ang isang GNU / Linux OS nang walang mga problema.
@Yukiteru 3 Disyembre, 2014 9:46 PM
Dito sa gentoo libudev ay isang virtual na tumuturo sa sys-fs / eudev, kaya ang mga gentoo na tao ang magbabago sa pagbabago ng eudev upang sumunod sa API na idinidikta ng bagong sistema ng kernel.
Kaya sa palagay ko ang mga distrito maliban sa systemd (hello devuan) ay gagamitin kung o kung eudev.
Ang nangyari sa orihinal na udev ay magaganap, binago ito ng systemd, ngunit narito ang core ay ang isa na idinidikta ng API upang mag-interface sa mga console gamit ang DRM / KMS .... Nais kong makita ang isang urxvt gamit ito… hehe
Ang tinatanggap ko ay ang sinumang gumagamit ng systemd ay walang pagpipilian na baguhin ang anumang ... buong at matigas na pagpapataw at tulad ng sinabi ko dati ... na umiyak sa sementeryo.
@ hindi nagpapakilala tiyak na kung ano ang sinabi mo ay ang iba pang posibilidad, ang eudev ay tatagal ng higit na lakas hinggil sa bagay na ito at panatilihing bukas ang mga pagpipilian upang pumili ng iba't ibang mga tool.
PS: Tulad ng sinabi mo, magiging kagiliw-giliw na makita kung paano sinasamantala ng mga VT ang mga kalamangan ng KMS / DRM kasama ang fbdev 😀
Eksaktong naulit mo ang konsepto na pinuna ko sa iyo, dahil kahit kailan ay hindi ko sinalita ang tungkol sa sistema, nagsalita ako tungkol sa komunikasyon sa pagitan ng mga proseso, at ulitin ko ulit, saan mo makukuha iyon dahil nakikipag-usap ang dalawang proseso, ang pagkamatay ng isang nagpapahiwatig na ang iba pa ay may sapat na mga posibilidad ng To die? Ipaliwanag sa akin kung paano ang dalawang proseso, na nakatira sa magkakahiwalay na puwang ng memorya, ay maaaring magkaka-impluwensya sa panloob na pag-uugali ng bawat isa. Tingnan natin kung ipinapaliwanag ko ang aking sarili, mula sa pananaw ng isa sa mga prosesong ito, ang pag-access lamang sa isang mekanismo ng IPC (anuman ito ay tinukoy upang makipag-usap sa mga proseso ng systemd). Kung ang programmer ay napakasama sa hindi pagsasama ng code na maaaring makitungo sa hindi inaasahang pag-input at output, iyan ay iba pa, ngunit wala itong kinalaman sa isang proseso na nakakaimpluwensya sa mga panloob na iba. Kung nag-crash ang systemd-networkd, hindi nito kailangang pumatay ng journald o systemd, tulad ng sa dating sysvinit, ang katotohanang hindi maaapektuhan ito ng mga inetd crash, magkahiwalay silang proseso.
Ipinaliwanag ni @dariem sa isang simpleng paraan upang makita kung nakuha mo ang ideya:
Ang sinasabi mo ay tiyak na ang pag-uugali na palaging inaasahan mula sa mga modular na programa at proseso. Ang modularity ay ipinatupad para sa hangaring iyon, ang paghihiwalay ng dalawang proseso at na sakupin nila ang kanilang sariling mga puwang sa memorya, at na nakikipag-usap sila sa pamamagitan ng ilang mga paraan (IPC, atbp.), Kaya't kung sakaling may magkamali, kung gayon walang nangyayari na hindi maganda. At ang ang sistema ay maaaring magpatuloy na gumana nang walang pagkaantala. Isang teorya na tiyak na mayroong mahusay na suporta dahil sa pagiging potensyal nito at ang napakalawak na margin ng pagiging maaasahan na ibinigay nito sa kasalukuyang computing. Ngayon, hindi ito laging totoo (ang buhay ay hindi laging maganda), at sa palagay ko ay nabiktima ka ng mga kaganapang ito sa isang okasyon o iba pa (tiyak na napupunta ito para sa lahat anuman ang OS na iyong ginagamit), at bibigyan ko isang pares ng mga halimbawa.
Ang una ay napupunta sa Xorg (na isang modular na proseso tulad ng systemd), na kung minsan ay nababaliw sa isang driver at nag-crash at iniiwan ka lamang nang walang mga graphic, habang ang natitirang bahagi ng system ay patuloy na gumagana tulad ng inaasahan (Mapalad na modularity 😀). Sa ngayon napakahusay, ang aming teorya na ang mga modular na proseso ay hindi kailangang masira ang system ay gumagana nang maayos. Ngunit (palaging may ilan ngunit) kung minsan ay nagbibigay ang Xorg ng isang bagay na higit sa kabaliwan at para sa ilang kakaibang dahilan (na maaaring mula sa pagkontrol ng mouse hanggang sa driver ng graphics) hindi lamang bumagsak ang Xorg, ngunit binibigyan ka din nito ng pinakamagandang takot sa kernel ( at isang graffiti sa monitor tulad ng Picasso) na maiisip mo, at pagkatapos ay mapagtanto mo, na gaano man ito ka-modular, kung ang isang proseso ay nakikipag-ugnay at nagpapalitan ng impormasyon / data sa isa pa, at may isang bagay na nagkamali sa isa sa mga ito, at para sa ilang kadahilanan, ang error ay hindi mapangasiwaan nang tama, ang mga pagkakataong naapektuhan ang mga proseso na pinag-uusapan, para sa simpleng katotohanan na ang data ay mali o simpleng sira, at pagkatapos ay dumating ang sakuna.
Kung sa palagay mo hindi ito maaaring mangyari, iniiwan ko sa iyo ang ilang mga ulat sa mga bug (ang isa ay sa akin sa Debian at mayroong isang pares ng mga litrato) ng isang lumang error na nasa Xorg, mesa, nouveau at drm / kms driver ng kernel, pinoproseso na sa kabila ng tumatakbo ** nang hiwalay at pagiging modular **, magkasama na hindi sila masyadong nagkakasundo, kahit papaano hindi sa ilalim ng mga pangyayaring iyon.
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
Ngayon ang iba pang halimbawa na ibibigay ko sa iyo ng systemd. Ang aming matandang Sysvinit ay nagkaroon ng isang kakaibang katangian na sa kabila ng pagiging matanda, ito ay napaka maaasahan, sa punto na kung ang iyong / etc / fstab ay may isang pagpasok ng pagkahati (hindi mahalaga para sa system, maunawaan ang isang / mnt / Disk160GB) at hindi ito hindi mai-mount para sa ilang kadahilanan, ang bundok ay simpleng nilaktawan, binigyan ka ng isang mensahe ng babala, at nagpatuloy sa proseso ng boot. Ngayon, ang systemd ay isa pang kuwento, sa kabila ng modularity nito, kung mayroon kang isang entry sa / etc / fstab at systemd para sa ilang kadahilanan ay nakikita na imposibleng mai-mount ito, hindi lamang ito naghihintay para sa pagkahati na magagamit (ang normal na naka-program na pag-uugali ) para sa pagpupulong nito, ngunit kung nagtatapos ang oras, ang iyong system ay tumigil at wala ka nang magawa kundi ang ipasok ang recovery mode at alisin ang linyang iyon mula sa / etc / fstab, isang bagay na talagang nabigo. Ang maliit na detalye na iyon ay wala na sa panahon ng automount sa boot, at ang buong proseso ay tumitigil, sa una (systemd-) ang maliit na detalye ay mas pangit, dahil lumitaw lamang ang dump at kailangan mong i-restart. Ang isang tao na napagmasdan ang detalye ay nagsasabi sa iyo.
Ang isa pang halimbawa na maibibigay ko ay coredumpd sa systemd. Ang coredumpd bilang default ay ipinapasa ang lahat ng impormasyon nito sa journald upang maisulat ng huli ang nakuhang impormasyon sa disk, sa ngayon ay mahusay, ginagamit namin ang modularity ng systemd sa aming kalamangan. Ngunit nangyayari ito minsan, kapag ang coredumps ay napakalaki, napakalaki, na makakakuha sila ng maraming GB, at sa proseso ng pagpasa ng impormasyon mula sa coredump hanggang sa journald at pagkatapos ay sa disk, mga kakaibang bagay ang nagaganap tulad ng pagtigil ng paggana ni Xorg at kahit na kernel gulat. Hindi lamang iyon nangyayari sa syempre ng systemd, ngunit ang paraan ng pagdisenyo nito ay nagdaragdag ng kadahilanan ng kabiguan at lumilikha ng iba pang mga hindi kasiya-siyang detalye (bukod sa mga ito ay nadagdagan ang pagkonsumo ng memorya, pag-log ng katiwalian, hindi kumpletong mga dump), na kailangang gumana Sa isang KDE coredump, mayroon kang tiyak na dumaan sa maraming mga yugto tulad nito, at mauunawaan mo ang kahalagahan ng pagkakaroon ng pagpipilian sa pag-sync sa / etc / fstab para sa iyong pagkahati ng dump, at tiyak na mapoot mo ang katotohanang hindi mo maaaring gamitin ang ilang iba pang pagpipilian upang hawakan ang mga dump, kung mayroon kang naka-install na systemd. Isang halimbawa ng kung ano ang maaaring mangyari sa systemd-coredumpd.
https://bugs.archlinux.org/task/41728
Ngayon, upang matapos:
Hindi ba sila dapat maging modular na mga programa at proseso? Oo, ang mga ito ay modular. Ang kernel ay ang tanging monolithic na bagay na napag-usapan ko rito, ngunit tumatanggap din ito ng mga module (LKM), kaya't ito ay magiging isang uri ng hybrid kernel bagaman ang base design form ay hindi idinisenyo sa ganitong uri ng istraktura, at ginagawa itong medyo hindi matatag sa ilalim ng ilang mga pangyayari.
Ang modularity na iyon ay hindi dapat payagan akong panatilihin ang aking mga proseso at system mula sa pag-crash kung may mali? Ito ay totoo, ang modularity ay isang panukalang dinisenyo upang makamit ang isang mataas na antas ng katatagan at pagiging maaasahan, ngunit hindi ito isang 100% hindi maaaring magkamali na panukala, sapagkat kung ang isang bagay ay maaaring magkamali, ito ay magkakamali, gaano man kabago, iyon ay isang katotohanan
Anong systemd ang kailangang magkaroon ng kontrol sa lahat upang posible ang paggamit ng cgroups at iba pang mga pagpipilian na idinagdag sa kernel? Ganap na mali. Iyon ay hindi kinakailangan sa lahat, ang systemd ay maaaring naiwan na may isang interface upang makontrol ang pagsisimula at pagtatalaga ng mga cgroups sa mga proseso at daemon na nasa system, nang hindi kinakailangang sakupin ang bilang ng mga serbisyong mayroon ngayon, at ang pinakamahusay na halimbawa ng iyon ay; na ang OpenRC ay may kakayahang gumamit din ng mga cgroup at hindi ito para sa kadahilanang iyon kaya nagsasalakay upang maisagawa ang gawaing iyon.
Ano ang bias ko at takot kapag pinag-uusapan ang tungkol sa systemd? Wala akong ideya kung saan niya kinukuha iyon, dahil sa nakikita mo ang aking sagot hindi ako natatakot doon, Pinag-uusapan ko lang ang tungkol sa mga aspeto na hindi ko gusto tungkol sa systemd at mayroon na, nang hindi umaasa sa mga opinyon ng third party.
Panghuli, sasabihin mo na: "Kung ang programmer ay napakasama sa hindi pagsasama ng code na maaaring makitungo sa hindi inaasahang pag-input at output, iyon ang iba pa ..."
Tiyak na sasabihin na ang programmer para sa hindi pagsasama ng isang code na humahawak sa LAHAT ng mga posibleng paraan kung saan ang kanyang programa ay maaaring nasira ng ilang maling data entry, ay MASAMA, tila para sa akin ang isang galit. Hindi mahalaga kung gaano siya kahusay sa isang programmer, ang isang tao ay hindi makapagdisenyo ng isang hindi nagkakamali at mabigong ligtas na programa, palaging magiging isang kabiguan, kung aling isang paraan o iba pa ang lalabas, at kapag nangyari ito, ito ay salamat sa isang random na kabiguan sa panahon ng paggamit nito, ng isang hacker o cracker na nagsasamantala sa isang kahinaan, sa pamamagitan ng isang pagsusuri sa code at pag-audit o ng anumang iba pang mga paraan na maaaring umasa ang programmer. Mas mahusay na sukatin ang mga salita bago sabihin ang isang bagay tulad nito.
Pagbati.
Ang halimbawang ibinibigay mo sa Xorg ay ang hindi gaanong naaangkop dahil alam ng bawat isa na sumailalim sa paglipat sa KMS / DRM na ang problema ay sanhi ng mga bug sa mga module ng kernel upang makontrol ang KMS na ibinibigay ng mga tagabuo ng mga driver ng Xorg. Ang isang bug sa isang module ng KMS ay kapareho ng isang kernel panic, wala itong kinalaman sa komunikasyon sa pagitan ng mga proseso, sapagkat sa kasong ito ay Xorg na gumagawa ng isang tawag sa system (syscall) upang baguhin ng kernel ang mode ng screen, iyon ay, doon ay isang proseso lamang na kasangkot (Xorg) na tumatawag sa kernel, na walang kinalaman sa kung ano ang hinaharap natin dito.
Ang kasalukuyang pag-uugali ng systemd kapag hindi nahanap ang mount point ay walang kaugnayan anuman ang katotohanan na ito ay isang pagpapaandar na maaaring hindi gusto ng isang tao, na nalulutas sa pamamagitan ng paghingi na suportahan nila ang iba pang pag-uugali, na hindi papansinin ang nabigong pag-mount. Ang coredump na naganap dati ay maaaring sanhi ng hindi magkatulad na mga sanhi na maaaring isipin lamang, ngunit ang katunayan na ang pagpapatupad ay hindi nagpatuloy ay maaaring dahil sa isang ninanais na pag-uugali, dahil sasabihin mo na dapat itong muling simulan, hindi na mayroong isang kernel na gulat o isang awtomatikong pag-restart. Tulad ng hindi ko napagdaanan na hindi ako maaaring magbigay ng isang opinyon.
Tungkol sa problemang inilagay mo sa systemd-coredumpd at ang link sa ulat ng bug, ipinapahiwatig ng lahat na ang problemang ito sa Arch Linux ay dahil sa compression na pinagana nila ang systemd nang naipon nila ito para sa pamamahagi. Mukha itong isang problema sa compression algorithm kaysa sa systemd mismo. Ang operating system ay hindi nag-crash, sa halip ang algorithm ng compression na ginamit upang iimbak ang mga coredump ay tila inaalis ang system at iyon ang kasalanan ng mga developer ng Arch Linux na nag-ipon ng systemd. Gayunpaman, ang mga systemd ay may mga setting upang limitahan ang pagkonsumo ng mapagkukunan at paganahin / huwag paganahin ang pagkuha ng lahat ng mga coredump na iniulat ng kernel. Siguro ang mga nagpapanatili ng Arch ng systemd at mga gumagamit ng KDE ay dapat tingnan ang mga ito.
Sinasabi mo na ang OpenRC ay gumagamit din ng mga cgroup nang hindi nagsasalakay. Ang problema ay ito: paano makikilala ng OpenRC ang pangalan ng mga maipatupad na daemon upang malaman nang eksakto kung aling alok ang mapagkukunan na pinakaangkop? Hindi talaga ako sigurado kung ito ang isa sa mga kadahilanan kung bakit pinangangalagaan ng systemd ang maraming mga bagay, na binibigyan ang mga executable ng isang kilalang pangalan, ngunit pinaghihinalaan ko na ang bagay ay nangyayari sa ganoong paraan. Bilang karagdagan, tinatanggal ang pasanin ng pagkakaroon ng dash sa gitna upang patakbuhin ang bawat isa sa mga serbisyong ito, sa pamamagitan ng direktang pag-uusap ng mga maipatupad.
Hindi ko tatanggihan na ang systemd ay maaaring magkaroon ng maraming mga bug, ngunit mula doon upang maiugnay ang lahat sa kanila sa paraang ipinaglihi, hindi sa palagay ko. Sa kaso ng sysvinit, napakatatag nito, isang mature na software, nagsisimula pa lang ang systemd.
https://www.reddit.com/r/LinuxActionShow/comments/2nv4hp/ask_lennart_poettering_a_question/
Kung paano nila sinabog ang mga bola sa systemD, xD Kung galit na galit ka rito, lumikha ng iyong sariling distro, na kung saan ay ang Libreng software para sa é_é
Hindi ito tungkol sa poot, tungkol sa pagtatanggol sa iyong komunidad.
Nga pala kung may mga pamamahagi Independent "sa ilalim ng lupa":
http://gutl.jovenclub.cu/neonatox-un-linux-iconoclasta
Paggalang
sapagkat ihambing ang lahat sa microsoft na kumikilos ito tulad ng windows .. kung ang mga bagay ay gumagana nang maayos at ito ay para sa pag-unlad at pag-unlad ng linux ano ang problema ... bawat proyekto sa simula ay maaaring magkaroon ng mga pagbabago sa mga error kung ang mga programa ng software atbp ay perpekto, Tao tayo, ngunit iyan ang dahilan kung bakit mayroon tayong mga pagkakamali
na kung nabigo ang systemd, mag-crash ang system ... at kung nabigo ang kernel, xorg, grub ... may mga tao na, na ina-update ang kernel sa kanilang pc o laptop, nawala ang system ... kung gayon dahil ang pagpupumilit sa pagiging perpekto ng isang bagay ...
na parang ang ilang system na lumabas ay walang mga error sa bug o isang bagay sa mga simula nito o kahit na sa pagkahinog nito ay may mga pagkabigo
Ang Systemd ay ipinataw bilang isang pamantayan na may maruming paglalaro, ito ay isang sapilitan na pagpapakandili para sa maraming mga pakete dahil maraming mga programa ang nasipsip ng systemd alinman dahil pinananatili nila ang mga ito o dahil dahan-dahan nilang tinanggal ang mga ito dahil hindi na nauugnay sapagkat ang systemd ay nagbigay na ng katulad.
Nililimitahan nito ang kalayaan sa pagpili, ibig sabihin, ang mga distrito ay hindi maaaring pumili ng HINDI gamitin ang systemd, maaari nilang subukang labanan tulad ng gentoo, ngunit iyon ay higit pa sa isang pansamantalang solusyon sa systemd, ang openrc ay isang sysv lamang na suportadong manager ng serbisyo para sa init at sa mga distro na incriptibo , Ang systemd ay nagbibigay ng higit na pag-andar kaysa sa openrc at may bagong pag-andar araw-araw. Sinusuportahan ng bagong software ang systemd at kinakailangang magpatupad ng isang bagay na katulad na nagtatapos sa paggawa ng iba pang mga init na mas kumplikado at mas katulad sa systemd na kung saan ay hindi mo gusto.
Gumagawa ang Systemd ng maraming bagay kumpara sa lumang init na basahin lamang ang isang pares ng mga linya mula sa / etc / inittab at pagkatapos ay i-load ang bawat isa sa mga incriptcript at ang kanilang mga setting ayon sa runlevel. Ang dating diskarte ay mas simple at mas malaya. Nasa isang yugto kami ng paglipat patungo sa isang bagong panahon ng homogeneity, walang solusyon, ang paraan na ito ay mananaig ay hindi mapigilan.
Sa loob ng ilang taon ay halos walang pagkakaiba sa pagitan ng paggamit ng debian, paggamit ng arko o fedora, mawawala ang pagkakakilanlan ng bawat distro kung magpapatuloy tayo tulad nito at ang systemd ay magiging mas mapanghimasok araw-araw na magiging bahagi ng pangalan ng system ( systemd / gnu / linux)
LOL
Upang umiyak sa simbahan>: D
Ano ang sinabi ni Don KZKG, iniiwan ko ito sa iyo: https://blog.desdelinux.net/systemd-vs-inteligencia/#comment-127648
Ang problema ay ikaw ay Argentina (ganoon din ako) ngunit ang paraan ng pagpapahayag ng kanilang sarili na ang karamihan sa mga gumagamit ng Argentina na Linux na nabasa ko ay talagang nag-aalala, kahit na sinabi rin na ang mundo ng libreng software ay nakakaakit ng ilang mga tao. Ang sinagip ko ay hindi mo ipinapalagay na maging Argentina, ngunit nagpapakita ito ng mga liga sa kasamaang palad.
uyyuyy .. nahulog ang batang iyon sa mabibigat na artilerya ..
malakas na komento !!
Juju .. ..pochoclos .. xD
Sumusunod mula sa artikulong ito na ang ginagawa lamang nila ay "magpataw" ng isang sistema. Hindi ako pumapasok upang masuri kung mas mabuti ito (na hindi ito), o mas masahol pa. Ang sinasabi ko, inuulit ko, binibigyang diin ko at binibigyang diin, ay hindi ko talaga nais na may ipataw sa akin.
Mga parirala tulad ng: "Hindi lang namin ginagamit ang mga ito para sa proseso ng pagsisimula, dahil sa palagay namin hindi sila ang pinakamahusay na tool para sa partikular na hangarin."
At sino ka upang sabihin sa akin kung nais kong gamitin ito o ang tool na iyon?
Narito ang bawat isa. Hindi ko lang ginagamit ito, period, at habang maaaring hindi, hindi ko gagamitin.
Nilagdaan Isang Taliban.
(Ito ay na nalibang ako sa clowning)
madalas sakit ng ulo sa paksang yan !!!! X_X
Namamahala ako ng mga server sa Centos 6 at ang pagpunta sa 7 na may systemd ay hindi nagkakahalaga sa akin ng anumang bagay, huwag umiyak, nagpapatuloy ang buhay.
Paumanhin, ngunit nagbabasa ako ng maraming mga bagay na nagpapaalala sa akin ng klasikong "windows server - Certified Man VS linux server - OpenSource Man" na diskurso.
Ika-1 - Makikita mo, kung pipilitin mo ang isang error ay normal na mabigo ito. Ang bawat isa sa mga video na nakita ko ay sapilitang mga pagkakamali. Para bang gumawa ako ng isang programa na nagpapakain ng mga keyword sa syslog log at sa parehong oras ay sinusubukan kong magpatupad ng isang script batay sa grep upang kumuha ng impormasyon mula sa log ... syempre mabibigo ito, sanhi ko ito.
Ito ay tulad ng pagbuhos ng asukal sa isang diesel engine at pagsasabing "Tingnan mo ... mas mahusay ang gasolina !!!" o tulad ng Windows do, magsulat ng isang file ng pagsasaayos na mali at magreklamo na ang daemon ay hindi nagsisimulang sabihin na "sa windows hindi ito nangyayari".
Ika-2 - Ang systemd na iyon ay nagsasama ng maraming mga bagay na maaaring hindi mo magamit? Well ano ang problema? Ito ay ang parehong walang laman na argument na ginagamit ng Windows laban sa mga Linux ... "Bakit ko nais ang isang simpleng teksto upang maglagay ng isang libo at isang mga pagpipilian kung hindi mo gagamitin ang mga ito?"
Naririnig ko pa rin ang mga guys ng IBM sa kanilang mga monilithic na programa na tumatahol taon na ang nakakaraan tungkol sa MySQL kapag nabasa ko ang ilang mga bagay. Nagpapasalamat ako at pinupuri ang pagkakaiba-iba ng GNU / Linux at ang pamayanan nito. Kung bibigyan mo ako ng 50 mga paraan upang gumawa ng isang bagay, pipiliin ko sa bawat sandali ang isa na pinakamahusay na gumagana para sa akin o nababagay sa kailangan ko. Nakakita ka ba ng problema dito?
Ika-3 - Sa antas ng mga pag-uusap, nahihinuha ko na mayroon kang isang sapat na antas upang gumana sa anumang pamamahagi o i-set up ang iyong sarili at mapanatili ito sa iyong sarili. Bakit mo nais na ilagay ang systemd at alisin ang mga bagay dito? Hindi ba mas madaling magpatuloy sa iyong init o openRC?
Sa mga tao na nagtanong sa akin na turuan sila ng mga pangunahing kaalaman sa linux palagi kong sinasabi ang parehong bagay ... Ang GNU / LINUX ay hindi mga WINDOWS, huwag subukang gawin ang parehong mga bagay o isipin na parang ito ay. Bakit mo nai-assimilate na ang sistemd ay kapareho ng initd o na gumagana ito pareho? Hindi ba mas madaling masama ang pagpapatakbo ng systemd at gamitin ang potensyal nito, kaysa subukan na gumawa ng mga pagpapaandar tulad ng init o OpenRC? Normal na hindi mo gusto ito.
Ika-4 - Ano ang mali sa pagiging kumplikado? Tiyak na naaalala mo pa rin noong nagbigay ka ng linear programming at tiyak na sa ilang mga punto sinabi mo ... «At bakit nais kong matutong magtrabaho sa mga bagay kung ngayon ay magagawa ko ang lahat at kung saan ay pinapayagan nila akong gamitin?» ... (ang facepalm ng ilang buwan sa paglaon ay mahusay kung xD)
Malinaw tayo Ang kasalukuyang init (at nagsasama ako ng systemd) ay may maraming mga pagkukulang na maaari lamang mapunan sa pamamagitan ng pagdaragdag ng pagiging kumplikado. Walang iba, dahil para sa isang magkakaugnay na system na lumago, dapat itong lumago sa pagiging kumplikado sa peligro na magkaroon ng isang mahina na bahagi, ngunit mas mahusay ito kaysa sa mananatiling hindi dumadaloy.
Malayo pa ang lalakarin at kung… sistemd ay hindi ang solusyon sa lahat. Ngunit hindi rin mananatili sa SysVinit.
PS: Pansinin ang kabalintunaan na ginamit ko ang pc ng aking kasamahan na "Kumapit ako sa windows-server defender" upang mabasa niya ito sa pamamagitan ng paraan. xD
Isang bagay lang, sa mga tagapagtanggol ng iba pang mga INIT na nagbibigay ng teknikal na data at mga link ... KAPIT !!! Gusto kong makita ang mga argumento at data tulad nito. Tandaan lamang, ang data bago ang Oktubre 2014 ay makasaysayan lamang.
Maraming bagay na tinalakay ang naayos na at maraming mga testbeds na nai-publish noong 2013 ay nasuri na.
@rolo
Kung totoo ito, kung nakita mo ang video, na HINDI mo nagawa, makikita mo na ang log ay 8MB, wala nang iba pa at iba pa at lahat ay nasisira, by the way, can you send the output of journald to syslog in payak na teksto? Oo, ngunit kahit na kung hawakan mo ang mga log na nilikha ng journald, nangyari iyon, ang system ay nabitin at, ito ay naiintindihan, tingnan natin, ang journal ay nakabitin sa PID1 kasama ang mga bagay na kasing kumplikado ng systemd, nabigo ito, nakikita mo na hindi mayroong ilang bahagi ng code na hindi pinapayagan ang pag-edit para sa isang bagay maliban sa parehong PID ng journald pati na rin wala itong kakayahang magpatuloy sa pagsusulat na lampas sa log ay nasira, na ipinapakita na bilang karagdagan sa pag-iisip sa windows mode, ang LP ay isang masamang programmer.
Huwag sabihin sa akin na magiging sa mga centos lamang ito, ang pinaka-matatag na bersyon ng distro na gumagamit ng systemd, clone ng RHEL7, at hindi ako nag-uulat o plano na iulat ang error.
Ang totoo ay habang binabasa ko ang mga pro systemd na komento, napagtanto ko na talaga silang tulad ng isang relihiyon, o pabor ka o ikaw ang kaaway, ngunit, sa mga relihiyong uri ng ISIL, ang mga nasa estado ng Islam, ganap na ekstremista, sa katunayan, alam ko mula sa karanasan, mga mahilig sa system, sa palagay nila ito, o kasama mo sila o ikaw ang kaaway. Iyon ang itinaguyod ni Lennart sa kanyang kayabangan at mangyaring huwag akong ligawan sa pagsuporta sa kanya ni Linus, ang systemd ay hindi ito, HINDI, ginamit ko ang systemd sa paglabas nito sa Fedora 15 at ito ay isang mas mabilis lamang init, ito Hindi pinalitan ang modularity ng GNU / Linux.
Kung papatayin ko ang rsyslog, sirain ang mga troso nito o palitan ito ng isang guhit, wala nang iba, tanging naubusan ako ng log, walang nakabitin, hindi apektado ang system.
@Rafael Mardojai
Iyon ang ginagawa ni Devuan, iyon ang ginawa ng Void Linux at iba pa na lumalayo sa systemd.
@Yukiteru
Tiyak na walang nagbabasa sa iyo, tulad ng sinabi nila sa akin ng Taliban, hindi ka nila binabasa dahil gumagamit ka ng mga bintana o nagkomento ka mula rito at dahil naniniwala ako na iilan sa mga mahilig sa system ang nakakaunawa sa teknikal na bahagi ng iyong sinabi at dito nakasalalay ang problema.
======
Ang totoo, iniisip ko pa rin na ang isang taong kilala noong 2006 ay tama tungkol sa isang bagay:
"Ayokong gamitin ng mga tao ang Linux o malaman ito, ang mga taong ito sa Ubuntu ay puno ang aking mga bola"
Ako- "Bakit?"
"Kapag may nalalaman at sa masa, ito ay shits, ito fucks up, at maraming mga sample ng mga ito"
Ako- "tulad ng alin?"
"Tingnan kung ano ang nangyari kay Debian, ngayon ay mayroon siyang isang ulok na anak na nagngangalang Ubuntu at tandaan sa loob ng ilang taon magkakaroon kami ng" mga hacker "at" geeks "na sumipsip ng Ubuntu at hindi nila malalaman kung paano makilala ang Ext3 mula sa NTFS"
May tama .... Ang systemd ay nagtatagumpay sa mga nakakaalam, tulad ng sinabi ni Allan McRae, sapagkat wala siyang pakialam kung paano niya sinisimulan ang kanyang makina, para sa kanya ito ay, pindutan, mahika at mayroon akong isang prompt. Kabilang sa mga hindi interesado sa higit sa "nagtatrabaho" na may magagandang tampok, kabuuan, para sa server na gamitin ang LFS o Gentoo o BSD talaga at pagkatapos ang mga nagmamahal dito dahil mas mabilis nitong binubuksan ang kanilang PC na may mga kulay na ilaw, magagandang tunog at mga laro ng pagkakataon , ngunit hindi nila alam kung ano ang isang syscall.
@SynFlag kung hindi nila basahin ito ay sa pamamagitan ng pagpapasya ng kanilang sarili, tungkol sa OS na ginagamit ko, kung nasa trabaho ko ako at nagkomento mula sa isang Windows PC, ito ay dahil ito lamang ang bagay na mayroon ako, maliban sa server iyon ay nasa Debian Wheezy at halatang mula sa server ay hindi ako maaaring magkomento dito.
Kahit sa bahay napilitan akong gamitin ang PC ng aking kapatid dahil namatay ang aking PC (ang MB at ang mapagkukunan ng kuryente ay nakipagsabwatan laban sa akin), at kahit na may oras ako, inilalagay ko ang isang LiveCD at ginagamit ang Sabayon (kasama ang OpenRC) upang magbigay ng puna dito, habang ginagawa ko tulad ng pagsulat ko ng mga salitang ito.
Ngayon, kung sasabihin nila sa akin o isipin na ako ay isang anti-systemd Taliban, hindi ito mahalaga sa akin. Tulad ng sinabi ko, gumamit ako ng systemd at alam ko na ang paa ay pilay, hindi lamang iyon, madalas kong basahin ang listahan ng systemd nang marami upang malaman ang tungkol sa mga bagay na nagmumula sa mga bagong bersyon, at magkaroon din ng kamalayan sa mga pagbabagong nagagawa at ng mga talakayang nagaganap doon. Ngayon kung ang anumang mangingibig ng systemd ay nauunawaan ang teknikal na aspeto ng kung ano ang aking pinag-uusapan at inilagay ko sa aking mga link (ang mga link sa systemd git repo karamihan), at kahit na hindi makita ang katotohanan, pinapayagan lamang akong mag-isip na nagbebenta ako ito sa kanilang mga mata at ang ekstremismo sa kanilang paraan ng pagtingin / pag-iisip / damdamin / mapagmahal / luwalhati / papuri / pagsamba ng systemd ay napakahusay na hindi mahalaga kung kahit si Linus mismo ay sinisipa ang **** sa labas ng systemd, gagawin nila naitatag pa rin sa kanilang mga ideya na tama ang mga ito.
Kamusta! Hindi ako masyadong dalubhasa, at nais kong malaman kung para saan ang "systemd" na ito at bakit napapag-usapan ito, ano ang problema at anong alternatibong naroroon? salamat
Ang komento ng SynFlag! Galing ako sa "geeks", "geeks" at "pro linuxeros" hanggang pareho.
At iyon ang hinaharap na naghihintay sa atin; Ubuntu kahit na sa sopas; Ang mga laptop ng Linux upang mai-access lamang ang Steam at i-play ang pinakabagong mainit na laro. At mga lehiyon ng maliliit na geeks na hindi alam kung ano ang tungkol sa pod.
Postcript: sumisipsip ang konsepto ng background ng systemd.
ang adk at mga pindutan ng forum ay hindi nakikita sa pangunahing pahina
Kaya ayon sa @SynFlag ngayon ang bawat isa na hindi kontra-systemd ay isang n00b, panlalaking panatiko sa relihiyon, at ang salot na sumisira sa GNU / Linux. Sa isang opinyon na kasing kaliit nito hindi ko alam kung ito ay nagkakahalaga ng debate sa paksang ito. Mas mahusay na hayaang tumakbo ang tubig at sa pangmatagalan kung ano ang mangyayari ay mangyayari.
Totoo, darating ang isang punto na hindi na matalakay. ang oras lamang ang magsasabi sa atin kung ang sytemd ay magiging isang positibong bagay para sa mundo ng libreng software o hindi.
Nagbibigay din ito sa akin ng ideya na kung ang pamamahagi na nakabatay sa debian na hindi gagamit ng systemd ay nagbunga, makakatulong ito na mapayapa ang mga espiritu ng mga hindi nais malaman ang anuman tungkol sa systemd.
tulad ng kung kailan lumitaw ang gnome 3 at isang matinding pagtutol ang naitayo, hanggang sa lumitaw ang "fork" kanela at pagkakaisa na pinapayagan na ipagpatuloy ang paggamit ng mga application ng gnome sa isang desktop na may mas maraming mga pagsasaayos at isang disenyo na mas naisip para sa pc at hindi gaanong para sa pagpindot
Marahil iyon, Rolo (ang hitsura ng Devuan), ay maaaring maging isang punto ng pinagkasunduan. Sa palagay ko kailangan nating lahat ito upang maglaman ng isang polarized at bellicose na kapaligiran sa talakayan. Ang Devuan ay magiging isang puwang para sa paglikha at pagpapatuloy ng isang paraan ng paggawa at makakatulong na kalmahin ang mga espiritu. Ang proseso na nabuhay kami sa Debian ay masakit, subalit dapat naming harapin ang sitwasyon, walang pagpipilian kundi tanggapin ang paghihiwalay. Nagtatapos ito na maging katulad ng mga diborsyo. Ang tinidor na ito ay maaaring isang transcript ng isang kasunduan sa kapayapaan at isang bahagi nito. Mayroong mga kahalili, syempre, Slackware, Gentoo, Funtoo, Crux, PCLinux OS, ngayon Manjaro (upang pangalanan ang ilan) ... ngunit ang "deb" na eksena ay nangangailangan ng isang kahalili nang walang systemd. Tila malinaw na walang makakumbinsi sa sinuman, ang mga argumento ay nasa talahanayan at walang pinagkasunduan (sa kabila ng katotohanang ang systemd ay may magagandang ideya at halata ang mga panganib na dala ng software na ito). Panahon na para sa mga tinidor at upang makakuha ng kalayaan para sa gumagamit (sapagkat ito ay tungkol sa Libreng Software, tama ba?).
Ang isang kadahilanan na nakakaimpluwensya sa proseso ay ang pakiramdam ng "pagkabigo" sa bahagi ng ilan sa atin na naglalagay ng aming tiwala kay Debian. Iyon ang dahilan kung bakit ang Devuan ay ipinakita bilang isang tinidor at hindi isang nagmula. Mayroong pag-igting sapagkat wala namang may gusto sa nangyari; ni ang pro-systemd (samakatuwid ay tiyak na galit na galit na pag-atake na sinusubukang i-defame) o ang anti-systemd (na sumali sa tinidor). Sa kapaligiran ay ang "gaano karaming talento ang maaaring mawala sa atin?", Parehong sa isang banda at sa kabilang banda.
Ang lahat ng mga gumagamit ng Debian ay tumingin sa distro sa "isang" tiyak na paraan (maaari itong mailapat sa iba pang mga pamamahagi). Mayroong mga humanga sa kalidad na panteknikal nito, ang iba ay kontrata sa lipunan, impluwensya nito sa mundo ng Linux, ang paggalang na nakamit nito sa mga nakaraang taon, ang katatagan nito sa mga kritikal na kapaligiran sa produksyon ... Sa ilang mga gumagamit ang pang-unawang ito ay nagbago, na may lumilitaw na pagkabigo . Pagkabigo, pagkabigo, tawagan ito kung ano ang gusto mo. Mula doon hanggang sa paghihiwalay mayroong kaunting hakbang lamang.
Ang diborsyo ng Debian ay katulad ng nangyari sa NetBSD at OpenBSD. Bagaman sasabihin ng oras. Nakikita ko ang maraming mga inaasahan sa tinidor at ipinaisip sa akin na hindi ito magiging isang mabilis at sterile na pamamahagi. Ngayon lang mayroong isang miyembro ng koponan ng gnome na nagkomento sa mailing list ni Devuan (kahit na hindi niya gaanong nagawa), ito, sa palagay ko, ay nagpapahiwatig na bumubuo ng interes si Devuan at nais, sa ilang paraan, na makipag-dayalogo.
Sabagay, magandang weekend.
@rolo
Upang sabihin na ang video ay maaaring linlangin o ang software ay isang kabuuang kamalian at insulto, sa aking buhay na PU ** Nagdaya ako ng isang bagay upang lumikha ng isang alamat, hindi kailanman, ipinagmamalaki ko na nakita ko ang kabiguang iyon sa pamamagitan ng aking paraan, hindi ng aking mga trick. Lahat sila ay pumupunta sa **** kaysa sa ***** at hindi ako maglalagay ng higit pa sa mga debate sa systemd sapagkat ito ay ganap na sa fart, walang nais na maunawaan ang anuman at lahat ito ay tulad ng isang relegion, kung saan, Galit ako, sapagkat ang lahat ng ito ay sa pamamagitan ng dogma ng pananampalataya. Maging masaya sa systemd.
Ang karahasan sa @SynFlag ay nagsisinungaling
Ang ipinapakita ng video na ito ay ang kasinungalingan ng pag-angkin na kung ang isa sa mga module ng systemd ay nasira, nagiging sanhi ito ng pag-crash ng systemd, dahil malinaw naman, mula sa kung ano ang ipinapakita ng iyong video na hindi nangyari, xddddd at sa paraan ng pagpapatakbo ng journal bilang ugat, samakatuwid, kung ang isang third party ay pumasok at nakakahamak na fucks up ang journal ng binary binary, hindi ako mag-aalala tungkol sa systemd ngunit sa halip tungkol sa seguridad ng iyong computer. xdddddd. Panghuli, sa paksa ng video, kopyahin kung ano ang ipinapakita sa pamamagitan ng pag-edit gamit ang nano ng file /var/log/journal/24f02f5b2b16758b820ea6a751ed6efb/system.journal at kapag na-restart mo nalaman na mayroong isang bagong system.journal at isang system @@ 24f02f5b2b16758edQeab @@ 820f6f751bXNUMXbXNUMX. Journal na ang nasirang binary.
Iyon ay, napagtanto ng journal na ang file ay sira, kaya hindi ito pinangalanan ulit at lumilikha ng bago, hindi ko makita kung ano ang problema doon?, Parehas na kung tinanggal ang system.journal file, journal ibabalik ito upang likhain.
Nagtataka ako kung ano ang mangyayari kung sirain ko ang isang payak na text log file na may isang hexadecimal editor, tiyak hanggang sa mapagtanto ng isang tao na ang file ay nasira lahat ng data ay nawasak Oo
Pag-usapan natin nang kaunti ang tungkol sa journal, na kung saan ay isa sa mga pinaka-karaniwang pamimintas ng systemd.
ang journal ay isang napakahalagang sangkap ng systemd, na kinukuha ang mga mensahe ng Syslog, mga mensahe ng kernel log, RAM at paunang mga mensahe sa boot, pati na rin ang mga mensahe na nakasulat sa STDOUT / TDERR at ginawang magagamit ang lahat ng impormasyong ito sa gumagamit.
Ngunit ang pinakamahalaga, ang journal ay maaaring gamitin nang kahanay, o bilang kapalit ng isang tradisyonal na syslog daemon, tulad ng rsyslog o syslog-ng, samakatuwid ang isang maingat na sysadmin ay maaaring magkaroon ng rsyslog o syslog-ng bilang pangalawang tool sa pag-query, bukod sa pagbago ng mga tala ng journal sa simpleng teksto kung sakaling masira ang binary
Ang isa pang mahalagang katotohanan tungkol sa journal ay kung ang folder ng / var / log / journal ay hindi nilikha, pansamantalang nai-save lamang ang impormasyon, na nawala sa bawat pag-restart.
halimbawa, nang ipasok ko ang systemd sa debian ang pagtitiyaga ng log ay hindi aktibo kaya kailangan kong manu-manong likhain ang folder ng journal
http://0pointer.net/blog/projects/journalctl.html
Ang mga nakakaalam ng Ingles, ay hindi maaaring palampasin ang mga pag-uusap na nagaganap sa pagitan ng mga tagabuo ng devuan, jaromil dimkr max2344 bukod sa iba pa sa freenode IRC channel #devuan.
Malaking kasiyahan na basahin ang mga pagsisiyasat ng systemd code dahil naibuhos nila ito nang sadya upang mahawahan (lumikha ng hindi kinakailangang mga pagtitiwala).
Inis ako ng Systemd ... diretso ... mahirap. Ang maliit na dokumentasyon o ang fucking slim ay nagpapatakbo lamang ng KDM o gdm at sa isang light system na nais ko ang slim lxdm ay hindi sinusuportahan ito o pinagsasama ito ... .. Seryoso na kahit na bago ... Masaya ako sa dapat nila. Ang totoo nagsimula akong gumamit ng openrc tulad ng sinabi nila sa gentoo at nakatulong ito .... Marami
@rolo
Ikaw ay isang mapagmataas at masamang balita upang masabi iyon. Ito ang pinakapangit na insulto na sinabi mo sa akin na nagsisinungaling ako o nagpapalsipika ng data, talagang naiinis ito sa akin kung paano upang maipagtanggol ang isang bagay na inaatake mo ang mga taong gumagawa ng seryosong PoC tulad ko. Ang log ay nasira, nag-crash ang system, ang pag-restart ng serbisyo ay hindi gagana kaya walang ibang pagpipilian ngunit i-restart ang makina, na hindi pinakamahusay sa isang na-hack na server, sasabihin mo sa akin na kung ang seguridad ay nakompromiso, ang pinakamagandang bagay ay upang muling simulan o muling i-install at ito lamang ang bagay na dapat kong mag-alala tungkol sa sinabi ng systemd na pinapatawad ang kanilang sarili at hindi gumagawa ng isang mainit na pagtatasa ng ANONG NANGYARI? upang makarating sa puntong iyon? Malinaw na ikaw ay isa pang produkto ng bagong sysadmin kung nakarating ka sa naitaas gamit ang ubuntu at may seguridad ng isang DOS 5.0 sa iyong pc, kaya kung ano ang sasabihin mong kinuha ko ito kung kanino ito nagmula, nakakaabala sa akin na ikaw pagdudahan din Ang isang nagpapalsipikasyon ay ikaw, tumugon ka ba sa parehong OS sa mga pag-update ng araw NA IYON? Tiyak na hindi, kaya subukang magsinungaling sa iba pa. Ano ang kakulangan ng kapasidad na mayroon ka, pumunta sa trabaho bilang isang driver ng taxi nang higit pa sa duda na bibigyan ka nito, huminto sa paglalaro sa Linux at panatilihin ang pagtingin sa pr0n
Tingnan natin ang kalapati (synflag), ipapakita sa iyo ng ama kung paano makakapagpatuloy sa pagtatrabaho ang journal pagkatapos na masira ang aming file ng binary journal log sa ilang kadahilanan, nang hindi kinakailangang i-restart ang computer.
Sa halimbawang ito nagsisimula kami mula sa isang pangunahing pag-install ng debian 8 jessie.
Bilang default, ang systemd-journal.service ay mayroong function na "storage = auto", samakatuwid upang magkaroon ng isang paulit-ulit na tala ng mga tala, kinakailangan upang likhain ang file sa / var / log / journal / dati.
# mkdir -p / var / log / journal /
Upang masimulan ng journal ang pagsulat ng mga tala, HINDI mo kailangang i-restart ang computer, gawin lamang:
# systemctl i-reload ang systemd-journal.service
o
# systemctl force-reload systemd-journal.service
### ngayon ay gagayahin natin na ang binary log ng journal ay nasira ###
# cd / var / log / journal
#ls
24f02f5b2b19808b820ea0a980ed6efb
# cd 24f02f5b2b19808b820ea0a980ed6efb
# nanosystem.journal
### ngayon binabago namin ang ilang linya ng file upang gayahin na ito ay nasira
#journalctl
### tulad ng inaasahan na walang mangyayari
#### kailangan bang i-restart ang computer para sa journal upang lumikha ng isang bagong binary? HINDI
# systemctl force-reload systemd-journal.service
#ls
system@24f02f5b2b19808b820ea0a980ed6efb-0000000000000001-0005069a53abf581.journal
sistema.journal
#journalctl
### Tulad ng nakikita natin, lumilikha ang journal ng isang bagong file ng binary log at maaari na nating ma-access muli ang impormasyon nang hindi na kinakailangang i-restart ang computer anumang oras
https://www.youtube.com/watch?v=hEagyMdkN4A&feature=youtu.be
konklusyon: synflag o ikaw ay ignorante, o ikaw ay isang tagagawa
hayaan itong palamutihan ka may hangganan
para sa pag-type ng error at pag-abuso sa kopya at i-paste nagsulat ako ng systemd-journal.service kung sa totoo lang ang serbisyo ay tinatawag na systemd-journald.service
Pichon?, ... kung gaano ka mali ang payat, sineseryoso .. Alam ko na iyan, iulat ang bug sa pulang sumbrero upang makita kung ano ang sinabi nila, pindutin ko ang sagot, tingnan kung mahuli mo:
Kung aalisin mo ang output file, o mai-o-overtake ang mga bahagi ng file, wala talagang magagawa ang daemon tungkol doon: kung ang isang umaatake ay may mga pahintulot na baguhin ang output file, nanalo na siya. Maaaring suriin ng daemon ang ilan sa mga bagay na iyon, ngunit iyon ay magiging hindi mabisa, at hindi talaga kapaki-pakinabang para sa anumang bagay. Kung nais mo, maaari kang mag-set up ng isang pana-panahong cryptographic signature na may 'journalctl –setup-keys'. Tingnan ang pahina ng tao na journalctl.
Ang journalctl ay nakasalalay sa rsyslog, hindi ito muling i-restart kung may error sa log, kung saan ang rsyslog ay hindi kailangan, kabuuan, kailangan mong gumamit ng fordward upang magpadala ng rsyslog at sa ganoong paraan ito nakasulat sa kabila ng lahat at nabago ang log ng journal, ito ay isang depekto sa disenyo ng journald, kung hindi mo nais na makita ito, pumutok ka sa akin.
@rolo
Sa video (Hindi ko alam kung ginawa mo ito) Nakikita ko na sa minutong 2:11 ls ginagamit at hindi ls -l na magpapahintulot na makita ang laki ng orihinal na mayroon ang system.journal file, pagkatapos ay ini-edit nila ito sa nano at idinagdag Walang laman na mga linya, i-restart ang serbisyo sa pamamagitan ng kamay at sa minuto 3:15 ginagawa nila muli ang ls at hindi ls -l, pagkatapos sa minuto 3:20 nakikita nila ang log na may journalctl, ipinapakita nito ang kasalukuyang log na kung saan ay mabuti.
Ngayon ay dumating ang aking mga katanungan:
1 - dahil ang ls ay ginagamit at hindi ls -l, upang makita ang orihinal na laki na mayroon ang log bago mai-edit
2 - ano ang nangyari sa lumang troso? saan ito inilagay ng systemd sa sira na binary log?
3 - sa aling systemd utos maaari mong ayusin ang iyong sira na binary log ... na hindi mo dapat na tanggalin
Regards
@anonymous
Ngayon ay dumating ang aking mga katanungan:
1 - dahil ang ls ay ginagamit at hindi ls -l, upang makita ang orihinal na laki na mayroon ang log bago mai-edit
2 - ano ang nangyari sa lumang troso? saan ito inilagay ng systemd sa sira na binary log?
3 - sa aling systemd utos maaari mong ayusin ang iyong sira na binary log ... na hindi mo dapat na tanggalin
1 ang katotohanan na hindi ko naisip ito, gamitin lamang ang ls upang makita kung anong mga file ang nasa direktoryo, ngunit kung interesado ka maaari mong kopyahin ito, ang pamamaraan ay detalyado, at ginawa ko ito sa virtualbox (ang pag-install ng isang base ng debian ay medyo gulo)
2 ang lumang log ay nananatili sa parehong direktoryo, ang systemd lamang ang pinangalanan itong muli ng maraming mga numero at titik (ipinapakita sa video)
3 Sa anumang kaso, maaari mong subukang gumamit ng mga application ng third-party (ilang hex editor na ipalagay ko) dahil kung maaaring ayusin ng systemd ang sira na file ay hindi ito papangalanan muli o lumikha ng bago. Sa anumang kaso, at tulad ng nabanggit ko na sa iba pang mga okasyon sa post na ito, ang isang maingat na sysadmin ay maaaring gumamit ng rsyslog o syslog-ng bilang pangalawang tool sa query, bukod sa pagbago ng mga tala ng journal sa simpleng teksto kung sakaling masira ang binary. .
Ibig kong sabihin, hindi ito ang ideya ng pagkumbinsi sa sinuman na gumamit ng systemd (Gusto ko ring mahalin na sa debian installer mayroong posibilidad na piliin ang int). ngunit hindi ako mananatiling tahimik kapag nabasa ko ang ignorante o hindi kapani-paniwala na patuloy na inuulit ang mga kasinungalingan tungkol sa systemd, tulad ng isang blog na mayroon, kung nakikita ng isang tao na ang mga salitang iyon ay hindi kasabay sa katotohanan. at tulad ng sinabi ni Aristotle, ang tanging katotohanan ay ang katotohanan 😉
@rolo
Tiningnan ko muli ang video at oo, nakalista ito doon, ang pangalang numero lamang ang napakahaba na nakita ko ito, naisip kong iyon ang direktoryo .... Pangalan ng soberanya.
Tungkol sa pag-aayos ng binary, oo, lohikal ang sinasabi mo ... kung maaayos ko ito hindi ako lilikha ng bago.
Sa wakas ay naiwan ako na hindi ito dapat maging isang binary upang hindi ito mangyari at makita ito nang walang mga espesyal na tool sa journalctl ... Hindi ko pa rin maintindihan kung ano ang humantong dito na gumamit ng isang binary format.
Pagbati at salamat sa pagtugon
Rolo, italaga ang iyong sarili sa ibang bagay:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393
Alam ko nang hindi ko nalalaman na…. Paano mo napansin ang pagkakaiba sa pagitan ng isa na sumusubok ng mga bagay at isa pa na gumagawa lamang ng mga umut-ot na video
Dumating ako upang isara ang ocote de Rolo, ang error na nakikita sa aking PoC ay naiulat, kaya, isara ang pote ng ocote:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393
Tingnan natin ang kamangha-manghang:
1 Sinabi mo na para malutas ng journal ang problema kinakailangan na i-restart ang pc tulad ng sa windows TOTALLY FALSE
Ipinakita ko sa iyo na kasinungalingan iyon at sa video na iyong ginawa nang walang oras ginagamit mo ba ang systemctl force-reload systemd-journald.service service dahil kung ginamit mo ito ang iyong argumento ay mabagsak (o hindi mo alam ang utos, na magpapakita na ikaw ay isang ignorante, o sadyang hindi ito ginamit, na magpapakita na ikaw ay isang kwentista)
2 Sinasabi mo na may mga ulat sa bug, sa isang banda ay wala itong katuturan dahil kadalasan ang mga tao ay nag-uulat ng maraming kalokohan bilang isang bug (upang maunawaan mo na hindi bawat ulat ng bug ay isang tunay na bug) binibigyan pa nito ako ng ideya na iniulat mo ito mismo pareho At sa kabilang banda, ang lahat ng mga programa ay may mga bug (kung gaano karaming naiulat na mga bug ang mayroon ng sysvinit (isang programa na mga 20 taong gulang)) at ang magandang bagay tungkol sa ulat ay nakakatulong ito sa mga developer na matuklasan at malutas ang mga problema (ilang mas mabilis, ang iba ay mas mabagal)
3 Sinasabi mo iyan sa error na nabuo mo sa journal, kapag na-restart mo ang systemd ay nag-crash ito dahil sa video maaari mong makita na kailangan mong i-restart nang malakas ang virtualbox. KUMPLONG MALI
Ang totoo ay ang systemd ay hindi nag-crash dahil perpekto ang pagsisimula ng system (kung hindi ito nagsimula sa systemd bibigyan ka nito ng isang kernel panic at kailangan mong ipasok ang recovery mode)
Ang nangyayari sa iyo ay ang system ay nasuri kapag sinubukan mong i-edit ang isang binary na may isang text editor at ang mga kadahilanan ay maaaring marami, tulad ng inalok na memorya, ang estado ng operating system (sa video na ang system ay tumatagal ng mahabang panahon upang mag-boot at patayin kung ano ang nagpapahiwatig na ito ay hindi isang malinis na pag-install ng 0 (na inirerekumenda para sa ganitong uri ng kaso)), atbp. Masasabi ko lang sa iyo na ang binary na na-edit ko tungkol sa 10 o 20 beses at hindi ito nasuri. Ipinapakita rin nito na ikaw ay alinman sa isang ignorante o isang kwentista.
4 Ngayon sinabi mo na ang journal ay nakasalalay sa rsyslog TOTAL na MALI, ang totoo ay maaari itong suriin ng sinuman sa pamamagitan ng pag-install o pag-uninstall ng rsyslog at makita na ang journal ay gumagana nang perpekto
Lubos kong pahalagahan kung iiwan mo ang hindi malusog na pagkahumaling sa akin, hindi ko kasalanan na ikaw ay ignorante o hindi kapani-paniwala
Konklusyon:
Hindi mo nais na gumamit ng systemd, sa palagay ko ito ay mahusay, ngayon hindi mo na kailangang kumalat ng malaking takot sa mga kasinungalingan upang makuha ang mga tagasunod sa iyong anti-systemd krusada. Nabuhay ako at binuhay, na mayroong isang lugar para sa lahat sa mundo ng libreng software 😉
isang paglilinaw sa point 3, may sasabihin sa akin na habang ang systemd ay nasa pid1, ang isang pag-crash ay magpapahiwatig ng systemd helmet na iyon. Dalawang bagay, una dito kung ano ang nakasaad na ang systemd ay nag-crash dahil sa pagkabigo sa journal, ngunit sa totoo lang mayroong isang tseke para sa pagpasok ng isang binary (na ginagamit nang real time) kasama ang isang text editor, nilinaw ko din na sa lahat ng mga ang mga pagsusulit na aking ginanap ay hindi kailanman nasuri ang virtual machine. Pangalawa, walang sinumang nasa kanilang tamang pag-iisip ang maaaring mag-angkin na ang linux ay hindi may label na xddd,
Hindi kapani-paniwala?, Payat, pigilan ng kaunti, kamangha-mangha ang iyong matandang babae na nagsasabing itinapon ko ang goma kapag hindi ko ito hinawakan gamit ang isang stick, bumalik ako sa paggalang:
1.- Kailangan mong i-restart o pilitin ang pag-restart ng serbisyo, na kung saan ay hindi perpekto at sa CentOS 7 nang subukan ko ang pag-restart ng serbisyo ay hindi gumawa ng anumang bagay, huwag kalimutan na ito ay bersyon 208 hindi ang bagong 217 o 216 ng Fedora.
2.- Hindi nauugnay at ang mga nag-uulat ng mga bug? ... tulala ka, hindi kita sinasagot
3.- UNHAPPY, ang bersyon na sinubukan ko sa araw na iyon ng video, na nakikita mo, nag-crash ang buong OS, bakit sa palagay mo ay ang kasinungalingan na hindi nasisiyahan? Hindi ako kasinungalingan na unggoy, pumunta upang kumuha ng cindor pajero.
4.- Ito ay nakasalalay sa self-regenerate mismo, hindi ito ginagawa nang mag-isa sa katunayan iminungkahi ko ito sa mga systemd devs bilang isang tampok, na binabago nito ang sarili nang hindi titigil sa pag-log maliban kung ang serbisyo ay nai-restart, kinuha nila ito bilang kung ano ang kanilang ay upang idagdag, kaya sipsipin ang aking titi at sabihin sa akin salamat tatay para sa pakikipagtulungan habang nanonood ako ng porn.
Bye payatot, nagsawa ako sa pakikipag-usap sa mga unggoy para sa mas gusto kong pumunta sa zoo, kapag nasa antas ka ng aking anus ay nag-uusap kami.
@SynFlag Humihingi ako ng paumanhin, hindi ko alam na ikaw ay may sakit, Akala ko talaga ikaw ay isang hindi kapani-paniwala at ignorante, ngunit sa iyong isinulat lamang napagtanto kong ikaw ay talagang maling akala.
well wala, sana mas magradweyt mo ang gamot mo at makabalik sa realidad, puwersa! kaya mo!!!
Nagbasa at nagbasa at nagbasa ulit ako ngunit wala akong naiintindihan, alam ko lamang na mula nang dumating ang petsa ng Xubuntu 14.04.1, wala akong problema sa aking kuwaderno, o sa aking hp 1102 laser printer, wala akong alam sa lahat, ako ay isang gumagamit at Hindi ko alam kung ang systemd ay mas malala o hindi angkop para sa init, ngunit inuulit kong wala akong mga problema sa xubuntu. 🙂
Nagbasa, nagbasa at nagbasa ulit at alam ko lamang na may kinalaman akong isang lumang paksa. XD