Cada dia els nostres ordinadors formen una part més important de la nostra vida, si té algun tipus de problema ens afecta el nostre estat d'ànim, el nostre humor jeje. És clar, els usuaris de Windows són més propensos a atacs de pànic, que si els virus (visqui linux!), Que si desfragmentar el HDD, que si cercar i instal·lar el Clean Master per a PC (encara que aquí en Linux igual hem de netejar el sistema, BleachBit és una de les alternatives preferides). Recentment els usuaris de Linux tenim (alguns) cert mal de cap anomenat: systemd
Bé a l'gra, he llegit un article interessant sobre systemd, Que sembla ser el que està de moda des de fa no gaire.
systemd, Que a alguns li sembla com (i faré ús de paraules d'un amic), un anell per governar-los tots ... a altres simplement ni els va ni li ve, mentre l'ordinador funcioni bé, no li importa si init fa X o I cosa, o si es fa servir systemd. A aquest qui els escriu, bé ... diguem que prefereixo init, el trobo més simple 🙂
Els deixo aquí l'article:
Abans de començar he de dir que no m'agrada gens la decisió de canviar les coses en Debian però, en cap moment planatge abandonar la meva estimada espiral. Només intento que, si anem a discutir un tema, almenys ho fem el més preparats possible tot i que jo mateix no em considero pro-systemd. Per aconseguir la desmitificació de systemd em donaré suport a un lloc web on els desenvolupadors donen el seu punt de vista el qual va arribar a les meves mans per un col·lega que si sembla ser pro-systemd encara que no sigui usuari de Debian. Dit això crec que puc passar a intentar desmitificar el que es diu sobre systemd.
systemd és a força de binaris
Potser aquest sigui un dels aspectes que més ens xoquin, si tot és a base de binari com monitoritzar les coses que usualment fem a través de logs ?. No tinc ni idea de com va néixer aquest mite, però no és absolutament cert.
systemd es configura gairebé exclusivament a través d'arxius de text simple. Uns ajustos que també poden alterar amb la línia d'ordres de l'nucli ia través de variables d'entorn. No hi ha res binari en la seva configuració (ni tan sols XML). Només un simple, senzill i fàcil de llegir arxiu de text.
Aquesta cosa és monolítica i ho controla tot
Abans d'arribar a la web esmentada anteriorment confesso que jo mateix pensava d'aquesta manera però després de llegir el que diuen els seus desenvolupadors meva opinió ha canviat alguna cosa ...
Si vostè fa una build de systemd amb totes les opcions de configuració habilitades vostè construirà 69 binaris individuals. Aquests binaris serveixen per a diferents tasques, i se separen amb cura per un nombre de raons. Per exemple, s'ha dissenyat systemd pensant en la seguretat, per tant, la majoria dels dimonis corren amb privilegis mínims (utilitzant les capacitats de l'nucli, per exemple) i són responsables de només tasques molt específiques, per reduir a el mínim la seva superfície la seguretat i l'impacte. També, systemd paral·lelitza l'arrencada més que qualsevol solució anterior. Aquesta "paral·lelització" es crea executant diversos processos en paral·lel. Per tant queda vist que systemd està molt bé dividit en molts binaris i per tant els processos. De fet, molts d'aquests binariosse separen tan bé, que són molt útils fora de systemd.
Un paquet que va incloure 69 binaris individuals difícilment pogués ser cridat monolític. El que és diferent de les solucions anteriors però, és que vam enviar més components en un únic tarball, i els mantenim encadenats en un únic repositori amb un cicle de llançament unificat.
Això no s'assembla a Unix
Certament hi ha alguna cosa de veritat en això. Els arxius de les fonts de systemd no contenen una sola línia de codi procedent de les línies originals de UNIX. No obstant això, es deriva la inspiració de UNIX, i per tant hi ha un munt de UNIX a systemd. Un exemple seria la idea d'UNIX "tot és un arxiu" el qual es troba reflectit en el fet que en systemd tots els serveis s'exposen en temps d'execució en un sistema d'arxius de l'nucli, els cgroupfs. Llavors, una de les característiques originals de UNIX va ser el suport multi-seat, basada en el suport integrat en el terminal. Amb systemd vam portar el suport multi-seat de forma nativa nuevamnte, però aquesta vegada amb el suport total per al maquinari d'avui, que cobreixen gràfics, ratolins, àudio, càmeres web i més. De fet el disseny de systemd com una suite d'eines integrades que cada un té els seus propòsits individuals però quan s'usen junts són més que la suma de les parts, que més o menys en el centre de la filosofia UNIX. Llavors, la forma en que el nostre projecte es maneja (és a dir, el manteniment de la major part de l'nucli de sistema operatiu en un únic repositori git) és molt més proper a el model BSD (que és un veritable UNIX, a diferència de Linux) de fer les coses (on la major part de el sistema operatiu central és mantenir-se en un únic repositori CVS / SVN) cosa que mai va ser així en Linux.
Al final, la qüestió de si alguna cosa és UNIX o no importa molt poc. Sent tècnicament excel·lent és tot just exclusiu de UNIX. Per a nosaltres, UNIX és una influència important (de fet, el més gran), però també tenim altres influències. D'aquí que en algunes zones systemd seran molt UNIX, i en altres una mica menys.
És que això és molt complex ...
Certament hi ha alguna cosa de veritat en això. Els ordinadors moderns són bèsties complexes i el sistema operatiu que s'executa en elles òbviament també ho serà, per tant han de ser complex. No obstant això, systemd certament no és més complex que les implementacions anteriors dels mateixos components. És més senzill, i té menys redundància. D'altra banda, la construcció d'un sistema operatiu senzill basat en systemd implicarà molt menys paquets que els que fa servir un Linux tradicional. Menys paquets fa que sigui més fàcil de construir el seu sistema, es desfà de les interdependències i de gran part de l'comportament diferent de tots els components involucrats.
Això no em deixarà fer servir scripts de Shell
Això és totalment fals. simplement no els fem servir per al procés d'arrencada, perquè creiem que no són la millor eina per a aquest propòsit específic, però això no vol dir systemd era incompatible amb ells. Podeu executar fàcilment els scripts de shell com a serveis systemd o dimonis, pot executar scripts escrits en qualsevol idioma com a serveis systemd ja que a systemd no li importa gens ni mica el que hi ha dins del seu executable. D'altra banda, en gran mesura utilitzem scripts de shell per als nostres propis fins, per a la instal·lació, construcció, proves de systemd. I vostè pot enganxar els scripts en el procés d'inici d'hora, s'utilitzin per als serveis normals, es poden executar en l'última parada, pràcticament no hi ha límits.
Arribats a aquest punt suposo que algunes de les principals creences poden haver estat aclarides, tot i no sentir-me un defensor el canvi i tenir els meus recels sobre això de "un dimoni per controlar-los a tots"Crec que a la fi ningú s'atrevirà a dir que almenys no funciona, fins i tot conec alguns usuaris que noten que amb systemd" PC camina més ràpid "però ja aquestes serien altres coses que poguessin discutir-se. De moment només em resta convidar-los a debatre aquí els punts de vista que tinguin sobre el gestor d 'que moltes distribucions han adoptat encara que ara les majors reaccions s'estiguin veient dins de la comunitat de Debian, i es fins li ha nascut un nou fork amb tot això. Si agradar o no és una qüestió de cadascú, jo per la meva part només vull posar el meu granet de sorra a la desmitificació de systemd que a la fi va estar present en Jessie, la propera versió de Debian.
L'article ho vaig veure en GUTL (que al seu torn va ser pres de Des d'Abreus)
¿Actualitat de systemd?
Sóc dels que no llegeix moltes notícies quan alguna cosa genera tanta polèmica, prefereixo quedar-me amb detalls més tècnics. És que .... de vegades sento que determinats temes deixen de ser una discussió o debat merament tècnic, i passen a ser com un d'aquells xafarderies de faràndula 🙁
Primer una bronca oberta d'un usuari a systemd anomenada systemd VS intel·ligència, Després Linus Torvalds dient que systemd no és tan dolent com el pinten (i una mica de raó sí que té), Un fork anomenat uselessd ... no comments ... i per no allargar més, finalment Devuan.
No diré si és tan dolent com diuen, menys dolent o pitjor. A mi el sistema em funciona sense problemes, però per gust personal preferiria init, ja que la seva forma d'organitzar diverses coses (com logs per exemple) m'agrada més, però bé, si systemd ve a ser anomenat un cavall de carreres i ha de substituir a init (¿Seria el nostre mul de càrrega, que fa tot però lent?) Doncs ... home, mentre el canvi no sigui extremadament brusc, els usuaris es puguin adaptar sense molt problema i el sistema funcioni millor (sí, millor, potser no em val!), Doncs benvingut sigui 😀
Molt bon article, porto uns dies amb Linux Mint 17.1 Rebecca amb systemd i ho sento molt més fluid que en versions anteriors, no es molt sobre això a causa que sóc un usuari comú que aquesta aprenent sobre això però estaré a l'pendent, aquest és el primer article que llegeixo que no parla pestes de systemd.
Per alguna cosa serà el primer que llegeixes que no parla pestes d'ell i d'altra banda, cuentame, fas servir la teva Mint com a servidor ?, o sigui, no et molestaria si té un error de tant en tant no ?, és per això que fas servir Mint , i és per això que no et molesta, no t'agrada però tampoc et fot systemd. Quan tinguis errors ia causa d'això tinguis problemes seriosos en entorns seriosos, va molestar-te.
Amic, alguan distro basada en Debian Stable que em recomeindes? Podria utilitzar Debian, però cal configurale moltes coses un cop isntalado, còdecs, etc ... Com em recomanes? gràcies.
¿I com vas aconseguir ficar systemd a Linux Mint? Jo volia intentar ficar-lo però no sé si calgui fer alguna cosa addicional (al que, en teoria, ja porta Ubuntu), si tens alguna guia a l'respecte o alguna cosa que em puguis passar t'ho agrairia molt
Molt bon article. A veure si els talibans anti-systemd el llegeixen (però ho dubto)
En tot cas, d'aquí a un any els veuré usant systemd i negaran el que van dir un any enrere. Així són. Resistents a l'canvi? Segur que si.
Em consideres un talibà per no voler acceptar a systemd, doncs llavors jo et considero un talibà per no voler acceptar que jo no vull acceptar systemd. Estem a mà 😉
No obstant això segons diu a la fin dels teus articles:
«elav: Blog Personal / Twitter / G+ / Usuario de ArchLinux. Informático, melómano, blogger y diseñador web. Administrador y Fundador de DesdeLinux.net. »
és a dir, fas servir una de les primeres distribucions que va adoptar systemd.
Salutacions
Ok nen.
Sense paraules !!!!, segueix jugant, que la vida és de color de rosa.
Per comentaris com el teu, estimat Giskard, és pel que renego de systemd i del que representa.
I si després de 20 anys fent servir i treballant amb i per a Linux, sóc un talibà; doncs, així sigui.
En un any vam parlar. I ILAV, jo no et vaig esmentar. Et vas matar tu solet com Chacumbele.
A veure, que la gent llegeix i NO llegeix. Hi ha o no hi ha talibans en contra de systemd? Els hi ha! I n'hi ha de l'altre costat, dels que el defensen a capa i espasa com si fos una panacea. Que són tots els que són? No! Per res! N'hi ha que simpatitzen amb un o altre i veuen el bo i dolent tant de l'propi com de l'aliè. Amb aquests es pot parlar sense problema. Però no em van a negar que HI HA talibans. I de costat i costat. I si algú es va picar per això sense entendre que podria molt bé NO ser un talibà, llavors descans el meu cas ja que les proves els fan culpables.
Si jo diàleg amb algú sobre systemd i d'entrada aquesta persona no el crida pel seu nom sinó Systemshit o alguna cosa semblant jo voldria que em diguessin, sincerament, si és possible tenir una conversa amb tal persona que d'entrada desqualifica a l'oponent. No es pot.
En fi, cal llegir. A veure, si jo vinc i dic «és que hi ha uns eschejfhduf (paraula inventada) que colpegen nens a l'sortir de l'escola» i vénen uns quants a defensar als «eschejfhduf» no és per pensar que ells mateixos ho són?
Bé, si algú per aquí (no talibans, si us plau, i tampoc eschejfhduf) vol conversar sobre els pro i contra de init i systemd (que tots dos tenen bones i dolentes) amb gust estaré per aquí.
Salutacions.
Els talibans anti systemd? i contame, vostès que són? els talibans pro-systemd ?, per altra banda, perquè assumiu que no llegirem sinó a fer comentaris directament ?, qui és el talibà de ment tancada que no admet discussió i parla com LP :: «és el millor, confia en mi, es el que faig ». ?.
Lei tot l'article i et puc dir:
Systemd és a força de binaris: Cert
El demistificació: Falsa
LP aquesta tergiversant el que es diu, que és que el core d'systemd són binaris, molts, massa per penjar d'PID1, entrellaçats entre si fortament, tant és que et convido a que miris a #devuan com costa netejar per exemple, logind de systemd i la resta dels paquets en Debian, donada el lligat que aquesta a el sistema el logueo que reemplaça a PAM.
La configuració és escarida i no permet TOT el que no desitjaria, com, desactivar journal, atès que no pots ni matar el PID, ni aturar-lo ni res, això és modularitat ?, amb sysvinit a el menys, podies matar tot fins a quedar només amb init , el mateix upstart.
===========
«Aquesta cosa és monolítica i ho controla tot»
Ho és, més enllà de que siguin 2 o 69 binaris, s'entrellacen entre si amb dbus i així amb l'US sencer, no deixant des-relacionar-los a tots amb facilitat, el cas més clar és journald, que no pots desactivar-lo, a més, l'inici de dimonis o serveis es fa mitjançant «unitats» que són arxius de text, però res més que això, parsejats per systemd i llest, res de modificacions o hacks en serveis més enllà de l'establert.
=======
«No s'assembla a UNIX»
Ho vaig a respondre brevemete. No compleix amb la LSB, tampoc amb POSIX i avui mateix un fedora developer que ajuda a #devuan, va dir: «És cert no ho és, tampoc importa, el que importa és que pugui corrar coses que si siguin POSIX, la resta, certament no m'interessa que US o cosa sigui, mentre funcioni i tingui bones features ». I perquè hauria de ser UNIX o UNIX-like: Fes una cosa i fes-la bé, una cosa que systemd, no fa.
===========
«No obstant això, systemd certament no és més complex que les implementacions anteriors dels mateixos components. És més senzill, i té menys redundància »
Menys redundància ?, et demanen que instal ALTRE syslog per a text pla i el demanaven per logueo remot abans d'existir systemd-journald-remote, és a dir, el van treure a producció sense poder fer un logueo remot sense dependre de rsyslog manualment, alguna cosa bàsic com el logueo centralitzat. Tot i així, no té la capacitat, un simple boolean d'indicar si volem la sortida en binari o en text pla i a més, si anava a fer servir binari perquè no alguna cosa conegut com berkeley DB perquè pugui ser llegit des de qualsevol sistema Unix o Linux?
Senzill ?, realment? mirin una mica el senzill que és: http://wiki.gentoo.org/wiki/Comparison_of_init_systems
Mirin la quantitat de línies de codi i fitxers.
=========================
«Això no em deixarà fer servir scripts de Shell»
Això és fals, però de nou tergiversa, no se li critica que no permeti usar bash script, sinó que no els faci servir per a l'inici de serveis, amb la qual cosa no és modificable, hackeable i flexible com ho és upstart o sysvinit. I per hackeable em refereixo a harcodeado.
============================
Encara penses que:
1.- No tinc res de rao
2.- No lei res i sóc un talibà?
jo em pregunto ... realment cal confiar en el que diu Lennart ?, si m'ho diu algú neutral puc prendre certes coses en consideració, però això em sap igual a que Red Hat publiqui alguna cosa per defensar systemd
Vaja, fins que algú de per aquí diu alguna cosa raonable i no solament por i desinformació.
L'article és la traducció a l'espanyol del que hagi escrit Lennart ..
Sense ànims d'ofendre, però la traducció sembla feta per Googlel Translator versió beta ... 🙁 treball em va costar entendre alguns paràgrafs; de totes maneres és d'agrair la informació.
@ Charlie-Brown, és per que Lennart no sap molt bé expressar-se en anglès. Així de lleig s'entén llegint l'original.
Vàlides les raons exposades, tot i això, penso que a alguns li puguin generar més interrogants. En qualsevol cas, la meva recomanació als que tinguin l'oportunitat: acudeixin a la font original de la informació http://0pointer.net/blog/projects/the-biggest-myths.html (Malauradament per a alguns, està en anglès) que és molt més completa i arriba a fonamentar fins a 30 raons per les quals es considera favorable l'ús de SistemD.
Aquest article que esmentes està escrit pel creador de systemd. Com és lògic ningú millor que ell per defensar el seu treball, no obstant això, els convido a veure aquest vídeo http://hackingthesystem4fun.blogspot.com/2014/12/systemd-journald-centos-7-totally.html i ja em diran les seves conclusions a l'respecte. No dic més.
ILAV el tema dels Registres d'journal que estiguin en un binari és un dels punts mes criticats, fins al propi linus plantejo, quan en un reportatge on va admetre que systemd no estava tan malament. Així mateix el propi linus explico que podis crear-te un script per prendre les dades de journal i posar-los en text pla.
També systemd et permet configurar la mida de l'binari de journal disminuint els riscos d'un possible error.
realment l'art que cites és molt poc seriós, ja que no té una mica de objectivitat, i fins i tot em fa preguntar si realment és real la decisió que mostra és real o aquesta trucat (fotre el programari apropósito perquè de l'error).
tots els programes en algun moment tenen errors, però semblés que sempre li van a buscar la cinquena pota a el gat per trobar-li una cosa dolenta a systemd.
Per exemple: en debian es va decidir que systemd serà el init predeterminat, però no impedeix usar sysvinit o openrc o upstart i em diràs bo si però no es pot treure totalment a systemd, i la meva resposta seria que és el mateix que succeïa en debian wheezy on vós podis córrer openrc, systemd o upstart però sota sysvinit
PD: no em vull imaginar que bojos es posaran amb kdbus i la seva integració amb systemd a nivell de el nucli de linux http://kroah.com/log/blog/2014/01/15/kdbus-details/
Si pot ser. És més, penso retirar-me oficialment dels debats que tinguin relació amb systemd. Que passi el que hagi de passar 🙂
@rolo la decisió està documentat, se li han presentat diversos bugs reports, li presenten un vídeo i ara diuen que està trucat. Si vol estar segur segueixi els pas i vegi el que passa. Ara per aca hi ha més informació de l'assumpte, ¿Bugs inventats? No ho crec.
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 i els seus grans explicacions)
https://bugzilla.redhat.com/show_bug.cgi?id=974132
https://bugzilla.redhat.com/show_bug.cgi?id=1157350
El que esmenta el vídeo és certament curiós. Com a desenvolupador, sempre se'ns diu que un detall no hauria d'afectar tot el sistema / programa, per exemple, si falla una consulta de selecció a la base de dades, per què caldria veure caure tot el programa? És el mateix amb systemd, si falla perquè altres fallen, no sé que tan bé fet estigui. Òbviament, hi ha casos en què una fallada són pràcticament la decisió de el sistema, però com més aïllades estiguin internament les propietats de el programa, millor producte es tindrà.
Ara, atacar un programari per la seva banda feble no és nou, és més aviat una pràctica molt comuna i que de fet s'hauria de fer amb tot programa, així que veure caure a systemd pel journald, és una prova vàlida que encara systemd no és el que es diu o es va fer creure.
Com més coses es tornin interdependència amb systemd, pitjor serà la cosa. Si abans pelar un dispositiu no feia caure a sistema, pot ser que ara les coses no tinguin tan bona pinta.
Systemd no és dolent, no l'odio, però no és el que molts volen fer creure. Avantatges té, però res a Upstart no tingués o pogués tenir, és clar, Canonical ficada pel mig i ja ningú va voler posar atenció.
Salutacions.
però en aquest vídeo en cap moment es que que el sistema caigui. el tipus el que fa és modificar el binari de la info d'journal per generar la decisió, però el punt és que totes les vegades entra a systemd.
pel que entenc, si limites la mida de l'binari de journal, quan arriba a l'limiti crea un altre i així. disminuint la possibilitat de corrompre totes les dades.
És que siguem clars ... ¿A qui se li ocorreria modificar el fitxer de l'log, també? xD
@Jorgicio 4 desembre 2014 6:03 PM
És que siguem clars ... ¿A qui se li ocorreria modificar el fitxer de l'log, també? xD
Si ho vas dir en mode irònic ... tot bé, ho he entès :)), però si vas preguntar realment, dono el meu punt de vista.
Per a mi aquesta clar que no és un error, és una característica !! la idea és que si hi ha escalament de privilegis en un accés remot, seria molt fàcil per a qui accedeix a eliminar el registre simplement editant per corrompre'l i que systemd l'elimini per corrupte i així lliurar-se de ser detectat en aquest accés remot.
Diganme paranoic, però no em queda una altra manera de pensar ... no és un error, és una característica i és per això no accepten reparar aquest error.
uff ara tots els blocs de linux fan 200 articles sobre systemd a al punt que ja em conosco gairebé tots els arguments en contra ia favor xD.
i de poc m'han anat convencent alguns dels arguments anti sistemd i entre els que he vist (si hi ha alguna cosa equivocat si us plau corriganme)
per ahi vaig veure fins i tot un article sobre com fer crashear tot el sistema quan s'edita un registre binari i que aquest no dóna informacion alguna que l'arxiu està corrupte.
la manca de claredat en els logs
un equip de desenvolupament que sol ignorar els informes de bugs
per ser tan gran i incloure tantes coses dins d'un init fa molt més inestable el sistema i si a això li sumem bugs com l'anteriorment esmentat fa un sistema sense l'estabilitat que tant caracteritza linux.
es diu modular però les parts de la mateixa no poden funcionar sense altres parts de la mateixa systemd
un desenvolupament que a la llarga genera dependències a l'hora de programar fent que programari com gnome difícilment portables a sistemes sense systemd.
reemplaça parts (networkd, logind etc) que portaven anys funcionant i rebent manteniment i les canvia per unes noves sense necessitat alguna que solen tenir molts mes bugs.
De el temps que porto fent servir distros basades en Arch (Manjaro, Bridge Linux, Antergos) que òbviament fan servir systemd, he de dir que no tinc queixes respecte al seu ús i maneig. Inicia serveis és fàcil -més encara en Bridge, on el bluetooth o modemmanager vénen desactivats per defecte-. A part d'un error relacionat amb hwdb.bin (https://bbs.archlinux.org/viewtopic.php?id=189536) No he tingut molts problemes. Òbviament no crec sigui l'opinió de tots, però en el personal no tinc queixes 🙂
No m'agrada la idea que una empresa (Red Hat) acusada de col·laborar amb la NSA (portes posteriors i control d'EUA) faci un sistema amb el qual es controla tot. Un anell per controlar-los a tots, per lligar-los a les tenebres si cal ..
D'altra banda he de reconèixer que la intel IRIS PRO 5200 em va millor i ja gairebé mai, per no dir que ja no, es em trenca el sistema gràfic a l'iniciar openSUSE 13.1. I si, tot va millor, s'inicia i s'apaga molt més ràpid. Com un simple usuari m'ha beneficiat.
ressalt la part important
¿Si algú t'acusa de que vens droga automàticament sos narcotraficant?
@juanfgs
narcotraficant no ... .cómplice si.
déu ... et insultaria però les teves pròpies paraules el fan per vós.
Només aclarir que s'escriu systemd, i és així com s'ha de fer.
Ortografia
Yes, it is written systemd, not system D or System D, or even systemd. And it is not system d either. Why? Because it 'sa system dimoni, and under Unix / Linux those are in lower case, and get suffixed with a lower case d. And since systemd manages the system, it 's called systemd. It 's that simple. But then again, if all that appears too simple to you, call it (but never spell it!) System Five Hundred since D is the roman numeral for 500 (this also clarifies the relation to System V, right?). The only situation where we find it OK to use an uppercase letter in the name (but do not like it either) is if you start a sentence with systemd. On high holidays you may also spell it systemd. But then again, Système D is not an acceptable spelling and something completely different (though kinda fitting).
http://freedesktop.org/wiki/Software/systemd/
Aquí també? Això mateix ho vas posar en GUTL .. però home, tots diuen Linux i no GNU / Linux, així que amb systemd el mateix.
Et comento que no cal fer servir el sistemes de log ni el cron que proveeix systemd podis seguir syslog-ng i cronie per això o altres alternatives
jo faig servir systemd en ArchLinux des que estava en aur i em sembla mes simple de majar que la forma en debian i redhat derivades, aquest té un munt d'ordres de consola que que et estalvien editar els arxius de text i simplifiquen l'armat d'scripts de configuració instal·lació (recordin que en fitxer s'instal·la tot per consola)
I no menys important el sistema inicia ràpid, en arch es podia iniciar serveis en paral·lel a l'iniciar el sistema però erra arriscat
el que em sembla malament del tema és que la majoria pren bàndols, o sos pro-systemd o anti-systemd, i crec que té les seves coses bones i dolentes, jo sóc un usuari i em vaig posar a jugar una mica amb systemd, la veritat que les seves coses bones, l'inici és més ràpid i menys complex que la resta dels init, encara que el tema dels journal al meu també em molesta molt.
Entenc que els que realment poden dir si és bo o dolent són els sysadmins o experts en el tema però em sembla que l'enrenou de systemd fa estona deixo de ser alguna cosa tècnic i pas a ser alguna cosa mes «faranduler», per la meva part estic en una mica en contra però no em considero anti o pro
@KZKG_Gaara
Veig que molt que el que comentes aquí és el mateix que Lennart ha publicat al seu bloc més precisament en aquesta entrada: http://0pointer.de/blog/projects/the-biggest-myths.html.
És clar el post ha tingut certes «aclaridores» i ha deixat de banda cert contingut tècnic, per tal de ser una informació fàcil de pair per a qui la vagi a llegir, però serem seriosos i sincers, per més que faci mal la veritat: systemd té moltes de les coses que Lennart nega no té, això i molt més en realitat. I en aquest sentit explico per part.
1.- Lennart diu que no és bloated i que no té un alt síndrome de NIH (Sindrome de Not Invented Here). Si és així si us plau que algú m'expliqui: Per què un init ha de tenir control de xarxes (systemd-networkd), dns (systemd-networkd), m-dns (systemd-networkd), logs (journald), coredumps (systemd -coredump), debugs (systemd-coredump i journald), acpi (logind), escalat de privilegis (logind), control de ntp (systemd-timesyncd), control sobre dev (systemd tom tota la funcionalitat de udev), control de / dev / random (generador de nombres aleatoris) i el més recent control sobre TTY (systemd-consoled)? És que ja no havien MOLTES eines creades per a tals fins com perquè systemd ara sumi les seves algunes amb accés exclusiu (cas journald)? Quina explicació lògica i acceptable em dóna al fet que un init sigui capaç de trencar el debug i la cmdline de el nucli? A això Afegeixin el control sobre kdbus, el proper IPC que serà integrat a l'nucli. Segurament em diran aca: «Però et pots instal·lar una altra eina per controlar tot això». I si és cert, però, moltes d'aquestes eines només reben un stream de dades llançat per systemd, com el cas de syslog i rsyslog manualment, els quals es connecten a un data / stream que journald proveeix perquè altres eines puguin VEURE el que journald maneja, a la fi, això només vol dir que tens dues eines que fan el mateix, i una d'elles és una caixa de pandora. (Per favor que no em diguin que el codi es pot auditar, perquè convido a que algú pugui «fumar-se» el codi de journald i el seu entramat amb systemd i altres eines relacionades)
2.- Lennart també ens diu que systemd ofereix suport per a SysV i LSB scripts. Això és una «mitja veritat» un «mentida blanca» per així dir-ho, perquè la veritat és que systemd-214 no està traduït a bash scripts ni SysV ni LSB i això està relatat en el seu Release notes per a aquesta versió.
3.- Què systemd no és portable? És un altre punt discutible. En BSD no funciona doncs bé, en BSD no hi Cgroups entre altres eines que systemd necessita per a la seva execució. Però és per una raó de disseny de systemd, no perquè no sigui portable. Fins que el nucli BSD no compleixi el que mínim per suportar-ho, systemd no funcionarà en aquesta plataforma i això no és culpa de ningú, només que BSD no té interès, ni Lennart tampoc. Així de simple és. Ara, el suport a altres llibreries C, és una altra cosa, ben coneguts són els problemes de glibc (només cal fer-se un nucli a mà per veure la quantitat d'opcions i workarounds que s'han fet per evitar aquests detalls sobretot per glibc 2.3, 2.5 i 2.11, entre altres falles que glibc ha arrossegat al llarg dels anys) però la cosa no acaba allà no acaba la cosa, Lennart mateix ha dit que ha preferit crear-se la seva pròpia llibreria libc, perquè per al seu grup això és molt més ràpid fer-ho així, que caminar llegint codi ja creat (i documentat per cert), però no s'atura allà, pensen treure glibc, i utilitzar la seva libc no només per systemd, sinó també per a Fedora tornant estàndard per a la construcció de tots els seus paquets. NIH On? Sembla que el bon Lennart li agrada trollear ja en gran.
4.- Que systemd no és monolític perquè està partit en 69 binaris. Si bé, això és discutible. systemd té 69 binaris, que fan diferents tasques, però aquests binaris passen la informació de les seves tasques a systemd, així que si un falla, les probabilitats de trencar el sistema, augmenten de manera força dràstica. Això està ben documentat, en els bugs reports abunden problemes com aquests i fins i tot problemes més senzills, estupidamente senzills en realitat. systemd pot estar partit en centenars binaris, però mentre el seu nucli sigui el que porti el control, el risc d'un break es manté i augmenta, i si no em creuen, llegeixin els bugs reports i divertiu-vos.
Fixeu-vos que aquí no he comentat res que systemd sigui escombraries, només he fet comentaris merament «tècnics» (òbviament parlar de tecnisimos la cosa es posa molt complexa) i vàlids, recolzat per informació fàcilment accessible per internet. Ara bé: ¿Què Linux necessita un init estandar? Si certament seria una cosa de gran valor per a la comunitat. Què systemd és la solució? No, tot i que està a prop, certament té moltes coses positives, però la seva expansió viral i la quantitat de coses que fa augmenten el risc del que pot sortir malament i acabar perjudicant la comunitat.
PD: Els deixo material on poden corroborar el que dic, llegiu-lo els resultarà bastant il·lustratiu, i vegin que no incloc blocs ni res per l'estil, pura critica personal i amb base. Salutacions.
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 potser et sentis identificat)
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
Amén germà .. a més ..
Segueixo sense veure raons vàlides per no adoptar systemd. Simplement interpretes el que veus amb por, resultant en exageracions. Ni avantatges ni desavantatges clares i ben definides.
A més aquesta integració permet la estandarizacion de la qual fins i tot vas parlar. No només Red Hat treballa en systemd, sinó diferents empreses i voluntaris d'altres distribucions.
Crec que l'error és que no s'estudia adequadament el funcionament de systemd.
Jo sí que veig raons vàlides en l'anàlisi de Yukiteru. Fixa't que en lloc de por jo veig rigor, precisió i claredat. Ha de ser un tema d'oculista.
No és por (no li tinc por a una peça de codi) i tampoc són exageracions (tot el que he dit aca està documentat i he passat bastant informació que la corrobora, informació que per cert surt de les llistes i de la ment / veu / puny / lletra de l'propi Lennart, i no dels comentaris d'un blogger), és lA REALITAT.
systemd fa tot això i molt més, i això és una cosa PREOCUPANT (concepte diferent a tenir por) perquè certament es pren atribucions i fa coses que a hores d'ara es pot fer per altres mitjans i que per cert funcionen millor i són més estables. systemd és molt Windows-like, i això no es pot amagar, només n'hi ha prou conèixer el que userinit.exe, svchost.exe, smss.exe i altres dependències fan i comparar-les amb systemd, la semblança és tan gran que dóna mala espina. Ara bé, certament systemd pot tenir una millor qualitat que la seva contrapart en Windows (o pot passar el contrari, ningú ho sap en realitat, tret que programes per a Microsoft) però no em pots acusar de EXAGERAT i poruc quan llegeixes a el mateix Lennart en una llista, parlant de crear-se tot una nova llibreria C, perquè està fart de glibc, i per Napa, llançar la petita i insignificant punta, que aquesta libc pugui ser usada per construir tots els paquets de Fedora. I si penses que és una mentida i que sóc exagerat et deixo el missatge en aquest enllaç: http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html (En anglès)
Ara digues-me si és exagerat dir davant de totes aquestes coses, que una vegada que Linus decideixi que CONFIG_VT tal com està, ha de sortir de l'nucli (situació que porta a la palestra força temps) i passar-lo a userspace, no succeeixi una cosa boja com que systemd-consoled sigui dependència forta per a gairebé qualsevol instal·lació de Linux (alguna cosa ha de manejar les VT no creus?), això no posaria a diferents distros no-systemd en el punt de mira per forzarlar a canviar. Si penses que això és exagerat, dejame dir-te que no tens ni idea del que Lennart és capaç de fer i està fent, ja que els seus últims canvis afecten el desenvolupament de l'fork de udev, eudev de Gentoo, i seguirà fent-amb les seves amenaces per sota la taula (per després queixar-com ho va fer a Google+)
@xiep no puc estar més d'acord amb el teu comentari.
Che Yukiteru, el teu extensa declaració omet el fet que el mail que linkeaste sobre libc és una broma de april fools, mira l'footnote i mira la data (31 de març, probablement 1 d'abril a l'timezone de Lennart)
Practica el teu english-fu perquè fa aigües i posa en dubte tota la teva «investigació».
@juanfgs sembles l'únic que llegeix, al menys això t'ho aplaudeixo, però et mancat llegir alguna cosa molt important que està en el meu comentari, no importa t'ho poso aquí:
»NIH On? Sembla que el bon Lennart li agrada trollear ja en gran. »
No crec que l'hagi escrit per una raó innocent, coneixia el fet que era una altra broma de l'Lennart per April s Fool Day (mal humor), a l'igual que la seva passió per convertir /, / etc i tota la resta en / Linux. 🙂
PD: Gràcies però no necessito practicar el meu anglès, porto amb l'idioma des dels 6 anys
Aaahh i tota la resta és veritat, verificalo 🙂
Això és sensacionalisme pur i dur, dieu que et bases en fets però en realitat seguiu el teu pressentiment que el tipus és dolent i vol dominar el món i torcés els fets perquè reflecteixin el teu discurs. Això és el que em molesta molt de la gent anti-systemd, no tenen pèls a la llengua a l'hora de torçar els fets i comptar mitges veritats, carregades de la vostra opinió és clar.
El meu «rule of thumb» davant aquests casos és simplement el següent desglossament lògic, partint de la premissa que
- sóc desenvolupador web / apps d'escriptori o cli
- no he escrit mai un sistema d'init.
- no sóc mantenidor d'una distro.
verificar si l'interlocutor ha:
- creat un sistema d'init
- és mantenidor actiu de sistema d'init d'una distro
i la realitat és que la majoria dels anti-systemd no passen aquesta prova, tot i així són un grapat de gent que per algun motiu SABEN MÉS que la gent darrere: Debian, Fedora, Archlinux, el nucli Linux, tot el projecte GNOME, probablement el projecte KDE també ja que no s'han queixat systemd, SUSE, i un llarg etc.
Tot i així el seu discurs verinós i corrosiu l'únic que aconsegueix és generar desunió, problemes i altres. Tal és el punt que no veig l'hora que finalment es passin a BSD com vénen amenaçant des Xorg, NetworkManager, PulseAudio i no sé si per pur desconeixement tècnic o perquè es quedarien sense que queixar-se no ho fan.
@juanfgs, li prenc la paraula específicament en això:
«I la realitat és que la majoria dels anti-systemd no passen aquesta prova, tot i així són un grapat de gent que per algun motiu SABEN MÉS que la gent darrere: Debian, Fedora, Archlinux, el nucli Linux, tot el projecte GNOME , probablement el projecte KDE també ja que no s'han queixat systemd, SUSE, i un llarg etc.
Tot i així el seu discurs verinós i corrosiu l'únic que aconsegueix és generar desunió, problemes i altres. Tal és el punt que no veig l'hora que finalment es passin a BSD com vénen amenaçant des Xorg, NetworkManager, PulseAudio i no sé si per pur desconeixement tècnic o perquè es quedarien sense que queixar-se no ho fan. »
Llavors SEGONS vostè, tots els anti-systemd som uns ponzoñosos i càustics que l'únic que aconseguim és desunió, problemes i altres. Deixeu-me dir-li que aquesta és la barbaritat més gran que he pogut llegir per aquí. Jo no sé perquè es molesten els pro-systemd, quan se li treuen a la llum els problemes estructurals d'un sistema, que òbviament en algun moment els afectaran, perquè pot ser que no els hagi passat res ara, però en algun moment, el farà, i llavors algun anti-systemd els recordarà les paraules que moltes vegades van dir i ningú els atur, i pot ser que algun altre anti-systemd els d'una mà.
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.
Ara de canviar-me a BSD, és possible, però només ho faré si systemd es torna una cosa tan virulent que no em permeti fer ús d'alguna altra opció, mentrestant em quedo a Linux, desactivant tota aquesta bogeria, incloent moltes de les coses de Cgroups .
!=
Novament torcés les paraules perquè s'acomodin al teu discurs. Sos molt bon material per polític / periodista.
Aclareixo, el meu problema no és conque esmentin problemes tècnics de systemd, el punt que és que moltes vegades estan carregant el seu discurs amb mentides a saber d':
Que si systemd et va a obligar a fer servir un servidor microhttpd (el qual és un mòdul opcional NO instal·lat per defecte), que si systemd és un sol binari, que systemd serà tancat perquè a Lennart li paga Microsoft, que els logs binaris són obligatoris. Que ningú vol a systemd i la seva adopció és per un lobby polític.
Això és el que xoca, les mentides. Si fos una discussió raonable valdria la pena, però és només FUD de l'bo.
Que no t'agradi em sembla perfecte, al meu molt programari no m'agrada, fins i tot llenguatges de programació, distros i altres, però no invent coses sobre això ni sóc obseqüent llegint el que vull llegir i carregant les meves declaracions amb sentiments personals per perjudicar la imatge de gent que el desenvolupa.
@juanfgs ho sento, però jo no sóc el que diu »verinós i corrosiu» a un determinat grup de persones simplement per no agradar-una peça de programari.
Novament, torçant frases per quedar com a víctima.
@juanfgs novament li dic, això ho va dir vostè, revisi les seves paraules, jo no camino tergiversant les seves paraules, només vaig fer un copy / paste de les seves paraules en el comentari 59.
Estic citant meu comentari textual capo, el qual has de llegir de nou ets tu perquè no querés comprendre, o no saps debatre. Vós treus de context coses i les interpretes com se't canta. Així que si vols triar viure en un món on et sentis insultat perquè rebaten els teus arguments, Lennart, xarxa hat i Microsoft estan perseguint és perquè vós trieu creure això.
Curt aquí perquè m'adono que no sos una persona raonable perquè no querés entendre, querés interpretar les coses com a vós et sembli.
Si vols ofendre't ofendete, però és el teu problema no de la resta de món.
@juanfgs no em molest pels teus comentaris, la veritat no veig raó, estem discutint, la gent civilitzada discuteix sense necessitat de molestar-se per a això (això és el que penso).
Ara si a vostè li agrada etiquetar, prejutjar (o com vulgueu) a la gent pels seus discursos o accions (potser hagi de llegir-se el meu comentari el # 64 i mesurar l'amplitud d'ell mateix), aquest és el seu problema, limiteu-vos a realitzar aquestes accions cap a vostè mateix i deixi als altres fora d'aquest sac.
Salutacions.
«La majoria dels anti-systemd», «gairebé tots», «tots», «alguna part dels anti-systemd» ... ens desviem, Mariano, ens desviem. En el cas que ens ocupa: Jo no veig per cap costat que Yukiteru hagi fet un discurs sensacionalista i basat en pressentiments (referir-se a la seva anàlisi d'aquesta manera sí que té una mica de retorçat), a canvi, ha desenvolupat sòlids arguments sobre els inconvenients de systemd basant-se en preguntes apropiades i material extret de llistes de de correus i seguiments de bugs (a més de forma educada i civilitzada). Possiblement per aquest motiu irrita alguns i l'ataquen a el primer comentari, per desacreditar-lo i desqualificar-(aquest cop sí, de manera verinosa).
Si tu veus que el discurs de la majoria dels anti-systemd és verinós i corrosiu, jo el que veig en el discurs d'alguns pro-systemd (no sé si són majoria o minoria) és histerisme i persecució dels que, precisament, s'exposen sòlids arguments entre tant de soroll. Això a la meva terra en diem fustigar la dissidència.
¿A vostè li va bé systemd? Fantàstic, em sembla bàrbar, però deixi als que no pensen el mateix expressar les seves reserves (potser no treballin de la mateixa manera el sistema operatiu).
Salutacions
Ah per cert ¿per que qualsevol error d'systemd és engrandit fins al punt de malbaratar tot el component, però d'altres com GCC, glibc o fins i tot el nucli no han estat criticats fins a aquest punt per molts dels seus errors?
Tu mateix ho has dit, glibc arrossega problemes des de fa temps. LLVM amb el temps ha demostrat tenir avantatges respecte a GCC. I aqui no veig la mateixa critica.
¿Per que no fer el mateix amb altres projectes?
Simplement és por col·lectiva i irracional per a mi.
Glibc té els seus errors ningú pot ocultar-los, hi ha falles enormes, de glibc que afecten el nucli ja centenars d'executables. La diferència entre Glibc i systemd, és que el primer és una base de la qual es poden transformen MILERS de projectes de programari en binaris, mentre que systemd és un init, el fi és ser una peça estable, provada i pràcticament infal·lible. No només això, Glibc s'ha d'ajustar a centenars de diferents arquitectura de maquinari (CPU), a diferents flags d'optimització i característiques úniques de l'CPU, a diferents formes d'optimització de programari, un treball molt més ardu i difícil que el de systemd, així que no veig de veritat cap forma de presentar a la mateixa escala una comparació entre els dos projectes.
El mateix va per GCC, GCC és un compilador que per cert suporta molts llenguatges (13 en total comptant els no oficials), i té característiques molt semblants a Glibc, suportant moltes arquitectures (70 arquitectruras per a la versió 4.9), flags d'optimització binària , flags d'optimització per CPU, i moltes altres característiques. Ara bé estan a el mateix nivell de dificultat, un compilador amb un init. La resposta és més que òbvia, començant amb que systemd està en C, i molt del codi de GCC està en assembler o ha de fer servir assembler perquè les coses puguin funcionar en binari, alguna cosa una «poc dificl de fer».
Què tenen errors GCC i Glibc? És clar. Fins Linus els ha donat el seu atac, però en GCC i Glibc tenen alguna cosa positiva que en systemd s'obliden moltes vegades, i és que, bug reportat, bug vist, error arreglat.
- si us plau que algú m'expliqui: Per què un init ha de tenir control de:
xarxes (systemd-networkd),
dns (systemd-networkd),
m-dns (systemd-networkd), l
OGS (journald),
coredumps (systemd-coredump),
debugs (systemd-coredump i journald),
acpi (logind), escalat de privilegis (logind),
ntp (systemd-timesyncd),
dev (systemd tom tota la funcionalitat de udev),
de / dev / random (generador de nombres aleatoris)
TTY (systemd-consoled)?
Un tema 100000 repetit i repetit, el que et mancat dir és que systemd pot funcionar sense ells, de fet en debian no estan ni la meitat dels que esmentes
igualment només és una característica del seu ampli enfocament
Lennart: Bé, systemd divideix el que ha de fer en molts components diferents (90+ binaris aquests dies). Cada un es corre amb les menors privilegis possibles.
M'imagino que això no és massa diferència coreutils, que també té una gran quantitat de components en un sol paquet. I coreutils probablement és un dels principals projectes que fan que Linux se sent com un sistema operatiu similar a UNIX, oi?
Però sí, systemd és més complex que sysvinit, no hi ha dubte. En els últims 40 anys de la computació moltes coses van canviar, i molts d'ells en realitat requereixen un cert nivell de complexitat de tractar amb ells ... Hi ha molt poca forma d'evitar això.
Perquè no et poses així d'intransigent amb freebsd que fa exactament el mateix però amb les seves eines i sense permetre que es facin servir altres, cosa que no és el cas de systemd.
- És que ja no havien MOLTES eines creades per a tals fins com perquè systemd ara sumi les seves algunes amb accés exclusiu (cas journald)?
No negaré que el tema de journal guardi la info a un binari és el més fluix de defensar, però no és la fi de l'món, es poden guardar en text pla
- Quina explicació lògica i acceptable em dóna al fet que un init sigui capaç de trencar el debug i la cmdline de el nucli?
Mmmmmmmmmmm ...................... trencar el nucli ....... 5000000 coses poden trencar el nucli
- A això Afegeixin el control sobre kdbus, el proper IPC que serà integrat a l'nucli.
Segons Lennart Això té relació positiva per als desenvolupadors i systemd va portar eines per obrir dbus als administradors, també els donarà a periòdic ia networkd interfícies de bus
- Segurament em diran aca: "Però et pots instal·lar una altra eina per controlar tot això". I si és cert, però, moltes d'aquestes eines només reben un stream de dades llançat per systemd, com el cas de syslog i rsyslog manualment, ... .. això només vol dir que tens dues eines que fan el mateix, i una d'elles és una caixa de pandora. (Per favor que no em diguin que el codi es pot auditar, perquè convido a que algú pugui "fumar-se" el codi d'journald i el seu entramat amb systemd i altres eines relacionades)
aquí entrem en la teoria de la conspiració !!!!! és programari lliure flac no s'oculta res
3.- Què systemd no és portable? És un altre punt discutible. En BSD no funciona doncs bé, en BSD no hi Cgroups entre altres eines que systemd necessita per a la seva execució. Però és per una raó de disseny de systemd, no perquè no sigui portable. Fins que el nucli BSD no compleixi el que mínim per suportar-ho, systemd no funcionarà en aquesta plataforma i això no és culpa de ningú, només que BSD no té interès, ni Lennart tampoc.
Bé això no és d'el tot correcte, els desenvolupadors de bsd de fer alguna cosa semblant a systemd cosa que el propi Lennart destaco al seu compte de g +
https://plus.google.com/115547683951727699051/posts/g78piqXsbKG
https://www.youtube.com/watch?v=Mri66Uz6-8Y
4.- Que systemd no és monolític perquè està partit en 69 binaris. Si bé, això és discutible. systemd té 69 binaris, que fan diferents tasques, però aquests binaris passen la informació de les seves tasques a systemd, així que si un falla, les probabilitats de trencar el sistema, augmenten de manera força dràstica. Això està ben documentat, en els bugs reports abunden problemes com aquests i fins i tot problemes més senzills, estupidamente senzills en realitat. systemd pot estar partit en centenars binaris, però mentre el seu nucli sigui el que porti el control, el risc d'un break es manté i augmenta, i si no em creuen, llegeixin els bugs reports i divertiu-vos.
Si aquestes usant sysvinit i se't trenca TTY dev acpi ntp se't trenca el sistema també, no sembris el terror.
Monolític és freebsd i no dieu res
@rolo
Ara enumérame quines són les distros que van prendre systemd i van crear aquests 90 binaris en paquets separats, serien 91 paquets amb systemd.
I que a l'instal·lar systemd no em demani cap d'aquests 90 paquets com a dependències.
De debò, i novament insisteixo ... .per favor Pásame les opcions de l'-configure-help que vull fer-me 91 paquets compilant a mà amb make.
No hi ha pitjor cec que el que no vol veure ... nois això és l'aigua i l'oli, sembla que encara hi ha gent tossuda que no veu la realitat del que persegueix redhat.
@rolo jo vull que et instal systemd ia part li treguis journald, systemd-udev i coredump, i facis servir opcions com eudev i syslog directament, a veure si podis.
No em va poder donar mes riure aquest comentari de debò, estic que em moro. 😀
Ja seriosament, en veritat es prenen la molèstia de llegir una mica, en lloc de seguir amb la biga en l'ull.
A més que ningú s'oblida que Kay Sievers, no només va trencar el cmdline de el nucli, sinó que volia callar, després de tot «genèric és genèric».
O sigui, que segons tu, el fet que dos processos es passin informació els fa tan acoblats que el fet que un falli fa que l'altre tingui altes probabilitats de fallar ... de què teoria de desenvolupament de programari vas treure això? Estic d'acord amb @pamp que parles des de la por irracional i esbiaixat.
I la teva altra gran interrogant, per què systemd ha de controlar tantes coses? Resposta senzilla: perquè amb sysvinit i tots els altres init s'estan desaprofitant avantatges introduïdes recentment en el nucli Linux que mentre ningú les posi en ús en espai d'usuari hi són «mosqueadas» (com diem a Cuba ... vaja, desperdiciándose) sense que ningú les faci servir i donen boníssimes avantatges en l'ús eficient de recursos de maquinari (CPU, RAM, i / O, etc.) entre elles cgroups. El que fa systemd és, precisament, posar aquestes bones funcionalitats el nucli Linux a el servei de l'usuari, però per a això necessita ser ell qui iniciï a aquests dimonis.
Crec que leiste i analizaste malament (analitzar és important) o simplement ni tan sols et vas donar l'oportunitat de fer això. Que dos processos es passin informació no és raó perquè faci fallida un sistema, però, quan tens binaris amb acció dinàmica com a control de xarxa, logs o coredump, passant informació directament a l'init, les coses poden anar malament i aniran malament, perquè si uns dels binaris es trenca les probabilitats de fer fallida a la resta són molt més grans, i això és una cosa bastant realista, i ha passat, el trenqui de l'cmdline de el nucli recentment, els problemes amb acpi que els devs de Nvidia van tenir gràcies a systemd-212 , tot això és una mostra del que dic.
@Dariem
Si no es pot compilar cada un d'aquests binaris en paquets individuals, estàs forçant que per voler un instal·lat, has d'instal·lar tots, a l'instal·lar-los a tots resulta que et trepitja altres paquets que no es podran instal·lar perquè hi ha les parts de systemd ocupant aquests llocs.
Que sentit té partir un executable gran en diversos executables més petits si a la fi no tenes un paquet per cada un que et permeti instal·lar individualment.
Torno a fer la comanda general a tot usuari avançat de systemd, que em digui com compilar aquests 90 mòduls i crear-me 90 paquets que si es em donen les ganes dels instal i sinó ús dels programes que venia utilitzant.
Molt mala llet tot això ... .pareciera que a l'gent de systemd ens creu ximples a tots els usuaris de gnu / linux.
Que consti, ús gentoo testing i fa uns mesos m'havia canviat a systemd i no vaig poder amb journald, això em va fer tornar a openrc mes ràpid que el que demori a passar-me a systemd.
Per seguir veient com va la cosa amb systemd tinc ArchLinux en una notebook que aviat pasere a gentoo ... .estable segurament.
@anonimo, jo només vull veure com evolucionarà el tema de les TTY a Linux. Quan el codi de CONFIG_VT surti, a favor de dividir VT en dues parts ben diferenciades (kernelspace i userspace) necessitarem alguna eina per controlar les VT des userspace i allí systemd-consoled pot jugar en ser una dependència forta que hale a la resta de les distros a la necessitat d'haver d'instal·lar els components de systemd, tan sols per fer possible que el sistema pugui funcionar. Això que dic no és una exageració, és una, possibilitat molt, molt gran, i realment preocupant. Hi ha altres projectes, com KMSCon, però si la majoria dels escriptoris i distros es van en favor de systemd, coses com KMSCon poden morir més ràpid del que molts pensen.
@Yukiteru 3 desembre 2014 8:49 PM
Jo no li tinc por a això, don Linus no va a treure les opcions per defecte d'una versió per a una altra, posarà el nou sistema com NEW i permetrà triar entre el de sempre i el nou.
Pel que fa a la part de l'userspace, es podrà fer un paquet que faci això de forma independent, si ho fa systemd, perquè no ho podrien fer altres 50 més ?, és més, les diferents maneres de fer-ho va a fer que les diferents terminals adoptin diferents maneres totes amb uses per activar i desactivar com ja estem acostumats.
El mateix va per kdbus, que Linus ho admeti al 3.19 com es aquesta dient, no vol dir que un ho va a haver de tenir actiu si o si.
Sóc molt feliç amb OPENBOX + compton, els escriptoris per la meva poden anar desapareixent que no m'estan per afectar en el mes mínim.
@anonimo la qüestió és que treure CONFIG_VT és una cosa que a la fi serà total (pel que he llegit), és a dir, en el nucli només quedessin les primitives, mentre que la resta de l'eines estaran en userspace, això no és dolent, a contra li tragués un munt de codi vell a el nucli, ho farà més senzill de mantenir, i molt més configurable (suport complet KMS / DRM per a consola). Certament a del principi, hi haurà els dos sistemes, però en el llarg termini (15-20 llançaments) possiblement surti de l'nucli, o fins i tot abans, moltes eines ja no suportin aquest codi en favor de codi més nou i amb millor suport.
Ara bé, el teu dius que si ho fa systemd, perquè no ho poden fer 50 més (imagino 50 aplicacions més). Doncs bé, si veiem les dependències forts de KMSCon (el projecte més vell en aquest sentit) són libudev (codi que serà unit a systemd properament, no serà suportat i tindrà conflicte amb systemd si funciona per compte propi), libdrm, libxkbcommon, libtsm i el mateix systemd per gestionar multi-seat, llavors quan veus això, t'adones com la cosa va prenent forma a prendre per si res més, un munt d'eines necessàries perquè un SO GNU / Linux funcioni sense problemes.
@Yukiteru 3 desembre 2014 9:46 PM
Aquí a gentoo libudev és un virtual apuntant a sys-fs / eudev, així que la gent de gentoo s'encarregarà de modificar eudev per complir amb l'API que dicti el nou sistema en el nucli.
Per això crec que les distros que no siguin systemd (hola devuan) faran servir si o si eudev.
Va a passar el que va passar amb el udev original, systemd s'ho va engolir, però aquí el nucli és el que dicta l'API per fer d'interfície amb les consoles usant DRM / KMS ... .ja quisera veure una urxvt utilitzant això ... jeje
El que si et accepto és que el que aquest usant systemd, no tindrà opció a canviar res ... imposició plena i dura i com vaig dir abans ... a plorar a l'cementiri.
@anonimo certament el que dius és l'altra possibilitat, eudev prendrà més força en aquest sentit i mantindrà obertes les opcions a triar diferents eines.
PD: Com dius seria interessant veure com com les VT prenen els avantatges de KMS / DRM juntament amb fbdev 😀
Has repetit exactament el concepte que et vaig criticar, perquè en cap moment vaig parlar de sistema, vaig parlar de comunicació entre processos, i torno repetir, d'on treus que perquè dos processos es comuniquin, la mort d'un implica que l'altre té àmplies possibilitats de morir? Explicame com dos processos, que resideixen en espais de memòria separats, poden incidir mútuament un en el comportament intern de l'altre. A veure si m'explico, des del punt de vista d'un d'aquests processos, tot sol està accedint a un mecanisme IPC (el que sigui que es va definir per comunicar als processos de systemd). Si el programador va ser tan dolent per no incloure codi que pugui lluitar amb entrada i sortida no esperada, això és una altra cosa, però no té res a veure amb que un processos influeixi en el funcionament intern d'un altre. Si systemd-networkd cau, no ha de tombar ni a journald, ni a systemd, com mateix amb el vell sysvinit el fet que caigui inetd no hauria afectar-lo, són processos separats.
@dariem pas a explicar de forma senzilla a veure si agafes la idea:
Això que dius certament és el comportament que sempre s'espera dels programes i processos modulars. La modularitat va ser implementada amb aquesta fi, el de separar dos processos i que aquests ocupin els seus propis espais de memòria, i que es comuniquin per algun mitjà (IPC, etc), perquè en cas que alguna cosa vagi malament, llavors res dolent passi i el sistema pugui seguir funcionant sense interrupció. Una teoria que certament ha tingut gran suport per la seva potencialitat i a l'immens marge de fiabilitat que li ha donat a la computació actual. Ara bé, això no sempre es compleix (la vida no sempre és bella), i crec que segurament has estat víctima d'aquests successos en una o altra ocasió (això segurament va per tots sense importar el SO que usi), i vaig a donar un parell d'exemples.
El primer va amb Xorg (que és un procés modular tal qual systemd), que de vegades li dóna la bogeria amb algun driver i simplement crashea i et deixa sense gràfics, mentre que la resta de sistema segueix funcionant tal com s'espera (Beneïda modularitat 😀). Fins aquí tot bé, la nostra teoria que els processos modulars no ha de trencar el sistema va bé. Però (sempre hi ha algun però) de vegades a Xorg li dóna una mica més que bogeria i per alguna raó estranya (que pot anar des del control de l'ratolí fins al driver gràfic) no només es crashea Xorg, sinó que també et dóna el més bonic dels nucli panic (i una pintada al monitor qual Picasso) que puguis imaginar, i llavors te n'adones, que sense importar que tan modular sigui, si un procés es intercomunica i intercanvia informació / dades amb un altre, i alguna cosa surt malament en un d'ells, i per alguna raó, no es pot gestionar l'error de forma correcta, les probabilitats que els processos en qüestió es vegin afectats augmenta, pel simple fet que les dades són errònies o simplement són corruptes, i llavors ve la catàstrofe.
Si pensa que això no pot passar, li deixo uns bugs reports (un és meu en Debian i té parell de fotografies) d'un error vell que està en Xorg, taula, nouveau i el controlador drm / km de el nucli, processos que malgrat d'executar-** separats i ser modulars **, junts no es porten molt bé, al menys no sota aquestes circumstàncies.
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
Ara l'altre exemple es el vaig a trobar systemd. El nostre vell sysvinit tenia una peculiaritat de que malgrat ser vell, era molt fiable, fins al punt en què si el teu / etc / fstab tenia una entrada d'una partició (no important per al sistema, entiendase 160 / mnt / DiscoXNUMXGB) i està no podia muntar per alguna raó, simplement el muntatge s'ometia, et donava un missatge d'advertència, i seguia amb el procés de booteo. Ara bé, systemd és un altre cantar, malgrat la seva modularitat, si tens una entrada a / etc / fstab i systemd per alguna raó veu que és impossible muntar-la, no només es queda esperant que la partició estigui disponible (el comportament normal programat) per al seu muntatge, sinó que si el temps acaba, el teu sistema queda detingut i no pots fer res més que entrar a manera recovery i treure aquesta línia del / etc / fstab, alguna cosa bastant fail en realitat. Aquest detallet no més durant el automuntatge al boot, i tot el procés s'atura, al principi (systemd-) el detallet era més lleig, perquè simplement et apareixia volcat i tenies de reiniciar. T'ho diu algú que pas pel detallet.
Un altre exemple que puc donar és coredumpd en systemd. coredumpd per defecte passa tota la seva informació a journald amb la finalitat que aquest últim escrigui en disc la informació captada, fins aqui tot bé, estem fent servir la modularitat de systemd al nostre favor. Però passa de vegades, en què els coredumps són molt grans, simplement tan grans, que poden ocupar diversos GB, i en el procés de passar informació des coredump a journald i després a el disc, passen coses tan estranyes com que Xorg deixi de funcionar i fins i tot nucli panics. Això no només passa amb systemd és clar, però la forma en com està dissenyat, augmenta el factor de fallada i crea altres detalls desagradables (entre ells l'augment de consum de memòria, corrupció de logs, dumps incomplets), qui hagi hagut de treballar amb un coredump del KDE, segurament ha passat per diversos episodis com aquests, i hi haurà entès la importància de tenir l'opció sync en el / etc / fstab per a la seva partició de buidatge, i segurament odiarà el fet que no pugui usar alguna altra opció per manejar els dumps, si té systemd instal·lat. Un exemple del que pot passar amb systemd-coredumpd.
https://bugs.archlinux.org/task/41728
Ara bé, per culminar:
No se suposa que són programes i processos modulars ?. Si, són modulars. El nucli és l'únic monolític del que he parlat aquí, però, aquest accepta mòduls tambíen (LKM), per la qual cosa vindria a ser, una mena de nucli híbrid encara que la seva forma de disseny base no està pensada en aquest tipus d'estructura, i això ho fa una mica inestable sota certes circumstàncies.
¿Què la modularitat no hauria de permetre fer que els meus processos i el meu sistema no es trenquin si alguna cosa surt malament? És cert, la modularitat és una mesura pensada en aconseguir un alt grau d'estabilitat i fiabilitat, però no és una mesura 100% infalible, perquè si alguna cosa pot sortir malament, simplement sortirà malament, per molt modular que sigui, aquesta una realitat.
Què systemd ha de tenir control de tot per fer possible l'ús de cgroups i altres opcions agregades a el nucli? Completament fals. Això no és necessari de el tot, systemd es va poder haver quedat amb una interfície per controlar l'arrencada i assignació de cgroups als processos i dimonis que estaran en el sistema, sense necessitat d'apoderar de la quantitat de serveis que ara té, i el millor exemple d'això és; que OpenRC també és capaç d'usar cgroups i no per això és tan invansivo per dur a terme aquesta tasca.
Què sóc esbiaixat i donat a la por quan parlo de systemd? No tinc ni idea d'on treu això, perquè com veu la meva resposta no tinc por d'això, només parlo d'aspectes que no m'agraden de systemd i ja, sense basar-me en les opinions de tercers.
Per últim, vostè diu que: «Si el programador va ser tan dolent per no incloure codi que pugui lluitar amb entrada i sortida no esperada, això és una altra cosa ...»
Certament dir que el programador per no incloure un codi que manegi TOTS els formes possibles en què el seu programa pugui trencar-se per alguna entrada de dades errònia, és DOLENT, em sembla una barbaritat. Per molt bon programador que sigui, una persona és incapaç de dissenyar un programa infal·lible ia prova de fallades, SEMPRE hi haurà una fallada, que d'una o altra manera sortirà a la llum, i quan ho faci, serà gràcies d'una fallada aleatori durant la seva ús, per algun hacker o cracker explotant alguna vulnerabilitat, per una revisió i auditoria de codi o per algun altre mitjà amb el qual el programador pugui explicar. És millor mesurar les paraules abans de dir, una cosa com aquesta.
Salutacions.
L'exemple que poses de Xorg és el menys apropiat ja que tot el que hagi patit la transició a KMS / DRM sap que el problema ve donat per errors en els mòduls de l'nucli per controlar KMS que proveeixen els desenvolupadors dels drivers de Xorg. Un error en un mòdul KMS és igual a un nucli panic, no té res a veure amb comunicació entre processos, ja que en aquest cas és Xorg realitzant una crida a sistema (syscall) perquè el nucli canviï de manera de pantalla, és a dir, hi ha un sol procés involucrat (Xorg) trucant a l'nucli, res a veure amb el que estem tractant aquí.
El de el comportament actual de systemd al no trobar el punt de muntatge no ve a el cas independentment que és una funcionalitat que a algú pot no agradar-li, això es resol demanant que suportin l'altre comportament, el que ignori el muntatge fallit. El coredump que passava abans va poder ser degut a dissemblants causes de les que només es podria especular, però el fet que l'execució no continués puc ser degut a un comportament desitjat, ja que dius que calia reiniciar, no hi va haver un nucli panic o reinici automàtic. Com no he passat per això no puc donar una opinió.
Sobre el problema que em poses amb systemd-coredumpd i l'enllaç a l'informe de bug, tot apunta que aquest problema en Arch Linux va ser a causa de la compressió li van habilitar a systemd quan ho van compilar per a aquesta distribució. Més sembla un problema de l'algoritme de compressió que de systemd en si. El sistema operatiu no es crashea, sinó que l'algoritme de compressió utilitzat per emmagatzemar els coredumps sembla estar deixant a el sistema sense recursos i això és culpa dels desenvolupadors d'Arch Linux que van compilar systemd. De tota manera, systemd té configuracions per limitar el consum de recursos i habilitar / inhabilitar la captura de tots els coredumps que reportar el nucli. Potser els mantenidors de systemd en Arch i els que fan servir el KDE haurien fer-los un cop d'ull.
Dius que OpenRC també usa cgroups sense ser invasiu. El problema està en el següent: com OpenRC reconeix el nom dels executables dels dimonis per saber exactament què assignació de recursos és la més adequada? En realitat no estic segur de si aquesta és una de les causes per la qual systemd es fa càrrec de tantes coses, assignant un nom ben conegut als executables, però sospito que la cosa va per aquí. A més, elimina la càrrega que representa tenir a dash pel medi per córrer cada un d'aquests serveis, a l'invocar directament als executables.
No negaré que systemd pot tenir molts bugs, però d'aquí a atribuir tots ells a la forma en què està concebut, no ho crec. En el cas de sysvinit, era superestable, una peça de programari madura, systemd tot just està començant.
https://www.reddit.com/r/LinuxActionShow/comments/2nv4hp/ask_lennart_poettering_a_question/
Com rebenten les pilotes amb systemd, xD Si tant l'odien creïn la seva pròpia distro, que per això és programari lliure é_é
No es tracta d'odi, es tracta de defensar la teva comunitat.
Per cert si hi ha distribucions «Underground» independents:
http://gutl.jovenclub.cu/neonatox-un-linux-iconoclasta
respectes
perquè comparar tot amb Microsoft que això es comporta com un windows .. si les coses funcionen bé i és per al desenvolupament i evolució de linux com és el problema ... tot projecte en el seu inici poden tenir canvis errors si els programes programari etc fossin perfectes, som humans mes gens per això tenim errors ..
que si falla systemd es peta el sistema .. i si falla el nucli, xorg, grub .. hi ha persones que actualitzant el nucli en el seu pc o portàtil se'ls queda el sistema ... llavors perquè la insistència en la perfecció d'alguna cosa ... ..
com si algun sistema que troba sortit no hagués tingut errors bugs o x cosa en els seus inicis o inclusivament ja en el seu maduris tenir falles
Systemd es va imposar com a estàndard amb joc brut, és dependència obligatòria per a molts paquets pel fet que molts programes van ser absorbits per systemd ja sigui perquè ells mateixos els mantenien o per que els van eliminar lentament a l'ia no ser rellevants per que systemd ja proveïa alguna cosa similar.
Això limita la llibertat d'elecció, és a dir les distros no poden optar per NO fer servir systemd, poden tractar de resistir-com gentoo, però això és més aviat una solució temporal a systemd, openrc és només un service manager recolzat en SysV per init i en els initscripts de la distro, systemd proveeix més funcionalitats que openrc i cada dia té una nova funcionalitat. El programari nou es recolza systemd i exigeix implementar alguna cosa similar el que acaba tornant més complexos als altres INITS i més semblant a systemd que és el que no es vol.
Systemd fa moltes coses comparat amb l'antic init que simplement llegia un parell de línies de / etc / inittab per després anar carregant segons el nivell d'execució cadascun dels initscripts i les seves configuracions. L'enfocament antic era molt més senzill i independent. Estem una etapa de transició cap a una nova era d'homogeneïtat, no hi ha solució, la forma d'imposar-que té és imparable.
En uns anys no hi haurà pràcticament diferència entre utilitzar debian, usar fitxers o fedora, es perdrà la identitat de cada distro si seguim així i systemd es tornarà cada dia mes intrusiu que fins passés a formar part de el nom de sistema (systemd / gnu / linux)
LOL
A plorar a l'església>: D
Què diu Don KZKG, li deixo això: https://blog.desdelinux.net/systemd-vs-inteligencia/#comment-127648
El problema és que sos argentí (jo també) però és realment preocupant la forma d'expressar-se que tenen la majoria dels linuxers argentins que llegeixo, encara que també es diu que el món del programari lliure atrau certa gent. El que rescato és que no presumiu de ser argentí, però es nota a llegües per desgràcia.
uyyuyy .. aquest noi va caure amb artilleria pesada ..
contundent el comentari !!
Juju .. ..pochoclos .. xD
De el tal article es desprèn que l'únic que fan és «imposar» un sistema. No entro a valorar si és millor (que no ho és), ni pitjor. El que dic, repeteixo, recalco i remarco, és que no em dóna la gana que em imposin res.
Frases com: «Simplement no els fem servir per al procés d'arrencada, perquè creiem que no són la millor eina per a aquest propòsit específic».
I qui eeres Tu per dir-me si vull fer servir un o altre eina ?.
Allà cadascú. Jo simplement, no el faig servir i punt, i mentre pugui no fer-ho, no ho faré.
Signat. Un Taliban.
(És que m'ha fet gràcia la pallassada)
sovint mal de cap amb aquest tema !!!! X_X
Estava administrant servers amb Centos 6 i passar a l'7 amb systemd no em va costar res, no plorin, la vida segueix.
Amb perdó, però estic llegint molta coses que em recorden a la discursión clàssica de «servidor windows - Home certificat VS servidor linux - Home openSource».
1r - Veureu, si forces un error és normal que falli. Tots i cada un dels vídeos que he vist són forçats de errores.Es com si faig un programa que alimenti de paraules clau el log de syslog i alhora tracte d'executar un script a força de grep per treure informació de log ... clar que va a fallar, jo ho he provocat.
És com fer sucre a un motor dièsel i dir «Mireu ... és millor el de gasolina !!!» o com fan els de windows, escriure malament un fitxer de configuració i queixar-se que no arrenca el dimoni dient «amb windows això no passa».
2n - Que systemd incorpora moltes coses que potser no vas a utilitzar? Bé com és el problema? És que és el mateix argument buit que fan servir els de windows contra els de linux ... «Perquè vull jo un text pla on posar mil i una opcions quan no les faràs servir».
Encara escolto els d'IBM amb els seus programes moniliticos bordar fa anys sobre mysql quan llegeixo algunes coses. Jo agraeixo i aplaudeixo la diversitat de GNU / Linux i de la seva comunitat. Si em dones 50 formes de fer alguna cosa, triaré en cada moment la que millor em funcioni o s'adapti al que necessito. ¿De debò que veieu un problema en això?
3r - Pel nivell de les converses, dedueixo que teniu nivell suficient per treballar amb qualsevol distribució o muntar-la vostra pròpia i mantenir-la vosaltres mateixos. ¿Perquè voleu posar systemd i treure-li coses? ¿No és més fàcil seguir amb la vostra init o openRC?
A la gent que m'ha demanat que els ensenyi les bases de linux els dic sempre el mateix ... GNU / LINUX no és WINDOWS, no intentis fer les mateixes coses ni penseu com si ho fos. Per que assimileu que sistemd és igual a initd o que funciona igual? ¿No és més senzill assimilar el funcionament de systemd i usar el seu potencial, d'intentar que funcions com init o OpenRC? És que és normal que no us agradi.
4t - Que hi ha de dolent en la complexitat? Segur que recordeu encara quan donàveu programació lineal i que segurament en algun moment vau dir ... «¿I perquè vull aprendre a treballar en objectes si ara puc fer de tot ia més ja em deixen fer servir el go to?» ... (el facepalm un parell de mesos després és gran si xD)
Siguem clars. Els init actuals (I incloc systemd) tenen moltes mancances que només es poden suplir afegint complexitat. No hi ha una altra, ja que perquè un sistema interconexo creixi, ha de créixer en complexitat a risc de tenir alguna part feble, però és millor que quedar-estanc.
Cal recórrer molt camí i si ... sistemd no és la solució a tot. Però tampoc ho és quedar-se amb sysvinit.
PD: Notese la ironia que he fet servir el pc del meu company «aferrimo defensor de windows-server» perquè de pas el llegeixi. xD
Només una cosa, als defensors d'altres INIT que donen dades tècnics i enllaços ... Chapo !!! M'encanta veure arguments i dades així. Només un apunt, les dades anteriors a octubre de l'any 2014 són merament històrics.
Moltes coses que es comenten ja han estat arreglades i molts bancs de proves publicats el 2013 ja han estat revisats.
@rolo
Si és cert, si vas veure el vídeo, cosa que NO vas fer, es veu que el log és de 8MB, gens mes i així i tot es corromp, per cert, podis enviar la sortida de journald a syslog en text pla? si, però tot i així si toques els log creats per journald, passa això, es penja el sistema i, és comprensible, a veure, journal penja d'PID1 juntament amb coses tan complexes com systemd, falla, es veu que no té alguna part de codi que no permeti l'edicion per alguna cosa que no sigui el mateix PID de journald així com tampoc té la capacitat de seguir escrivint més enllà que sigui corromput el registre, el que demostra que a més de que pensa en mode windows, LP és mal programador .
No em diguis que sera només en centos, la versió mes estable de les distro que fan servir systemd, clon de RHEL7, i no ni reporti ni penso reportar l'error.
La veritat és que com més llegeixo els comentaris pro systemd, m'adono que realment són com una religió, o aquestes a favor o sos l'enemic, però, d'aquestes religions tipus ISIL, els de l'estat islàmic, totalment extremistes, de fet , ho sé per experiència, els systemd lovers, pensen així, o aquestes amb ells o ets l'enemic. Això és el que promou Lennart amb la seva supèrbia i per favor, no em fotin amb què Linus li dóna suport, systemd no era això, NO HO ERA, jo vaig usar systemd tot just va sortir a Fedora 15 i era solament un init més ràpid, no reemplaçava la modularitat de GNU / Linux.
Si jo mato rsyslog manualment, corrompo seus log o reemplaçament el mateix per un dibuix, gens mes, només que em quedo sense log, res es penja, el sistema no es veu afectat.
@Rafael Mardojai
Això fa Devuan, això va fer Void Linux i altres que es mantenen lluny de systemd.
@Yukiteru
Segur ningú et llegeix, com em diuen taliban, a vós no et llegeixen perquè fas servir windows o vas comentar des del i perquè crec que pocs dels systemd lovers, entenen la part tècnica del que dieu i ahi radica el problema.
======
La veritat, segueixo pensant que una persona coneguda alla pel 2006 tenia raó en una cosa:
«No vull que la gent faci servir linux ni que ho conegui, aquests d'Ubuntu em tenen les balls plenes»
jo- «Per?»
«Quan alguna cosa es fa conegut i per a les masses, es caga, es fot, i hi ha mostres a munts d'això»
jo- «com quals?»
«Mira el que li pas a Debian, ara té un fill tonto anomenat Ubuntu i acordate en alguns anys tindrem« hackers »i« geeks »que van mamar Ubuntu i no van a saber distingir Ext3 de NTFS»
Una mica d'raó tenia .... systemd triomfa entre els que saben, com diu Allan McRae, perquè no li importa com inicia la seva màquina, per al és, botó, màgia i tinc avís de sol·licitud. Entre els que no els interessa mes que «funcioni» amb boniques features, total, per a servidor usen LFS o Gentoo o BSD realment i després els que l'estimen perquè encén mes rapid seu PC amb llums de colors, sons bonics i jocs d'atzar, però no saben que és una syscall.
@SynFlag si no llegeixen és per decisió d'ells mateixos, pel que fa a l'SO que ús, si estic en el meu treball i comento des d'una PC amb Windows, és perquè és l'únic que tinc a la mà, excepte el servidor que està en Debian wheezy i òbviament des del servidor no puc comentar aca.
Fins i tot a casa meva m'he vist obligat a fer servir el PC de la meva germana perquè el meu PC ha mort (la MB i la font de poder conspirar contra la meva), i tot i així quan tinc temps, em munto un CD autònom i ús Sabayon (amb OpenRC ) per comentar aca, com estic fent just mentre escric aquestes paraules.
Ara bé, si em diuen o pensen que sóc un talibà anti-systemd això me fa. Com ja vaig dir, he fet servir systemd i es que pota ranqueja, no només això, acostumo a llegir molt la llista de systemd per assabentar-me de les coses que vénen en noves versions, i també per estar a l'tant dels canvis que es realitzen i de les discussions que alli es porten. Ara si algun amant de systemd entén l'aspecte tècnic del que parlo i poso en els meus enllaços (els enllaços a l'repo git de systemd majorment), i tot i així és incapaç de veure la realitat, això només em permet pensar que la bena en els seus ulls i l'extremisme en la seva forma de veure / pensar / sentir / estimar / glorificar / enaltir / adorar systemd és tan gran que no importa si fins i tot el mateix Linus li dóna un cop de peu pel **** a systemd, ells seguiran atrinxerats en les seves idees que estan en el correcte.
Hola! no sóc molt expert, i em gustaria saber perquè serveix aquest «systemd» i perquè s'està parlant tant del, com és el problema i que alternativa hi ha? gràcies
Collonut el comentari SynFlag! Estic de «geeks», «frikis» i «linuxers de pro» fins a les mismisimas.
I aquest és el futur que ens espera; Ubuntu fins a la sopa; portàtils amb Linux per només accedir a Steam i jugar a l'últim jueguito de moda. I legions de frikis setciències que no saben de què va la beina.
Postdata: el concepte de fons d'systemd és una merda.
els botons de l'ADK i de fòrum no es veuen a la pàgina principal
Així que segons @SynFlag ara tot el que no és anti-systemd és un n00b, fanàtic religiós extremista, i la pesta que corromp GNU / Linux. Amb una opinió tan estreta com aquesta no sé si val la pena debatre sobre aquest tema. Millor deixar que l'aigua corri ia la llarga passarà el que hagi de passar.
és veritat, arriba un punt que no es pot discutir més. només el temps ens dirà si sytemd serà una cosa positiva per al món del programari lliure o no.
igualment em dóna la idea que si aquesta distribució basada en Debian que no va a utilitzar systemd arriba a concretar-se, va col·laborar en apaivagar els ànims d'aquells que no volen saber res amb systemd.
com quan va aparèixer gnome 3 i s'armo una resistència tremenda, fins que van aparèixer els «fork» cinnamon i unity permetent seguir fent servir els programes de gnome en un escriptori amb mes configuracions i un disseny més pensat per al pc i no tant per el tàctil
Potser aquest, Rolo (l'aparició de Devuan), pot ser un punt de consens. Crec que tots ho necessitem per contenir un ambient de discussió polaritzat i bel·licós. Devuan serà un espai per a la creació i la continuïtat d'una manera de fer i això ajudarà a calmar els ànims. El procés que hem viscut a Debian ha estat dolorós, però hem d'assumir la situació, no hi ha més remei que acceptar la separació. Això acaba sent una mica com els divorcis. Aquest fork pot ser un transsumpte de tractat de pau i un punt ia part. Existien alternatives, és clar, Slackware, Gentoo, Funtoo, Crux, PCLinux US, ara Manjaro (per enumerar algunes) ... però l'escena «deb» requeria d'una alternativa sense systemd. Sembla clar que ningú va a convèncer a ningú, els arguments estan sobre la taula i no hi ha consens (tot i que systemd tenen bones idees i que els perills que aquest programari comporta són evidents). És temps de forks i que s'obtingui llibertat per a l'usuari (perquè això es tracta de Programari Lliure, no?).
Un factor que ha influït en el procés ha estat la sensació de «decepció» per part d'alguns dels que dipositem la confiança en Debian. Per això Devuan es planteja com un fork i no una derivada. Hi ha tensió perquè a ningú li agrada què ha passat; ni als pro-systemd (d'aquí certs atacs furibunds intentant difamar) ni als anti-systemd (que han apostat pel fork). En l'ambient hi ha el «¿quant talent podem estar perdent?», Tant per una part com per l'altra.
Tots els usuaris de Debian contemplem la distro d ' «una» certa manera (això pot aplicar-se a les altres distribucions també). Hi ha qui admira la seva qualitat tècnica, altres les seves contracte social, la seva influència en el món Linux, el respecte que ha collit amb els anys, la seva estabilitat en els entorns productius crítics ... En alguns usuaris aquesta percepció s'ha alterat, apareixent la decepció. La desil·lusió, el desencant, diguin-li com vulguin. D'aquí a la separació només hi ha un passet.
El divorci de Debian s'assembla al que ha passat amb NetBSD i OpenBSD. Tot i que el temps ho dirà. Veig moltes expectatives en el fork i això em fa pensar que no serà una distribució fugaç i estèril. Avui mateix hi havia un membre de l'equip de gnome comentant a la llista de distribució de Devuan (tot i que ho ha fet amb certa malaptesa), això, al meu entendre, suggereix que Devuan genera interès i es vol, d'alguna manera, dialogar .
En fi, bon cap de setmana.
@rolo
Dir que el vídeo pot estar trucat o el sofware, és una fal·làcia total i insult, en la meva PU ** vida truc alguna cosa per crear un mite, mai, em vano d'haver vist aquesta sentència pels meus mitjans no pels meus truchos. Es van tots a la **** que els ***** i no em penso ficar mes en debats de systemd perquè és totalment a l'pet, ningú vol entendre res i és tot com una relegion, les quals, detesto, perquè tot és per dogma de fe. Siguin feliços amb systemd.
@SynFlag violència és mentir
El que si demostra aquest vídeo és la falsedat de l'afirmació que si un dels mòduls de systemd si s'arruïna, fa que systemd caigui, ja que evidentment, per la qual cosa mostra el teu video això no va succeir, xDDDDD i per cert journal s'executa com a root, per tant, si un tercer entra i maliciosament fot el binari dels Registres d'journal, jo no em preocuparia de systemd sinó mes bé de la seguretat del teu ordinador. XDDDDDD. Per últim sobre el tema de el vídeo, repliqui el que es mostra editant amb nano l'arxiu /var/log/journal/24f02f5b2b16758b820ea6a751ed6efb/system.journal i a l'reiniciar et trobaras que hi ha un nou system.journal i un system @@ 24f02f5b2b16758b820QQea6a751ed @. journal que és el binari danyat.
És a dir journal s'adona que l'arxiu està corrupte, així que no canvia el nom i torna a crear un de nou, no veig com és el problema en això ??, el mateix que si s'elimina l'arxiu system.journal, journal el torna a crear.
em pregunto que passaria si a un arxiu de registre de text pla, el arruïnaria amb un editor hexadecimal, segurament fins que un no es de compte que l'arxiu estava danyat es peperina totes les dades Oo
parlem una mica de journal que és una de les critiques més comunes a systemd.
journal és un component molt important de systemd, que capta els missatges Syslog, els missatges de registre de l'nucli, RAM i els missatges d'arrencada inicials, així com missatges escrits en sortida estàndard / TDERR i fa que tota aquesta informació estigui disponible per a l'usuari.
Però el més important, és que journal pot ser utilitzat en paral·lel, o en reemplaçament d'un dimoni syslog tradicional, com rsyslog manualment o syslog-ng, per tant un sysadmin previngut podria tenir rsyslog manualment o syslog-ng com una segona eina de consulta, a el marge de transformar en text pla els registres de periòdic per si el binari es corromp
Una altra dada important sobre journal és que si no aquesta creada la carpeta / var / log / journal Només es guarda informació en forma temporal, la qual es perd amb cada reinici.
per exemple, quan entro systemd a debian la persistència dels log no estava activa així que havia de crear manualment la carpeta journal
http://0pointer.net/blog/projects/journalctl.html
Els que sàpiguen anglès, no es poden perdre les xerrades que s'estan duent a terme entre els desenvolupadors de devuan, Jaromil dimkr max2344 entre d'altres al canal IRC de freenode #devuan.
Molt divertit llegir les investigacions de el codi d'systemd com ho han escampat a el propòsit amb finalitat d'infectar (crear dependecias innecessàries).
Em molesta systemd ... .així de front ... és difícil. Poca documentació ni el puto slim corre sol KDM o gdm i en o sistema lleuger vull slim lxdm no ho suporta ni compilant ... .. Enserio que fins abans de ... .estaba feliç amb devien. La veritat vaig començar a fer servir openrc com diuen a gentoo i ajudo .... molt
@rolo
Sos un insolent i malformador de notícies a el dir això. És el pitjor insult que em diguis que ment o falsejament dades, realment em repugna com en pro de defensar alguna cosa ataques a gent que fa PoC seriosos com jo. El log es corromp, el sistema crashea, reiniciar el servei no funciona així que no queda una altra que reiniciar la màquina la qual cosa no és el millor en un servidor hackejat, em diràs que si la seguretat va ser compromesa el millor és reiniciar o reinstal·lar i és de l'únic que em dec preocupar com diuen els de systemd excusant-se i no fer una anàlisi en calent de qUE pAS? per arribar a aquest punt ?. Evidentment sos un producte més dels new sysadmin si és que arribes a això que es va criar usant Ubuntu i té la seguretat d'un DOS 5.0 en el seu pc, així que el que diguis el prenc com de qui ve, em fot molt que dubtis a més el que falseja sos vós, vas replicar acado el mateix OS amb les updates d'ESE dia ?, segurament no, així que tratá de mentider a un altre. Que manca de capacitat tenes, camina a laburar de taxista xq per mes que això dubto que et de, deixa de jugar amb linux i segui mirant pr0n
A veure colomí (synflag), papa et va a mostrar com es feia per aconseguir que journal vaig continuar funcionant després que per alguna raó el nostre arxiu de registre binari de journal queda corrupte, sense haver de reiniciar l'ordinador.
en aquest exemple partim d'una instal·lació base de debian 8 Jessie.
per defecte systemd-journal.service be amb la funció «storage = auto» per tant per aconseguir tenir un registre persistent dels log cal crear l'arxiu a / var / log / journal / prèviament.
# Mkdir -p / var / log / journal /
perquè journal comenci a escriure els log NO cal reiniciar l'ordinador, vasta amb fer:
# Systemctl reload systemd-journal.service
o
# Systemctl force-reload systemd-journal.service
### ara anem a fer veure que es corromp el registre binari d'journal ###
# Cd / var / log / journal
# ls
24f02f5b2b19808b820ea0a980ed6efb
# cd 24f02f5b2b19808b820ea0a980ed6efb
# Nano system.journal
### ara modifiquem alguna línia de l'arxiu per simular que es corromp
# journalctl
### com era d'esperar no passa res
#### ¿cal reiniciar l'ordinador perquè periòdic creï un nou binari? NO
# Systemctl force-reload systemd-journal.service
# ls
system@24f02f5b2b19808b820ea0a980ed6efb-0000000000000001-0005069a53abf581.journal
system.journal
# journalctl
### com podrem veure periòdic crea un nou arxiu binari de log i ja podem vovler a accedir a la informació sense haver d'haver reiniciat en cap moment l'ordinador
https://www.youtube.com/watch?v=hEagyMdkN4A&feature=youtu.be
conclusió: synflag o sos un ignorant, o sos un fabulador
que et garúe finit
per error de mecanografia i abús de el copy and paste vaig escriure systemd-journal.service quan en realitat el servei es diu systemd-journald.service
Pichon ?, ... que equivocat aquestes flac, de debò va .. Això ja ho sabia, reporti l'error en xarxa hat a veure que deien, et pego la resposta, a veure si captes:
If you remove the output file, or overwrite parts of the file, the dimoni can not really do anything about that: if an attacker has permissions to modify the output file, she has already won. The dimoni could check some of those things, but that would be rather inefficient, and not really useful for anything. If you want, you can set up a periodic Cryptographic signature with 'journalctl -setup-keys'. Veure the journalctl man page.
Journalctl depèn de rsyslog manualment, no s'auto reinicia en cas d'error en el log, cosa que rsyslog manualment no necessita, total, tenes que fer servir el fordward perquè enviï a rsyslog manualment i d'aquesta forma s'escrigui malgrat tot i es regeneri el journal log , és una falla de disseny de journald, si no queres veure-ho, blow em.
@rolo
Al vídeo (no sé si ho has fet tu) veig que al minut 2:11 es fa servir ls i no ls -l que permetria veure la mida que tenia originalment l'arxiu system.journal, després ho editen amb nano i li afegeixen línies buits, reinicien el servei a mà i en el minut 3:15 tornen a fer ls i no ls -l, després en el minut 3:20 veuen el log amb journalctl, això li mostra el log actual la qual cosa aquesta bé.
Ara vénen les meves preguntes:
1 - perquè es fa servir ls i no ls -l, per poder veure el tamany original que tenia el log abans de ser editat
2 - que pas amb el log vell? on el va ficar systemd a l'registre binari corrupte?
3 - amb que comanda systemd pot reparar el seu registre binari corrupte ... que se suposa que no ha esborrat
Salutacions
@anonimo
Ara vénen les meves preguntes:
1 - perquè es fa servir ls i no ls -l, per poder veure el tamany original que tenia el log abans de ser editat
2 - que pas amb el log vell? on el va ficar systemd a l'registre binari corrupte?
3 - amb que comanda systemd pot reparar el seu registre binari corrupte ... que se suposa que no ha esborrat
1 la veritat que ni ho vaig pensar, només utilitzi ls per veure que arxius eren al directori, però si t'interessa el podis replicar, el procediment està detallat, i ho faci en virtualbox (instal·lar un debian base és una papita)
2 l'log vell queda al mateix directori, només sol que systemd el reanomena amb un munt de números i lletres (es mostra en el vídeo)
3 en tot cas podries intentar recórrer a aplicacions de tercers (algun editor hexadecimal suposo) ja que si systemd pogués reparar l'arxiu corrupte no ho renombraría ni crearia un de nou. En tot cas, i com ja he esmentat en altres ocasions gen aquest post, XNUMX sysadmin previngut podria tenir rsyslog manualment o syslog-ng com una segona eina de consulta, a el marge de transformar en text pla els registres de periòdic per si el binari es corromp .
dic, no és la idea de convèncer a ningú de fer servir systemd (fins m'encantaria que en l'instal·lador de debian hi hagi la possibilitat d'escollir el int). però no em quedaré callat quan llegeixo a ignorants o fabuladors que se la passen repetint mentides sobre systemd, quant bloc existeix, quan un veu que aquests aquests no coincideixen amb la realitat. i com deia Aristòtil l'única veritat és la realitat 😉
@rolo
He mirat el vídeo de nou i si, ahi sortia llistat, només que era tan llarg el nom numèric que el veia, vaig pensar que aquest era el directori ... .soberano nom.
Respecte a reparar el binari, si, és lògic el que dius ... si pogués reparar no crearia un de nou.
Finalment em quedo amb que no hauria de ser un binari perquè no passi això i per poder veure sense eines especials amb journalctl ... ..aún no comprenc que el va portar a fer servir un format binari.
Salutacions i gràcies per respondre
Rolo, dedicate a una altra cosa:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393
Jo ho vaig saber sense saber això .... com es nota la diferència entre un que camina provant coses i un altre que només fa videitos pedorros
Vinc a tancar el ocote de Rolo, l'error que es veu en el meu PoC havia estat reportat, així que, tancat el ocote petit:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393
A veure fabulador:
1 vas afirmar que perquè journal solucionés el problema era necessari reiniciar el pc com en windows TOTALMENT FALS
Et vaig demostrar que això era una mentida i en el vídeo aquest que vas fer en cap moment fas servir la comanda systemctl force-reload systemd-journald.service perquè si ho haguessis usat teu argument es queia (o desconeixies la comanda, la qual cosa demostraria que sos un ignorant, o intencionalment no ho vas utilitzar, la qual cosa demostraria que sos un fabulador)
2 Dieu que hi hagi informes de l'informe d'error, d'una banda és totalment irrellevant ja que en general la gent reporta moltes tonteras com bug (perquè ho entenguis no tot reporti de bug és un veritable error) fins i tot em dóna la idea que el reportaste vós mateix. I per l'altre tots els programes tenen bug (quants error reportats té sysvinit (un programa que té com a 20 anys)) i el bo de l'informe és que ajuda als desenvolupadors a descobrir i solucionar problemes (alguns mes ràpid altres mes lent)
3 Dieu que amb la decisió que generes a journal, a l'reiniciar systemd es trenca ja que en el vídeo es veu que tenes de reiniciar forçadament el virtualbox. TOTALMENT FALS
La veritat és que systemd no es trenca ja que el sistema s'inicia perfectament (si no arrenqués systemd et donaria un kernel panic i hauries d'entrar en mode recuperació)
El que et passa és que el sistema es titlla quan tractes d'editar un binari amb un editor de text i els factors poden ser molts, com la memòria assignada, l'estat de sistema operatiu (en el vídeo el sistema triga molt a arrencar i en apagar el que dóna a pensar que no és una instal·lació neta de 0 (cosa recomanada per a aquest tipus de casos)), etc. Només et puc dir que el binari aquest l'editi unes 10 o 20 vegades i mai es va titllar. Això també posa en evidència que o ets un ignorant o un fabulador
4 Ara dieu que journal depèn de rsyslog manualment TOTALMENT FALS, el fet és que qualsevol ho pot comprovar instal·lant o desinstal·lant rsyslog manualment i veient que journal funciona perfectament
Et agrairia encaridament que deixis aquesta obsessió malsana cap a la meva persona, no és culpa meva que siguis un ignorant o fabulador
Conclusió:
No querés fer servir systemd, em sembla genial, ara no tenes cap necessitat de sembrar el terror amb mentides per aconseguir adherents al teu croada anti-systemd. viure i deixa viure, que hi ha lloc per a tothom al món del programari lliure 😉
un aclariment sobre el punt 3, algú em diria que com systemd aquesta en pid1 una penjada de la màquina implicaria que systemd casc. Dues coses, primer aca el que s'afirmava és que systemd tustava per la decisió de journal, però en realitat es produeix un accent per entrar a un binari (que aquesta sent usat en temps real) amb un editor de text, igualment aclareixo que en totes les proves que realitzi mai es va titllar la màquina virtual. En segon lloc ningú amb dos dits de front pot afirmar que linux no es titlla xDDD,
Fabulador ?, flac, contenete una mica, fabuladora la teva vella que diu que em tir la goma quan no la toco ni amb un pal, volviedo a el respecte:
1.- Tenes de reiniciar o forçar el reinici de l'servei, la qual cosa tampoc és l'ideal i en CentOS 7 quan ho probe la represa de l'servei no cap a res, no oblidis que és la versió 208 no la 217 nova o 216 de Fedora.
2.- Irrellevant i els que reporten errors? ... sos un idiota, ni et responc
3.- INFELIÇ, la versió que probe aquest dia de el vídeo, que es veu, es crasheaba l'US sencer, perquè et penses que mentiria infeliç de l'orto ?, no sóc un simi mentider, va a prendre cindor pajero.
4.- Depèn per a auto regenerar-sol, no ho fa per si mateix de fet ho suggerit als dev de systemd com feature, que s'auto regeneri sense deixar de loggear llevat que es reiniciï el servei, m'ho van prendre com que ho van a afegir, així que chupame la verga i decime gràcies papi per col·laborar mentre jo miro porno.
Chau flac, em cansi de parlar amb monitos per això prefereixo anar a zoo, quan estiguis a el nivell de la meva anus xerrem.
@SynFlag et demano mil disculpes, no sabia que estaves malalt, realment creia que eres un fabulador i ignorant, però amb el que acabes d'escriure m'adono que en realitat sos un delirant.
bo res, espero que graduïs millor el teu medicació i aconsegueixis tornar a la realitat, força !!! vós podis !!!
Llegeixo i llegeixo i rellegeixo però no entenc res, només es que des que va sortir Xubuntu 14.04.1 fins a la data, no he tendio cap problema amb el meu notebook, ni amb la meva impressora làser hp 1102, no es res de res, sóc usuari i no sé si systemd és pitjor o no convé d'init, però repeteixo no tinc problemes amb xubuntu. 🙂
Leo, llegeixo i rellegeixo i només es que estic revivint un tema vell. XD