Todos os días os nosos ordenadores forman unha parte máis importante da nosa vida, se ten algún tipo de problema afecta o noso estado de ánimo, o noso humor jeje. Por suposto, os usuarios de Windows son máis propensos aos ataques de pánico que se os virus (viva linux!), e se desfragmentamos o disco duro, e se buscamos e instalamos o CleanMaster para PC (aínda que aquí en Linux aínda temos que limpar o sistema, BleachBit é unha das alternativas preferidas). Recentemente os usuarios de Linux teñen (algúns) unha certa dor de cabeza chamada: systemd
Ben ao punto, lin un artigo interesante sobre systemd, que parece ser o que leva de moda hai pouco tempo.
SistemaD, que a algúns lles parece (e empregarei as palabras dun amigo), un anel para gobernalos a todos ... a outros simplemente non lles gusta ou vén, sempre que o ordenador funcione ben, non importa se init fai cousas X ou Y ou se se usa systemd. A este que escribe, bueno ... digamos que prefiro init, paréceme máis sinxelo 🙂
Deixo aquí o artigo:
Antes de comezar debo dicir que non me gusta a decisión de cambiar as cousas en Debian pero, en ningún momento penso abandonar a miña amada espiral. Simplemente intento iso, se imos discutir un tema, polo menos o facemos o máis preparado posible aínda que eu mesmo non me considero pro-sistema. Para lograr a desmitificación de systemd contarei cun sitio web onde os desenvolvedores dan o seu punto de vista que chegou ás miñas mans por un compañeiro que parece ser pro-sistema aínda que non sexa un usuario de Debian. Dito isto, creo que podo pasar a intentar desmitificar o que se di sobre systemd.
Índice
systemd está baseado en binario
Quizais este sexa un dos aspectos que máis nos choca, se todo se basea en binario, como supervisamos as cousas que facemos normalmente a través de rexistros? Non teño nin idea de como naceu este mito, pero non é absolutamente certo.
systemd configúrase case exclusivamente a través de ficheiros de texto sen formato. Algunhas configuracións que tamén se poden modificar coa liña de comandos do núcleo e a través de variables de entorno. Non hai nada binario na túa configuración (nin sequera XML). Só un ficheiro de texto sinxelo, directo e fácil de ler.
Esa cousa é monolítica e controla todo
Antes de chegar ao citado sitio web, confeso que eu mesmo pensaba así, pero despois de ler o que din os seus desenvolvedores, a miña opinión cambiou algo ...
Se constrúe systemd con todas as opcións de configuración activadas, construirá 69 binarios individuais. Estes binarios cumpren diferentes tarefas e están separados coidadosamente por varias razóns. Por exemplo, systemd foi deseñado pensando na seguridade, polo tanto a maioría dos demos funcionan con menos privilexios (usando capacidades do núcleo, por exemplo) e son responsables só de tarefas moi específicas, para minimizar a súa pegada. seguridade e impacto. Ademais, systemd arranca máis que calquera solución anterior. Esta "paralelización" créase executando diversos procesos en paralelo. Polo tanto, vese que systemd está moi ben dividido en moitos binarios e, polo tanto, procesos. De feito, moitos destes binarios sepáranse tan ben que son moi útiles fóra de systemd.
Difícilmente se puido chamar a un paquete que incluía 69 binarios individuais monolítico. Non obstante, o que é diferente das solucións anteriores é que enviamos máis compoñentes nun único tarball e os mantemos encadeados nun único repositorio cun ciclo de liberación unificado.
Iso non parece Unix
Certamente hai algo de certo niso. Os ficheiros fonte systemd non conteñen unha soa liña de código das liñas UNIX orixinais. Non obstante, a inspiración derívase de UNIX e, polo tanto, hai moita UNIX en systemd. Un exemplo sería a idea UNIX de "todo é un ficheiro" que se reflicte en que en systemd todos os servizos están expostos no tempo de execución nun sistema de ficheiros do núcleo. cgroupfs. Así, unha das características orixinais de UNIX era o soporte para varios asentos, baseado no soporte de terminal integrado. Con systemd volvemos a traer soporte nativo de varios asentos, pero esta vez con soporte completo para o hardware de hoxe, que abrangue gráficos, ratos, audio, cámaras web e moito máis. De feito, o deseño de systemd como un conxunto de ferramentas integradas que teñen cada un os seus propósitos individuais pero cando se usan xuntos son máis que a suma das partes, o que está máis ou menos no núcleo da filosofía UNIX. Polo tanto, o xeito no que se manexa o noso proxecto (é dicir, manter a maior parte do núcleo do sistema operativo nun único repositorio git) está moito máis preto do modelo BSD (que é un verdadeiro UNIX, en oposición a Linux) para facer as cousas (onde a maioría dos o sistema operativo central mantense nun único repositorio CVS / SVN) que nunca foi o caso en Linux.
En definitiva, a cuestión de se algo é UNIX ou non importa moi pouco. Sendo técnicamente excelente, apenas é exclusivo de UNIX. Para nós, UNIX é unha influencia importante (de feito, a maior), pero tamén temos outras influencias. Polo tanto, nalgunhas áreas o sistema será moi UNIX e noutras un pouco menos.
Iso é moi complexo ...
Certamente hai algo de certo niso. Os ordenadores modernos son animais complexos e o sistema operativo que funciona nel tamén o será, polo que teñen que ser complexos. Non obstante, systemd non é certamente máis complexo que as implementacións anteriores dos mesmos compoñentes. É máis sinxelo e ten menos redundancia. Por outra banda, a creación dun sistema operativo baseado en systemd simple implicará moitos menos paquetes que os usos tradicionais de Linux. Menos paquetes facilita a construción do seu sistema, elimina as interdependencias e gran parte do comportamento diferente de todos os compoñentes implicados.
Iso non me deixará usar scripts de shell
Isto é totalmente falso. Simplemente Non os usamos para o proceso de arranque, porque pensamos que non son a mellor ferramenta para ese propósito específico, pero iso non significa que systemd fose incompatible con eles. Pode executar facilmente os scripts de shell como servizos systemd ou demos, pode executar scripts escritos en calquera a linguaxe como servizos systemd xa que a systemd non lle importa o máis mínimo o que hai dentro do seu executable. Por outra banda, usamos en gran parte scripts de shell para os nosos propósitos, para instalar, construír, probar systemd. E pode pegar os scripts no proceso de inicio precoz, úsanse para servizos normais, pódense executar na última parada, practicamente non hai límites.
Neste punto, supoño que algunhas das principais crenzas poden ter sido aclaradas, a pesar de non sentirse defensor do cambio e ter as miñas dúbidas sobre "un demo para controlalos a todos"Creo que ao final ninguén se atreverá a dicir que polo menos non funciona, incluso coñezo a algúns usuarios que notan que con systemd" o PC funciona máis rápido "pero esas serían outras das que se podería discutir. Polo momento, só me queda convidalo a comentar aquí os puntos de vista que ten sobre o xestor de inicio que adoptaron moitas distribucións, aínda que agora as maiores reaccións están a verse dentro da comunidade Debian, que incluso naceu unha nova bifurcación con Todo isto. Queira que queira ou non é cousa de todos, pola miña parte só quero facer o meu grano no sistema desmitificador que finalmente estará presente en Jessie, a seguinte versión estable de Debian.
Vin o artigo en GUTL (que á súa vez foi extraído de De Ábreus)
Actualidade do sistema?
Son dos que non le moitas novas cando algo xera tanta polémica, prefiro quedar con máis detalles técnicos. É iso .... Ás veces, sinto que certos temas deixan de ser un debate ou debate meramente técnico e pasan a ser un deses chismes de famosos 🙁
Primeiro chámase unha fila aberta dun usuario a systemd systemd VS intelixencia, logo Linus Torvalds dicindo iso systemd non está tan mal como o pintane algunha razón se o ten), un garfo chamado inútild ... Sen comentarios ... e finalmente Devuan.
Non vou dicir se é tan malo como se di, menos malo ou peor. O sistema funciona para min sen problemas, pero para o gusto persoal prefiro init, porque a súa forma de organizar varias cousas (como os rexistros por exemplo) gústame máis, pero bueno, se systemd chega a chamarse cabalo de carreiras e debe substituír por init (¿Sería a nosa mula de mochila, que fai todo menos que lenta?) Ben ... home, mentres o cambio non sexa extremadamente brusco, os usuarios poden adaptarse sen moito problema e o sistema funciona mellor (si, mellor, non paga a pena de todos os xeitos!), Benvido 😀
114 comentarios, deixa os teus
Moi bo artigo, estiven uns días con Linux Mint 17.1 Rebecca con systemd e síntome moito máis fluído que nas versións anteriores, non sei moito disto porque son un usuario común que estou aprendendo disto pero Estarei ao tanto, este é o primeiro artigo que lin que non fala de pragas de systemD.
Por algo, será o primeiro que lese que non fale de el e, por outra banda, dime, ¿usas o teu Mint como servidor? Quero dicir, non te molestaría se ten algún erro de cando en vez, non? Por iso usas Mint , e por iso non che molesta, non che gusta pero tampouco o sistema che atorga. Cando tes erros e por iso tes problemas graves en ambientes graves, molestarache.
Amigo, algunha distro baseada en Debian Stable que recomendas? Podería usar Debian, pero tes que configurar moitas cousas unha vez instaladas, códecs, etc ... Cal recomendas? grazas.
E como conseguiches que systemd se instalase en Linux Mint? Quería intentar poñelo pero non sei se teño que facer algo adicional (ao que, en teoría, Ubuntu xa trae), se tes algunha guía ao respecto ou algo que me podes transmitir, agradeceríallo moito
Moi bo artigo. A ver se o anti-SystemD talibán o leu (pero dubido)
En calquera caso, dentro dun ano vounos usar SystemD e negarán o que dixeron hai un ano. Así son. Resistente ao cambio? Seguro que si.
Considérasme talibán por non querer aceptar Systemd, entón considérote talibán por non querer aceptar que non quero aceptar Systemd. Estamos a man 😉
Non obstante, como di ao final dos teus artigos:
«Elav: blog persoal / Twitter / G + / usuario de ArchLinux. Informático, melómano, blogueiro e deseñador web. Administrador e fundador de DesdeLinux.net. »
é dicir, usa unha das primeiras distribucións que SystemD adoptou.
lembranzas
Está ben, neno.
Sen palabras !!!!, sigue xogando, que a vida é de cor de rosa.
Por comentarios coma o teu, querido Giskard, é por iso que descarto a SystemD e o que representa.
E se despois de 20 anos empregando e traballando con e para Linux, son talibán; Ben, así sexa.
Nun ano falamos. E elav, non te mencionei. Matácheste como Chacumbele.
A ver, a xente le e NON le. ¿Hai ou non hai talibáns contra SystemD? Hai! E hai no outro lado, quen o defende dentes e uñas coma se fose unha panacea. Que son todos os que son? Non! De ningunha maneira! Hai quen simpatiza cun ou outro e ve o bo e o malo tanto dos seus como dos demais. Con esas pódese falar sen problema. Pero non negarán que haxa talibáns. E dun lado a outro. E se a alguén lle picou iso sen entender que moi ben NON poderían ser talibáns, entón descanso o meu caso porque as probas os fan culpables.
Se falo con alguén sobre SystemD e desde o primeiro momento esa persoa non o chama polo seu nome senón Systemshit ou algo semellante, gustaríame sinceramente que me dixeran se é posible manter unha conversa con tal persoa que inicialmente descualifica ao opoñente. Non pode.
En fin, hai que ler. A ver, se veño e digo "hai algúns eschejfhduf (palabra inventada) que golpean aos nenos cando saen do colexio" e algúns veñen a defender o "eschejfhduf" ¿non é pensar que eles mesmos o son?
Ben, se alguén por aí (non os talibáns, por favor, e tampouco eschejfhduf) quere falar dos pros e os contras de init e SystemD (que teñen bos e malos), estaré encantado de estar.
Saúdos.
O talibán antisistema? e dime, que eres? os talibáns pro-systemd?, por outra banda, porque asumen que non imos ler senón comentar directamente ?, quen é o talibán de mente pechada que non admite discusión e fala como LP :: «é o mellor , confía en min, sei o que fago ". ?
Lin todo o artigo e podo dicirche:
Systemd está baseado en binario: True
A desmitificación: falsa
LP está a terxiversar o que se di, que é que o núcleo systemd é binario, moitos, demasiados para colgar do PID1, fortemente entrelazados, tanto que che invito a mirar #devuan como custa limpar, por exemplo, logind systemd e o resto dos paquetes en Debian, dado o ligado que está o rexistro que substitúe a PAM ao sistema.
A configuración é concisa e non permite TODO o que non quixera, como desactivar o diario, xa que nin se pode matar o PID, nin detelo nin nada, iso é a modularidade? Con sysvinit, polo menos, podería matalo todo ata que só quedase con init , mesmo advenedizo.
===========
"Esa cousa é monolítica e controla todo".
É, máis aló do feito de que son 2 ou 69 binarios, están entrelazados entre si con dbus e, polo tanto, con todo o sistema operativo, non permitindo que non estean facilmente relacionados, o caso máis claro é Journald, que non pode desactivalo, tamén , o inicio de demos ou servizos realízase a través de "unidades" que son ficheiros de texto, pero nada máis que iso, analizado por systemd e voila, sen modificacións nin pirataxes nos servizos máis alá do establecido.
=======
"Non parece UNIX"
Respondereino brevemente. Non cumpre co LSB, nin co POSIX e hoxe un desenvolvedor de fedora que axuda en #devuan dixo: «É certo que non é, non importa, o que importa é que poida executar cousas que son POSIX, o resto, desde logo non me interesa o sistema operativo ou o que sexa, sempre que funcione e teña boas funcións ». E por que debería ser UNIX ou UNIX: faga unha cousa e faino ben, algo que systemd non fai.
===========
Non obstante, systemd non é certamente máis complexo que as implementacións anteriores dos mesmos compoñentes. É máis sinxelo e ten menos redundancia »
Menos redundancia? Pídenlle que instale OUTRO syslog para o texto sinxelo e pediron para o rexistro remoto antes de que existise systemd-journald-remote, é dicir, puxérono en produción sen poder facer un rexistro remoto sen depender de rsyslog , algo básico como o inicio de sesión centralizado. Aínda así, non ten a capacidade, un simple booleano para indicar se queremos a saída en binario ou en texto plano e tamén, se ía usar binario, por que non algo coñecido como berkeley DB para que se poida ler dalgún sistema UNIX ou Linux?
¿Sinxelo ?, de verdade? bote unha ollada ao sinxelo que é: http://wiki.gentoo.org/wiki/Comparison_of_init_systems
Mire a cantidade de liñas de código e ficheiros.
=========================
"Iso non me deixará usar scripts de shell"
Iso é falso, pero de novo está falsificado, non se critica por non permitir o uso de script bash, senón por non usalos para iniciar servizos, razón pola cal non é modificable, pirateable e flexible como é upstart ou sysvinit. E por hackable quero dicir codiciado.
============================
Aínda pensas que:
1.- Non teño ningunha razón
2.- Non lin nada e son talibán?
Pregúntome ... de verdade teño que confiar no que di Lennart? Se alguén neutral me di que podo ter en conta certas cousas, pero isto ten o mesmo gusto que Red Hat publica algo para defender a Systemd
Vaia, ata que alguén por aquí diga algo razoable e non só medo e desinformación.
O artigo é a tradución ao español do que escribiu Lennart.
Non me ofende, pero a tradución parece que a fixo a versión beta de Google Translator ... 🙁 Tiven dificultades para comprender algúns parágrafos; de todos os xeitos agradécese a información.
@ Charlie-Brown, é porque Lennart non sabe expresarse moi ben en inglés. Así de feo se entende lendo o orixinal.
As razóns expostas son válidas, non obstante, creo que algunhas poden xerar máis preguntas. En calquera caso, a miña recomendación a quen teña a oportunidade: ir á fonte orixinal da información http://0pointer.net/blog/projects/the-biggest-myths.html (por desgraza para algúns, está en inglés) que é moito máis completo e vén xustificar ata 30 razóns polas que o uso de SistemD se considera favorable.
Ese artigo que mencionas está escrito polo creador de Systemd. Obviamente, ninguén mellor que el para defender o seu traballo, non obstante, invítovos a ver este vídeo http://hackingthesystem4fun.blogspot.com/2014/12/systemd-journald-centos-7-totally.html e contaranme as súas conclusións ao respecto. Non digo máis.
Elav, o número de rexistros de diario que están nun binario é un dos puntos máis criticados, incluso o propio linus o plantexou, cando nun informe onde admitiu que systemd non era tan malo. O propio linus tamén explicou que podes crear un script para tomar os datos da revista e poñelos en texto plano.
Tamén systemd permítelle configurar o tamaño do binario do diario, reducindo o risco dun posible fallo.
En realidade, a arte que citas é moi pouco seria, xa que non ten un chisco de obxectividade e incluso me fai preguntarme se a falla que mostra é real ou está falsificada (fode co software propietario para que dea o erro).
todos os programas teñen erros nalgún momento, pero parece que sempre van buscar a quinta pata do gato para atopar algo mal con systemd.
Por exemplo: en debian decidiuse que systemd sería o init por defecto, pero non impide o uso de sysvinit ou openrc ou upstart e xa me dirás que si, pero non podes eliminar totalmente systemd, e a miña resposta sería que é o mesmo que ocorreu en debian wheezy onde podes executar openrc, systemd ou upstart pero baixo sysvinit
PD: Non quero imaxinar o tolo que se volverán con kdbus e a súa integración con systemd a nivel de kernel de Linux http://kroah.com/log/blog/2014/01/15/kdbus-details/
Se pode ser. Ademais, penso retirarme oficialmente das discusións relativas a Systemd. O que teña que pasar 🙂
@rolo o fallo está documentado, presentáronselle varios informes de erros, presentáronlle un vídeo e agora din que está amañado. Se queres estar seguro, segue os pasos para ver que pasa. Agora tes máis información sobre o asunto, erros inventados? Non o creo.
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 e as súas grandes explicacións)
https://bugzilla.redhat.com/show_bug.cgi?id=974132
https://bugzilla.redhat.com/show_bug.cgi?id=1157350
O que menciona o vídeo é certamente curioso. Como desenvolvedor sempre nos din que un detalle non debería afectar a todo o sistema / programa, por exemplo, se falla unha consulta selecta na base de datos, por que debería fallar todo o programa? É o mesmo con SystemD, se falla porque fallan outros, non sei o ben feito. Obviamente, hai casos nos que un fallo é practicamente un fallo do sistema, pero canto máis illadas internamente sexan as propiedades do programa, mellor será o produto.
Agora, atacar o software desde o seu lado débil non é novo, é unha práctica moi común e que de feito debería facerse con todos os programas, polo que ver SystemD caer no xornal é unha proba válida de que SystemD non é o que é dixo ou levou a crer.
Canto máis cousas se fagan interdependentes con SystemD, peor quedarán. Se montar un dispositivo antes non fallaba o sistema, é posible que agora as cousas non estean tan ben.
SystemD non está mal, non o odio, pero non é o que moitos queren que creas. Ten vantaxes, pero nada do que Upstart non tiña ou podería ter, por suposto, Canonical estaba involucrado e xa ninguén quería prestarlle atención.
Saúdos.
pero nese vídeo en ningún momento sei que o sistema falla. o que fai o tipo é modificar o binario da información do diario para xerar o erro, pero o punto é que cada vez que entra en systemd.
Polo que entendo, se limita o tamaño do binario do diario, cando alcanza o límite crea outro e así sucesivamente. diminuíndo a posibilidade de corromper todos os datos.
Sexamos claros ... A quen tamén se lle ocorrería modificar o ficheiro de rexistro? xD
@Jorgicio 4 de decembro de 2014 ás 6:03
Sexamos claros ... A quen tamén se lle ocorrería modificar o ficheiro de rexistro? xD
Se o dixeches de xeito irónico ... de acordo, entendín :)), pero se realmente me preguntaches, dou o meu punto de vista.
Para min está claro que non é un erro, é unha característica !! A idea é que se hai escalada de privilexios nun acceso remoto, sería moi doado para aqueles que aceptan eliminar o rexistro simplemente editándoo para corrompelo e que systemd o elimine como corrompido e así desfacerse de ser detectado nese acceso remoto.
Dime paranoico, pero non teño outra forma de pensar ... non é un erro, é unha característica e por iso non aceptan solucionalo.
uff agora todos os blogs de linux fan 200 artigos sobre systemd ata o punto de que xa coñezo case todos os argumentos en contra e a favor de xD.
e pouco a pouco fun convencido por algúns dos argumentos anti sistemd e entre os que vin (se hai algo mal, corríxeme)
Mesmo vin un artigo sobre como fallar todo o sistema cando se edita un rexistro binario e que non dá información de que o ficheiro está corrompido.
a falta de claridade nos rexistros
un equipo de desenvolvemento que a miúdo ignora os informes de erros
Ser tan grande e incluír tantas cousas dentro dun init fai que o sistema sexa moito máis inestable e se engadimos erros como o mencionado anteriormente, fai un sistema sen a estabilidade que linux caracteriza tanto.
dise modular pero partes del non poden funcionar sen outras partes do mesmo sistemad
un desenvolvemento que a longo prazo xera dependencias á hora de programar, facendo que software como gnome dificilmente portátil a sistemas sen systemd.
substitúe as pezas (networkd, logind etc) que levaban anos traballando e recibindo mantemento e cámbiaas por outras novas sen necesidade de que adoitan ter moitos máis erros.
Dende que uso distros baseados en Arch (Manjaro, Bridge Linux, Antergos) que obviamente usan systemd, debo dicir que non teño queixa sobre o seu uso e manexo. Iniciar servizos é doado, máis aínda en Bridge, onde o bluetooth ou o modemmanager están desactivados por defecto. Ademais dun erro relacionado con hwdb.bin (https://bbs.archlinux.org/viewtopic.php?id=189536) Non tiven moitos problemas. Evidentemente non creo que sexa opinión de todos, pero persoalmente non teño queixa 🙂
Non me gusta a idea de que unha empresa (Red Hat) acusada de colaborar coa NSA (portas traseiras e control dos Estados Unidos) faga un sistema co que todo está controlado. Un anel para controlalos todos, para atalos á escuridade se fose necesario ..
Por outra banda, teño que recoñecer que o intel IRIS PRO 5200 funciona mellor para min e case nunca, se non, o meu sistema gráfico rompe cando comezo openSUSE 13.1. E si, todo é mellor, comeza e apágase moito máis rápido. Como me beneficiou un usuario sinxelo.
Destaco a parte importante
Se alguén te acusa de vender drogas, es automaticamente traficante?
@juanfgs
Narcotraficante non .... cómplice si.
Deus ... insultaríache pero as túas propias palabras fano por ti.
Simplemente aclare que systemd está escrito, e así debe facerse.
Ortografía
Si, está escrito systemd, non sistema D ou System D, nin sequera SystemD. E tampouco é o sistema d. Por que? Porque é un demonio do sistema, e baixo Unix / Linux, están en minúsculas e quedan sufixados con minúsculas d. E xa que systemd xestiona o sistema, chámase systemd. É tan sinxelo. Pero, de novo, se todo iso che parece demasiado sinxelo, chámalo (pero nunca deletréalo!) Sistema Cincocentos xa que D é o número romano de 500 (isto tamén aclara a relación co sistema V, non?). A única situación na que atopamos ben usar unha letra maiúscula no nome (pero tampouco me gusta) é se inicia unha frase con systemd. Nas vacacións altas tamén podes deletrealo sÿstëmd. Pero, de novo, Système D non é unha ortografía aceptable e algo completamente diferente (aínda que un pouco axeitado).
http://freedesktop.org/wiki/Software/systemd/
Aquí tamén? Puxeches isto en GUTL .. pero home, todo o mundo di Linux e non GNU / Linux, así que con SystemD o mesmo.
Dígoche que non é necesario usar o sistema de rexistro nin o cron que systemD fornece, podes seguir syslog-ng e cronie para esta ou outras alternativas
Eu uso systemD en ArchLinux desde que estaba en aur e parece máis sinxelo de manexar que o xeito derivado de debian e redhat, ten moitos comandos de consola que lle aforran a edición dos ficheiros de texto e simplifican a montaxe da configuración de instalación de scripts (lembre que en arch todo está instalado pola consola)
E non menos importante o sistema comeza rápido, en arch podes iniciar servizos en paralelo ao iniciar o sistema pero é arriscado
O que creo que é malo no asunto é que a maioría toma partido, ou vostede é pro-systemd ou anti-systemd, e creo que ten as súas cousas boas e malas, son usuario e empecei a xogar un pouco con systemd, realmente O bo é que o arranque é máis rápido e menos complexo que o resto do init, aínda que o número da revista tamén me molesta moito.
Entendo que os que realmente saben se é bo ou malo son os administradores ou os expertos no tema, pero paréceme que o sistema que se preocupou hai un tempo deixou de ser algo técnico e converteuse en algo máis "parado". pola miña parte estou un pouco en contra, pero non me considero anti nin pro
@KZKG_Gaara
Vexo que boa parte do que comentas aquí é o mesmo que Lennart publicou no seu blog, máis precisamente nesta entrada: http://0pointer.de/blog/projects/the-biggest-myths.html.
Por suposto, a publicación tivo certas "aclaracións" e deixou de lado certos contidos técnicos, para ser fácil de dixerir información para quen a vaia ler, pero imos ser serios e sinceros, aínda que a verdade doe: systemd ten moitas cousas que Lennart nega que non teña, iso e moito máis. E neste sentido explícome por parte.
1.- Lennart di que non está inchado e que non ten un síndrome de NIH alto (síndrome non inventado aquí). Se é así, alguén me explique: Por que un init debería ter control de rede (systemd-networkd), dns (systemd-networkd), m-dns (systemd-networkd), rexistros (journald), coredumps (systemd -coredump), depuracións (systemd-coredump e journald), acpi (logind), escalada de privilexios (logind), control de ntp (systemd-timesyncd), control sobre dev (systemd tomou toda a funcionalidade de udev), control de / dev / random (número aleatorio xerador) e o último control sobre TTY (consolado por systemd)? Non houbo MOITAS ferramentas creadas para tales fins que systemd agora engade as súas propias con acceso exclusivo (caso de Journal)? Que explicación lóxica e aceptable me das para que un init poida romper a depuración do núcleo e a cmdline? Engádelle a ese control sobre kdbus, o seguinte IPC que se integrará no núcleo. Seguramente me dirán aquí: «Pero podes instalar outra ferramenta para controlar todo iso». E se é certo, pero, moitas desas ferramentas só reciben un fluxo de datos lanzado por systemd, como no caso de syslog e rsyslog, que se conectan a un fluxo de datos / diario que fornece journald para que outras ferramentas poidan VER o que xornais conducen , ao final, iso significa que tes dúas ferramentas que fan o mesmo e unha delas é unha caixa de pandora. (Por favor, non me digas que se pode auditar o código, porque invito a alguén a "fumar" o código journald e o seu marco con systemd e outras ferramentas relacionadas)
2.- Lennart tamén nos di que systemd ofrece soporte para scripts SysV e LSB. Isto é unha "metade verdade", unha "mentira branca" por así dicilo, porque o certo é que systemd-214 non ofrece soporte para scripts bash, SysV ou LSB e iso está relacionado nas súas notas de lanzamento para esa versión.
3.- Que sistema non é portátil? É outro punto discutible. En BSD non funciona ben, en BSD non hai Cgroups entre outras ferramentas que systemd precisa executar. Pero é por unha razón de deseño do sistema, non porque non sexa portátil. Ata que o núcleo BSD non cumpra o mínimo para soportalo, systemd non funcionará nesa plataforma e iso non é culpa de ninguén, só que BSD non ten interese nin tampouco Lennart. É tan sinxelo. Agora, o soporte para outras bibliotecas C é outra cousa, ben coñecidos son os problemas de glibc (só tes que facer un núcleo a man para ver a cantidade de opcións e solucións que se fixeron para evitar estes detalles, especialmente para os glibc 2.3, 2.5 e 2.11, entre outros fallos que glibc arrastrou ao longo dos anos), pero non remata aí non remata, o propio Lennart dixo que preferiu crear a súa propia biblioteca libc, porque para o seu grupo é moito máis rápido lendo o código xa creado (e documentado por certo), pero non se detén aí, planean eliminar glibc e usan a súa libc non só para systemd, senón tamén para Fedora, converténdoo nun estándar para a construción de todos os seus paquetes. NIH Onde? Parece que ao bo vello Lennart lle gusta o troll e o grande.
4.- Ese sistema non é monolítico porque está dividido en 69 binarios. Si, ben, isto é discutible. systemd ten 69 binarios, que realizan tarefas diferentes, pero estes binarios pasan a información da súa tarefa a systemd, polo que se falla, as posibilidades de romper o sistema aumentan bastante. Isto está ben documentado, os informes de erros abundan en problemas coma estes e en problemas aínda máis sinxelos, estupidamente simples. systemd pódese dividir en centos de binarios, pero mentres o teu núcleo estea controlado, o risco de quebra continúa e aumenta e, se non me crees, le os informes de erros e divírtete.
Teña en conta que aquí non comentei nada de que systemd é lixo, só fixen comentarios meramente "técnicos" (obviamente falar de cousas técnicas faise moi complexo) e válido, apoiado por información facilmente accesible en internet. Agora ben: que Linux precisa dun inicio estándar? Si, seguramente sería algo de gran valor para a comunidade. Que sistema é a solución? Non, aínda que está preto, certamente ten moitas cousas positivas, pero a súa propagación viral e a cantidade de cousas que fai aumenta o risco de que poida saír mal e acabar perxudicando á comunidade.
PD: Deixo material onde podes corroborar o que digo, lelo será bastante ilustrativo e vexo que non inclúo blogs nin nada polo estilo, pura crítica persoal e baseada. Saúdos.
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 quizais te sintas identificado)
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 irmán .. amén ..
Aínda non vexo razóns válidas para non adoptar systemd. Simplemente interpreta o que ve con medo, o que resulta en esaxeracións. Nin vantaxes nin desvantaxes claras e ben definidas.
Ademais, esa integración permite a estandarización da que ata falou. Non só Red Hat traballa en systemd, senón diferentes empresas e voluntarios doutras distribucións.
Creo que o erro é que o funcionamento de systemd non se estudou correctamente.
Vexo razóns válidas na análise de Yukiteru. Teña en conta que en vez de medo vexo rigor, precisión e claridade. Debe ser un problema de médico ocular.
Non é medo (non teño medo a un anaco de código) e tampouco son esaxeracións (todo o que dixen aquí está documentado e pasei información suficiente que o corrobora, información que por certo sae das listas e de a mente / voz da propia letra de Lennart, e non dos comentarios dun blogueiro), é A REALIDADE.
systemd fai todo iso e moito máis, e iso é algo PREOCUPANTE (un concepto diferente ao de ter medo) porque seguramente leva atribucións e fai cousas que neste momento se poden facer por outros medios e que por certo funcionan mellor e son máis estables . systemd é moi parecido a Windows e iso non se pode ocultar; só ten que saber que fan userinit.exe, svchost.exe, smss.exe e outras dependencias e comparalas con systemd, a semellanza é tan grande que é unha mala idea. Agora, certamente, systemd pode ter unha mellor calidade que o seu homólogo de Windows (ou pode ocorrer o contrario, ninguén o sabe, a non ser que programa para Microsoft), pero non me pode acusar de EXAGERADO e MEDIBLE cando leu ao propio Lennart Nunha lista, falando de crear unha biblioteca C completamente nova, porque xa está farto de Glibc e, para non facer nada, bota o pequeno e insignificante consello, que esa libc se pode usar para construír todos os paquetes de Fedora. E se pensas que é mentira e que esaxero, deixareiche a mensaxe nesta ligazón: http://lists.freedesktop.org/archives/systemd-devel/2013-March/010062.html (en inglés)
Agora dime se é esaxerado dicir diante de todas estas cousas, que unha vez que Linus decide que CONFIG_VT tal e como é, ten que saír do núcleo (situación que existe desde hai tempo) e pasalo ao espazo dos usuarios, non sucede unha cousa tola como se systemd-consoled é unha forte dependencia de case calquera instalación de Linux (algo ten que manexar as TV, ¿non crees?), que non poñería diferentes distros non systemd no punto de mira para forzar un interruptor. Se pensas que é un tramo, déixame dicirche que non tes nin idea de que Lennart é capaz e está a facer, xa que os seus últimos cambios afectan ao desenvolvemento do garfo udev, Gentoo eudev, e seguirá facéndoo coas súas ameazas. por debaixo da mesa (para queixarse máis tarde como fixo en Google+)
@xiep Non podo estar máis de acordo co teu comentario.
Che Yukiteru, a súa longa declaración omite o feito de que o correo electrónico que ligou a libc sexa unha broma de parvos de abril, mire a nota ao pé e mire a data (31 de marzo, probablemente o 1 de abril na zona horaria de Lennart)
Practica o inglés-fu porque é acuoso e pon en dúbida toda a túa "investigación".
@juanfgs pareces o único que le, polo menos aplaudo iso, pero necesitas ler algo moi importante que está no meu comentario, non importa, vou poñelo aquí:
»NIH Onde? Parece que ao bo e vello Lennart lle gusta o troll e o grande ".
Non creo que o escribise por unha razón inocente, era consciente do feito de que era outra broma de Lennart para April's Fool Day (mal humor), así como da súa paixón por converter /, / etc e todo o demais a / Linux. 🙂
PD: Grazas pero non necesito practicar o meu inglés, estou a usar o idioma dende os 6 anos
aaahh e todo o demais é certo, verifícao 🙂
Este é un sensacionalismo absoluto, dis que estás baseado en feitos, pero en realidade segues a túa idea de que o tipo é malo e quere apoderarse do mundo e torces os feitos para reflectir o teu discurso. Isto é o que me molesta moito da xente antisistema, non pican palabras á hora de retorcer feitos e dicir medias verdades, cargadas coa súa opinión, por suposto.
A miña "regra xeral" nestes casos é simplemente a seguinte desglose lóxica, partindo da premisa de que
- Son desenvolvedor web / aplicacións de escritorio ou cli
- Nunca escribín un sistema de iniciación.
- Non son o mantedor dunha distro.
comproba se o interlocutor ten:
- creou un sistema init
- mantén activamente o sistema init dunha distro
e a realidade é que a maioría dos antisistemas fallan esta proba, aínda así son un puñado de persoas que por algunha razón SABEN MÁIS que as persoas detrás: Debian, Fedora, Archlinux, o núcleo Linux, todo o proxecto GNOME, probablemente o Proxecto KDE tamén porque non se queixaron de systemd, SUSE, etc.
Aínda así, o seu discurso velenoso e vitriólico o único que consegue é xerar desunión, problemas e outros. Tal é o punto que non podo esperar a que finalmente cambien a BSD xa que ameazaron desde Xorg, NetworkManager, PulseAudio e non sei se por pura ignorancia técnica ou porque non se queixarían diso.
@juanfgs, respóndoche especialmente na túa palabra:
«E a realidade é que a maioría dos antisistemas non superan esta proba, aínda así hai un puñado de persoas que por algunha razón SABEN MÁIS que as persoas detrás: Debian, Fedora, Archlinux, o núcleo Linux, todo o GNOME proxecto Probablemente tamén o proxecto KDE xa que non se queixaron de systemd, SUSE e moito tempo etc.
Aínda así, o seu discurso velenoso e vitriólico o único que consegue é xerar desunión, problemas e outros. Tal é o punto que non podo esperar a que finalmente cambien a BSD xa que ameazaron desde Xorg, NetworkManager, PulseAudio e non sei se por pura ignorancia técnica ou porque non se queixarían diso. "
Entón, segundo vostede, todos os antisistema somos velenosos e vitriólicos, o único que conseguimos é a desunión, os problemas, etc. Déixeme dicirche que esa é a maior indignación que puiden ler por aquí. Non sei por que se preocupan os pro-systemd cando se poñen de manifesto os problemas estruturais dun sistema, o que obviamente lles afectará nalgún momento, porque pode que non lles pasase nada agora, pero nalgún momento si. faráo, e entón algún antisistema lembrará as palabras que dixeron moitas veces e ninguén as detivo, e quizais algún outro antisistema lles dea unha man.
Persoalmente, non me gusta systemd, pero iso non significa que non use init, debo, porque precisamente no meu traballo se teño que tocar unha máquina con ese init, debo ter coñecemento de como manexalo el. Ademais, persoalmente tamén o usei dende que cheguei a Archlinux e incluso en Debian e Gentoo, así que non me diga que a miña visión está distorsionada ao non usar systemd, useino e sei que coxea e se teño que axudar a alguén no foro FromLinux ou no IRC ou na lista Debian (que é a distro na que estiven máis tempo e aínda uso no meu traballo) fareino con gusto, porque precisamente se algo me gusta de a comunidade Linux, é que a pesar da diferenza sempre axuda.
Agora para cambiar a BSD, é posible, pero só o farei se systemd se volve tan virulento que non me permite usar ningunha outra opción, mentres tanto permanezo en Linux, desactivando toda esa tolemia, incluíndo moitos dos Agrupa cousas.
!=
De novo torces as palabras para que se axusten ao teu discurso. Vostede é moi bo material para un político / xornalista.
Aclaro, o meu problema non é que mencionen problemas técnicos de Systemd, a cuestión é que moitas veces están cargando o seu discurso con mentiras, a saber:
Que se systemd te obrigará a usar un servidor microhttpd (que é un módulo opcional NON instalado por defecto), que se systemd é un único binario, ese systemd pecharase porque lennart é pagado por Microsoft, que os rexistros binarios Son obrigatorios. Ninguén quere systemd e a súa adopción faise por un lobby político.
Iso é o que choca, as mentiras. Se fose unha discusión razoable pagaría a pena, pero é só o bo FUD.
Que non che guste paréceme perfecto, non me gusta moito o software, nin sequera as linguaxes de programación, distros e outros, pero non invento cousas sobre iso nin son obsequioso lendo o que quero ler e cargando as miñas declaracións con sentimentos persoais para danar a imaxe das persoas que a desenvolven.
@juanfgs perdón, pero non son eu quen chamo a un determinado grupo de persoas "velenoso e vitriólico" simplemente porque non lles gusta un software.
De novo, torcendo frases para ser vítima.
@juanfgs de novo dígoche, que dixeches ti, comproba as túas palabras, non estou a terxiversar as túas palabras, acabo de facer unha copia / pegar das túas palabras no comentario 59
Cito o meu comentario textual capo, o que tes que ler de novo es ti porque non queres entender ou non sabes debater. Sacas as cousas do contexto e as interpretas como se che cantan. Entón, se queres escoller vivir nun mundo no que te sentes insultado porque os teus argumentos están en disputa, Lennart, Red Hat e Microsoft perséguenche, é porque decides crer niso.
Resumo aquí porque me decato de que non es unha persoa razoable porque non queres entender, queres interpretar as cousas como creas.
Se queres ser ofendido, oféndete, pero é o teu problema, non o resto do mundo.
@juanfgs Non me molestan os teus comentarios, realmente non vexo ningunha razón, estamos a discutir, a xente civilizada discute sen ter que preocuparse por iso (iso é o que creo).
Agora, se che gusta etiquetar, prexulgar (ou como queiras chamalo) á xente polos seus discursos ou accións (quizais deberías ler o meu comentario # 64 e medir a amplitude do mesmo), ese é o teu problema, limítate a esas accións cara a ti mesmo e deixa aos demais fóra dese bolso.
Saúdos.
"A maioría dos antisistemas", "case todos", "todos", "algunha parte do antisistema" ... desviámonos, Mariano, desviámonos. No presente caso: non vexo por ningures que Yukiteru pronunciase un discurso sensacional baseado en corazonadas (referíndose á súa análise deste xeito ten algo torcido), pola contra, desenvolveu sólidos argumentos sobre as desvantaxes do sistema baseado en preguntas e material axeitado extraído de listas de correo e trazas de erros (así como de forma educada e civilizada). Posiblemente por este motivo irritase a algúns e atacáseno no primeiro comentario, para desprestixialo e descualificalo (esta vez, de xeito velenoso).
Se ves que o discurso da maioría dos anti-systemd é velenoso e vitriólico, o que vexo no discurso dalgúns pro-systemd (non sei se son maioría ou minoría) é a histeria e a persecución dos que, precisamente, fan argumentos sólidos entre todo o ruído. Iso na miña terra chamamos disidencia acosadora.
¿Está facendo systemd ben por ti? Estupendo, paréceme xenial, pero deixe que os que non pensan o mesmo expresen as súas reservas (é posible que o sistema operativo non funcione do mesmo xeito).
lembranzas
Ah, por certo, por que se estoupa algún erro do sistema ata o punto de desperdiciar todo o compoñente, pero outros como GCC, glibc ou incluso o núcleo non foron criticados ata ese momento por moitos dos seus erros?
Xa o dixeches ti, glibc leva moitos anos arrastrando problemas. Co tempo, Llvm demostrou ter vantaxes sobre GCC. E aquí non vexo a mesma crítica.
Por que non facer o mesmo con outros proxectos?
Para min é simplemente medo colectivo e irracional.
Glibc ten os seus erros ninguén os pode ocultar, hai enormes erros de Glibc que afectan o núcleo e centos de executables. A diferenza entre Glibc e systemd é que a primeira é unha base a partir da cal MILES de proxectos de software poden transformarse en binarios, mentres que systemd é un init, cuxo propósito é ser unha peza estable, comprobada e practicamente infalible. Non só iso, Glibc debe axustarse a centos de diferentes arquitecturas de hardware (CPU), a diferentes bandeiras de optimización e características únicas da CPU, a diferentes formas de optimización de software, un traballo moito máis arduo e difícil que o de systemd. Realmente non vexo ningunha forma de presentar unha comparación entre os dous proxectos na mesma escala.
O mesmo ocorre con GCC, GCC é un compilador que por certo soporta moitas linguaxes (13 en total contando as non oficiais) e ten características moi similares a Glibc, soporta moitas arquitecturas (70 arquitecturas para a versión 4.9), optimización binaria bandeiras, bandeiras de optimización da CPU e moitas outras funcións. Agora están no mesmo nivel de dificultade, un compilador cun init. A resposta é máis que obvia, comezando por que systemd está en C e gran parte do código GCC está no ensamblador ou hai que usar o ensamblador para que as cousas funcionen en binario, algo un pouco "difícil de facer".
Que pasa con GCC e Glibc? Claro. Incluso Linus deulles o seu ataque, pero en GCC e Glibc teñen algo positivo que en systemd a miúdo esquécense, é dicir, informouse dun erro, víronse erros e corrixiron.
- por favor, alguén me explique: Por que un init debería ter o control de:
redes (systemd-networkd),
dns (systemd-networkd),
m-dns (systemd-networkd), l
ogs (diario),
coredumps (systemd-coredump),
depuracións (systemd-coredump e journald),
acpi (logind), escalada de privilexios (logind),
ntp (systemd-timesyncd),
dev (systemd tomou todas as funcionalidades de udev),
de / dev / random (xerador de números aleatorios)
TTY (consolado por systemd)?
Un tema 100000 repetido e repetido, o que cómpre dicir é que systemd pode funcionar sen eles, de feito en debian nin sequera son a metade dos que menciona
do mesmo xeito só é unha característica do seu enfoque amplo
lennart: Ben systemd divide o que ten que facer en moitos compoñentes diferentes (máis de 90 binarios estes días). Cada un corre cos menos privilexios posibles.
Imaxino que isto non é unha gran diferencia de coreutils, que tamén ten un gran número de compoñentes nun paquete. E coreutils é probablemente un dos principais proxectos que fai que Linux se sinta como un sistema operativo similar a UNIX, non?
Pero si, systemd é máis complexo que sysvinit, sen dúbida. Nos últimos 40 anos de computación cambiou moito, e moitos deles realmente requiren un certo nivel de complexidade para tratar ... Hai moi pouco camiño para iso.
Porque non tes esa intransixencia con freebsd, que fai exactamente o mesmo pero coas súas ferramentas e sen permitir o uso doutras, o que non é o caso de systemd.
- ¿Non se crearon MOITAS ferramentas para tales fins que agora systemd engade as súas propias, algunhas con acceso exclusivo (case journal)?
Non vou negar que o tema da revista garda a información nun binario é o máis feble que defender, pero non é o fin do mundo, pódense gardar en texto plano.
- Que explicación lóxica e aceptable me das que un init é capaz de romper a depuración do núcleo e a cmdline?
Mmmmmmmmmmm …………………. romper o núcleo ……. 5000000 cousas poden romper o núcleo
- Engade a ese control sobre kdbus, o seguinte IPC que se integrará no núcleo.
Segundo lennart Isto ten unha relación positiva para os desenvolvedores e systemd traerá ferramentas para abrir dbus aos administradores, tamén dará interfaces de bus diario e de rede
- De seguro que me dirán aquí: "Pero podes instalar outra ferramenta para controlar todo iso". E se é certo, pero, moitas desas ferramentas só reciben un fluxo de datos lanzados por systemd, como no caso de syslog e rsyslog, ... .. iso só significa que ten dúas ferramentas que fan o mesmo e unha de eles son unha caixa de Pandora. (Por favor, non me digas que se pode auditar o código, porque invito a alguén a "fumar" o código journald e o seu marco con systemd e outras ferramentas relacionadas)
aquí entramos na teoría da conspiración !!!!! é un software libre delgado, nada está oculto
3.- Que sistema non é portátil? É outro punto discutible. En BSD non funciona ben, en BSD non hai Cgroups entre outras ferramentas que systemd precisa executar. Pero é por unha razón de deseño do sistema, non porque non sexa portátil. Ata que o núcleo BSD non cumpra o mínimo para soportalo, systemd non funcionará nesa plataforma e iso non é culpa de ninguén, só que BSD non ten interese nin tampouco Lennart.
Ben, iso non é do todo correcto, os desenvolvedores de BSD fan algo semellante ao systemd que o propio Lennart destacou na súa conta de g +
https://plus.google.com/115547683951727699051/posts/g78piqXsbKG
https://www.youtube.com/watch?v=Mri66Uz6-8Y
4.- Ese sistema non é monolítico porque está dividido en 69 binarios. Si, ben, isto é discutible. systemd ten 69 binarios, que realizan tarefas diferentes, pero estes binarios pasan a información da súa tarefa a systemd, polo que se falla, as posibilidades de romper o sistema aumentan bastante. Isto está ben documentado, os informes de erros abundan en problemas coma estes e en problemas aínda máis sinxelos, estupidamente simples. systemd pódese dividir en centos de binarios, pero mentres o teu núcleo estea controlado, o risco de quebra continúa e aumenta e, se non me crees, le os informes de erros e divírtete.
Se estás usando sysvinit e o teu TTY dev acpi ntp rompe tamén o teu sistema, non te asustes.
O monolítico é freebsd e non dis nada
@rolo
Agora listame cales son as distros que levaron systemd e crearon eses 90 binarios en paquetes separados, sería 91 paquetes con systemd.
E ao instalar systemd non me pide ningún destes 90 paquetes como dependencias.
En serio, e volvo insistir ... por favor, pásame as opcións do –configure-help que quero facer 91 paquetes compilando a man con make.
Non hai peor cego que o que non queira ver ... rapaces isto é auga e petróleo, parece que aínda hai persoas teimudas que non ven a realidade do que é o redhat.
@rolo Quero que instale systemd e elimine journald, systemd-udev e coredump e use opcións como eudev e syslog directamente, para ver se pode.
Este comentario non me puido facer rir máis seriamente, estou morrendo. 😀
En serio, realmente toman a molestia de ler un pouco, en vez de quedar co raio no ollo.
Ademais, ninguén esquece que Kay Sievers non só rompeu o cmdline do núcleo, senón que quixo calalo, ao fin e ao cabo "o xenérico é xenérico".
Noutras palabras, segundo vostede, o feito de que dous procesos transmitan información faino tan unido que o feito de que un faga que o outro teña unha alta probabilidade de fracaso ... de que teoría do desenvolvemento de software obtivo iso? Estou de acordo con @pamp en que falas dende un medo irracional e tendencioso.
E a túa outra gran pregunta, por que o sistema ten que controlar tantas cousas? Resposta sinxela: porque con sysvinit e todas as outras vantaxes de init recentemente introducidas no núcleo de Linux están a desperdiciarse, sempre que ninguén as use no espazo do usuario, están "cabreadas" (como dicimos en Cuba ... ben , malgastar) sen ninguén os uso e dan moi boas vantaxes no uso eficiente dos recursos de hardware (CPU, RAM, E / S, etc.) incluídos os grupos. O que fai systemd é, precisamente, poñer estas boas funcionalidades ao núcleo Linux ao servizo do usuario, pero para iso ten que ser el quen inicie eses demos.
Creo que leu e analizou mal (analizar é importante) ou simplemente nin se deu a oportunidade de facelo. Que dous procesos transmitan información non é un motivo para que un sistema se rompa, con todo, cando tes binarios con acción dinámica como control de rede, rexistros ou coredump, pasando información directamente a init, as cousas poden ir mal e irán mal, porque se algúns dos binarios rompen, as posibilidades de romper o resto son moito maiores, e iso é bastante realista, e aconteceu, o núcleo cmdline fallou recentemente, os problemas de acpi que tiveron os desenvolvedores Nvidia grazas a systemd-212, todo iso é un mostra do que digo.
@Dariem
Se non podes compilar cada un destes binarios en paquetes individuais, estás forzando iso porque queres que se instale, tes que instalalos todos, ao instalalos todos resulta que pisas outros paquetes que non se poden instalar porque as partes de systemd están ocupando eses lugares.
Que sentido ten dividir un executable grande en varios executables máis pequenos se ao final non tes un paquete para cada un que che permita instalalos individualmente.
Volvo facer a solicitude xeral a todos os usuarios avanzados de systemd, para que me digan como compilar eses 90 módulos e crear 90 paquetes que se me apetece instalalos e se non utilizo os programas que estiven a usar.
Moi mal leite todo isto ... parece que a xente de systemd pensa que todos os usuarios de gnu / linux son parvos.
Para deixar constancia, usei probas gentoo e hai uns meses cambiei a systemd e non puiden con journald, o que me fixo volver a openrc máis rápido do que tardou en cambiar a systemd.
Para seguir vendo como van as cousas con systemd teño archlinux nun portátil que pronto sairá a gentoo .... Seguramente estable.
@ anónimo, só quero ver como vai evolucionar o problema TTY en Linux. Cando saia o código CONFIG_VT, a favor de dividir a TV en dúas partes ben diferenciadas (espazo de núcleo e espazo de usuarios) necesitaremos algunha ferramenta para controlar as TV dende o espazo de usuarios e alí o sistema consolado pode xogar a ser unha forte dependencia que atrae ao resto de as distros sobre a necesidade de ter que instalar os compoñentes systemd, só para facer posible que o sistema funcione. O que digo non é unha esaxeración, é unha posibilidade moi, moi grande e realmente preocupante. Hai outros proxectos, como KMSCon, pero se a maioría dos escritorios e distros van a favor do systemd, cousas como KMSCon poden morrer máis rápido do que moitos pensan.
@Yukiteru 3 de decembro de 2014 ás 8:49
Non lle teño medo, o señor Linus non eliminará as opcións predeterminadas dunha versión a outra, establecerá o novo sistema como NUEVO e permitiralle escoller entre o antigo e o novo.
En canto á parte do espazo de usuario, podes facer un paquete que o faga de forma independente, se systemd o fai, por que non se poderían outros 50 máis? Ademais, as diferentes formas de facelo farán que os diferentes terminais adopten diferentes xeitos, todos cos USEs para activalo e desactiva como estamos acostumados.
O mesmo pasa con kdbus, que Linus o admite en 3.19 como está dicindo, non significa que haxa que telo activo si ou si.
Estou moi contento con openbox + compton, os escritorios para min poden estar desaparecendo porque non me afectarán.
@ anonymous a pregunta é que eliminar CONFIG_VT é algo que ao final será total (polo que lin), é dicir, no núcleo só quedarán as primitivas, mentres que o resto de ferramentas estarán no espazo de usuarios, isto é non está mal, pola contra, eliminará moitos códigos antigos do núcleo, fará máis doado de manter e moito máis configurable (compatibilidade completa con KMS / DRM para a consola). Certamente, ao comezo, haberá ambos sistemas, pero a longo prazo (15-20 versións) pode saír do núcleo, ou incluso antes, moitas ferramentas xa non admiten tal código en favor dun código máis novo e mellor soportado.
Agora dis que se systemd o fai porque 50 máis non o poden facer (imaxino 50 aplicacións máis). Ben, se vemos as fortes dependencias de KMSCon (o proxecto máis antigo neste sentido) son libudev (código que se unirá a systemd en breve, non será compatible e entrará en conflito con systemd se funciona por si só), libdrm , libxkbcommon, libtsm e systemd para manexar varios asentos, entón cando ves isto, decátaste de como as cousas están tomando forma ao tomar por si mesmas moitas ferramentas necesarias para que un sistema operativo GNU / Linux funcione sen problemas.
@Yukiteru 3 de decembro de 2014 ás 9:46
Aquí en gentoo libudev é un virtual que apunta a sys-fs / eudev, polo que a xente de gentoo encargarase de modificar eudev para cumprir coa API ditada polo novo sistema de núcleo.
Entón, creo que outras distros distintas a systemd (hola devuan) usarán if ou if eudev.
O que pasou co udev orixinal vai ocorrer, o sistema o devorou, pero aquí o núcleo é o ditado pola API para interactuar coas consolas usando DRM / KMS .... Xa quería ver un urxvt usando isto ... jeje
O que si acepto é que quen use systemd non terá a opción de cambiar nada ... imposición completa e dura e como dixen antes ... de chorar ao cemiterio.
@ anonymous sen dúbida o que dis é a outra posibilidade, eudev tomará maior forza neste sentido e manterá as opcións abertas para escoller diferentes ferramentas.
PD: Como dis, sería interesante ver como VT leva as vantaxes de KMS / DRM xunto con fbdev 😀
Xa repetiches exactamente o concepto que che critiquei, porque en ningún momento falei do sistema, falei de comunicación entre procesos e repito de novo, de onde o consegues porque se comunican dous procesos, a morte dun implica que o outro ten amplas posibilidades de Morrer? Explícame como dous procesos, que residen en espazos de memoria separados, poden influírse mutuamente no comportamento interno do outro. A ver se me explico a min mesmo, dende o punto de vista dun destes procesos, só accede a un mecanismo IPC (calquera que sexa o que se definise para comunicar aos procesos systemd). Se o programador era tan malo en non incluír código que poida tratar con entrada e saída inesperadas, iso é outra cousa, pero non ten nada que ver con que un proceso inflúa nas internas doutro. Se systemd-networkd falla, non ten que matar a journald ou systemd, como ocorreu co sistema antigo sysvinit, o feito de que inetd falla non debería afectalo, son procesos separados.
@dariem explicou dun xeito sinxelo para ver se tes a idea:
O que dis é certamente o comportamento que sempre se espera dos programas e procesos modulares. A modularidade implementouse con ese propósito, o de separar dous procesos e que ocupen os seus propios espazos de memoria, e que se comuniquen por algúns medios (IPC, etc.), de xeito que no caso de que algo faga mal, non pasa nada malo. o sistema pode seguir funcionando sen interrupcións. Unha teoría que seguramente contou cun gran apoio debido ao seu potencial e á inmensa marxe de fiabilidade que deu á computación actual. Agora, isto non sempre é certo (a vida non sempre é fermosa), e creo que seguramente fuches vítima destes acontecementos nalgunha ocasión ou noutra (seguramente isto vale para todos independentemente do sistema operativo que uses), e vou dar un par de exemplos.
O primeiro vai con Xorg (que é un proceso modular do mesmo xeito que systemd), que ás veces tola cun controlador e falla e deixa sen gráficos, mentres que o resto do sistema segue funcionando como se esperaba (Blessed modularity 😀). Ata agora está ben, a nosa teoría de que os procesos modulares non teñen por que romper o sistema funciona ben. Pero (sempre hai algúns pero) ás veces Xorg dá algo máis que tolemia e por algunha estraña razón (que pode ir desde o control do rato ata o controlador gráfico) Xorg non só falla, senón que tamén che dá o máis bonito do pánico do núcleo ( e un graffiti no monitor como Picasso) que podes imaxinar e logo dásche conta de que, por moi modular que sexa, se un proceso intercomunicamos e intercambiamos información / datos con outro e algo falla nun deles, e para por algunha razón, o erro non se pode tratar correctamente, aumentan as posibilidades de que os procesos en cuestión se vexan afectados, polo simple feito de que os datos son erróneos ou simplemente están corruptos, e logo chega a catástrofe.
Se pensas que isto non pode ocorrer, déixoche algúns informes de erros (un é meu en Debian e ten un par de fotografías) dun erro antigo que está en Xorg, mesa, nouveau e o controlador drm / kms do núcleo, procesos que a pesar de funcionando ** por separado e sendo modular **, xuntos non se levan moi ben, polo menos non baixo as circunstancias.
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
Agora o outro exemplo vouno dar con systemd. O noso antigo Sysvinit tiña unha peculiaridade de que, a pesar de ser vello, era moi fiable, ata o punto de que se o teu / etc / fstab tiña unha entrada de partición (non importante para o sistema, comprende un / mnt / Disk160GB) e é que non podería ' Non se pode montar por algún motivo, o montaje simplemente saltouse, deulle unha mensaxe de aviso e continuou co proceso de arranque. Agora, systemd é outra historia, a pesar da súa modularidade, se tes unha entrada en / etc / fstab e systemd por algún motivo ve que é imposible montalo, non só agarda a que a partición estea dispoñible (o comportamento normal programado ) para a súa montaxe, pero se remata o tempo, o seu sistema está parado e non pode facer máis que entrar no modo de recuperación e eliminar esa liña de / etc / fstab, algo realmente fallo. Ese pequeno detalle xa non se fixo durante o arranque automático e todo o proceso detense, ao principio (systemd-) o pequeno detalle era máis feo, porque o vertedoiro acaba de aparecer e había que reiniciar. Alguén que pasou polo detalle dille.
Outro exemplo que podo dar é coredumpd en systemd. por defecto, coredumpd pasa toda a súa información a journald para que este escriba a información capturada no disco, ata o de agora, estamos a usar a modularidade de systemd para a nosa vantaxe. Pero acontece ás veces, cando os coredumps son moi grandes, tan grandes, que poden ocupar varios GB, e no proceso de pasar información do coredump a journald e despois ao disco, suceden cousas estrañas como que Xorg deixa de funcionar e incluso o núcleo. pánico. Iso non só ocorre con systemd, por suposto, senón que o xeito no que está deseñado aumenta o factor de falla e crea outros detalles desagradables (entre eles un aumento do consumo de memoria, corrupción de rexistros, volcados incompletos), que tivo que traballar cun coredump de KDE, ten seguramente pasou por varios episodios coma estes e comprenderá a importancia de ter a opción de sincronización en / etc / fstab para a súa partición de volcado e seguramente odiará o feito de que non poida usar algunha outra opción para tratar os volcados, se tes systemd instalado. Un exemplo do que pode ocorrer con systemd-coredumpd.
https://bugs.archlinux.org/task/41728
Agora, para rematar:
Non se supón que son programas e procesos modulares? Si, son modulares. O núcleo é o único monolítico do que falei aquí, pero tamén acepta módulos (LKM), polo que chegaría a ser unha especie de núcleo híbrido aínda que a súa forma de deseño base non está deseñada nese tipo de estrutura. e iso faino un pouco inestable baixo certas circunstancias.
Esa modularidade non debería permitirme evitar que os meus procesos e sistema se producisen fallos se algo falla? É certo, a modularidade é unha medida deseñada para acadar un alto grao de estabilidade e fiabilidade, pero non é unha medida 100% infalible, porque se algo pode ir mal, simplemente vai mal, por moi modular que sexa. realidade.
Que sistema ten que controlar todo para facer posible o uso de cgroups e outras opcións engadidas ao núcleo? Completamente falso. Iso non é necesario en absoluto, systemd podería quedar cunha interface para controlar o inicio e a asignación de cgroups aos procesos e demos que estarán no sistema, sen ter que facerse cargo do número de servizos que agora ten e o mellor exemplo diso é; que OpenRC tamén é capaz de usar cgroups e por iso non o invade para levar a cabo esa tarefa.
Que teño tendencia e medo cando falo de systemd? Non teño nin idea de onde o consegue, porque como ve a miña resposta non lle teño medo, só falo de aspectos que non me gustan de systemd e xa sen contar coas opinións de terceiros.
Finalmente, dis que: "Se o programador foi tan malo para non incluír código que poida tratar con entrada e saída inesperadas, iso é outra cousa ..."
Certamente dicir que o programador por non incluír un código que manexa TODAS as formas posibles en que o seu programa pode ser roto por algunha entrada de datos errónea é MAL, paréceme unha indignación. Non importa o bo que sexa un programador, unha persoa non pode deseñar un programa infalible e seguro, SEMPRE haberá un fallo, que dun xeito ou doutro sairá á luz e, cando o faga, será grazas a un fallo aleatorio durante o seu uso, por un hacker ou cracker que explota unha vulnerabilidade, por unha revisión e auditoría de código ou por calquera outro medio co que o programador poida contar. Mellor medir as palabras antes de dicir algo así.
Saúdos.
O exemplo que pon de Xorg é o menos adecuado porque todos os que sufriron a transición a KMS / DRM saben que o problema é causado por erros nos módulos do núcleo para controlar os KMS proporcionados polos desenvolvedores dos controladores Xorg. Un erro nun módulo KMS é o mesmo que o pánico do núcleo, non ten nada que ver coa comunicación entre procesos, porque nese caso é Xorg o que fai unha chamada de sistema (syscall) para que o núcleo cambie o modo de pantalla, é dicir, hai só hai un proceso implicado (Xorg) que chama ao núcleo, nada que ver co que estamos a tratar aquí.
O comportamento actual de systemd cando non atopa o punto de montaxe é irrelevante independentemente de que sexa unha funcionalidade que poida que non lle guste a alguén, que se resolve pedindo que admitan o outro comportamento, o de ignorar o monte fallido. O descenso ocorrido antes podería deberse a causas diferentes que só se podían especular, pero o feito de que a execución non continuase pode deberse a un comportamento desexado, xa que dis que houbo que reiniciar e non que houbese un núcleo. pánico ou un reinicio automático. Como non o pasei non podo opinar.
Respecto ao problema que puxeches con systemd-coredumpd e a ligazón ao informe de erros, todo indica que este problema en Arch Linux debíase á compresión que habilitaron systemd cando o compilaron para esa distribución. Parece máis un problema co algoritmo de compresión que co propio systemd. O sistema operativo non está fallando, máis ben o algoritmo de compresión usado para almacenar os coredumps parece estar drenando o sistema e iso é culpa dos desenvolvedores de Arch Linux que compilaron systemd. Non obstante, systemd ten axustes para limitar o consumo de recursos e habilitar / desactivar a captura de todos os botes de memoria informados polo núcleo. Quizais os mantedores de Arch de systemd e os que empregan KDE deberían botalos unha ollada.
Vostede di que OpenRC tamén usa cgroups sen ser invasor. O problema é este: como recoñece OpenRC o nome dos executables do demonio para saber exactamente que asignación de recursos é a máis adecuada? Non estou seguro de se esta é unha das razóns polas que systemd se encarga de tantas cousas, dándolle un nome coñecido aos executables, pero sospeito que a cousa vai así. Ademais, elimina a carga de ter trazo no medio para executar cada un destes servizos, invocando directamente os executables.
Non negarei que systemd pode ter moitos erros, pero a partir de aí atribuílos a todos ao xeito no que se concibe, non o creo. No caso de sysvinit, era moi estable, un software maduro, systemd acaba de comezar.
https://www.reddit.com/r/LinuxActionShow/comments/2nv4hp/ask_lennart_poettering_a_question/
Como rebentan bolas con systemD, xD Se tanto o odias, crea a túa propia distribución, iso é para o software libre é_é
Non se trata de odio, senón de defender a túa comunidade.
Por certo se hai distribucións "Underground" independente:
http://gutl.jovenclub.cu/neonatox-un-linux-iconoclasta
Respecta
porque compárao todo con Microsoft para que se comporte como Windows .. se as cousas funcionan ben e é para o desenvolvemento e a evolución de Linux cal é o problema ... cada proxecto ao principio pode ter erros nos cambios se os programas de software etc. fosen perfectos, Somos humanos, pero por iso temos erros.
que se falla systemd, o sistema fallará ... e se falla o kernel, xorg, grub ... hai xente que, actualizando o kernel no seu PC ou portátil, perde o sistema ... entón porque a insistencia no perfección de algo ...
coma se algún sistema saído non tivera erros de erros ou algo nos seus inicios ou incluso na súa madurez tivera fallos
Systemd impúxose como estándar con xogos sucios, é unha dependencia obrigatoria para moitos paquetes porque moitos programas foron absorbidos por systemd ben porque os mantiveron ou porque os eliminaron lentamente xa que xa non eran relevantes porque systemd xa proporcionaba algo similar.
Isto limita a liberdade de elección, é dicir, as distros non poden escoller NON usar systemd, poden intentar resistir como gentoo, pero iso é máis unha solución temporal para systemd, openrc é só un xestor de servizos soportado por sysv para init e initscripts distro , systemd ofrece máis funcionalidades que openrc e ten novas funcionalidades todos os días. O novo software admite systemd e require implementar algo semellante, o que acaba por facer as outras inits máis complexas e máis semellantes a systemd, que non é o que quere.
Systemd fai moitas cousas en comparación co antigo init que simplemente le un par de liñas de / etc / inittab e logo carga cada un dos initscripts e as súas configuracións segundo o nivel de execución. O enfoque antigo era moito máis sinxelo e máis independente. Estamos nunha etapa de transición cara a unha nova era de homoxeneidade, non hai solución, a forma en que prevalece é imparable.
En poucos anos non haberá practicamente ningunha diferenza entre usar debian, usar arch ou fedora, a identidade de cada distro perderase se seguimos así e systemd farase máis intrusivo cada día que incluso pasará a formar parte do nome do sistema (systemd / gnu / linux)
LOL
Chorar á igrexa>: D
Que di Don KZKG, déixovos isto: https://blog.desdelinux.net/systemd-vs-inteligencia/#comment-127648
O problema é que es arxentino (eu tamén) pero a forma de expresarse que a maioría dos usuarios arxentinos de Linux que leo é realmente preocupante, aínda que tamén se di que o mundo do software libre atrae a determinadas persoas. O que rescato é que non presume de ser arxentino, pero desafortunadamente mostra ligas.
uyyuyy .. ese rapaz caeu con artillería pesada ..
forte comentario !!
Juju .. ..pochoclos .. xD
Deste artigo despréndese que o único que fan é "impoñer" un sistema. Non entro a valorar se é mellor (que non) ou peor. O que digo, repito, subliño e subliño, é que realmente non quero que me impoñan nada.
Frases como: "Simplemente non as usamos para o proceso de inicio, porque pensamos que non son a mellor ferramenta para ese propósito específico".
E quen es ti para dicirme se quero usar tal ou cal ferramenta?
Alí cada un. Simplemente non o uso, punto e, aínda que poida que non, non o farei.
Asinado. Un talibán.
(É que me fan gracia as trapalladas)
moitas veces unha dor de cabeza con ese tema !!!! X_X
Xestionaba servidores con Centos 6 e ía a 7 con systemd non me custou nada, non chores, a vida segue.
Desculpe, pero estou lendo moitas cousas que me lembran o clásico discurso "Windows Server - Certified Man VS Linux Server - OpenSource Man".
1o - Verás, se forzas un erro, o normal é que falla. Todos e cada un dos vídeos que vin son erros forzados. É coma se fixera un programa que introduce palabras clave no rexistro de syslog e ao mesmo tempo intento executar un script baseado en grep para extraer información do rexistro ... por suposto que vai fallar, eu causeino.
É como botar azucre nun motor diésel e dicir "Mira ... a gasolina é mellor !!!" ou como fai o Windows, escribe un ficheiro de configuración mal e quéixase de que o demonio non comeza a dicir "con Windows isto non ocorre".
2o - Ese sistema incorpora moitas cousas que quizais non vas usar? Pois cal é o problema? É que é o mesmo argumento baleiro empregado por Windows fronte a Linux ... "Por que quero que un texto sinxelo poña mil e unha opcións cando non as vai usar.
Aínda oio aos rapaces de IBM cos seus programas monilíticos ladrando hai anos sobre mysql cando lin algunhas cousas. Agradezo e aplaudo a diversidade de GNU / Linux e a súa comunidade. Se me das 50 xeitos de facer algo, escollerei en cada momento o que mellor me funcione ou se adapte ao que necesito. ¿De verdade ves algún problema nisto?
3o: polo nivel das conversas, deduzo que tes un nivel suficiente para traballar con calquera distribución ou configurar a túa e mantelo ti mesmo. Por que queres poñer systemd e eliminar cousas del? Non é máis fácil continuar co seu init ou openRC?
Á xente que me pediu que lles ensinase os conceptos básicos de Linux sempre lles digo o mesmo ... GNU / LINUX non é Windows, non tente facer as mesmas cousas nin pense coma se fose. Por que asimila que sistemd é o mesmo que initd ou que funciona igual? Non é máis doado asimilar o funcionamento de systemd e utilizar o seu potencial que intentar facer funcións como init ou OpenRC? É normal que non che guste.
4o - Que pasa coa complexidade? Seguro que aínda lembras cando deu programación lineal e iso seguramente nalgún momento dixo: «E por que quero aprender a traballar obxectos se agora podo facer todo e se non me deixan usar?» ... (O facepalm un par de meses despois é xenial se xD)
Sexamos claros. O init actual (e inclúo systemd) ten moitas deficiencias que só se poden encher engadindo complexidade. Non hai outra, xa que para que poida crecer un sistema interconectado, ten que medrar en complexidade a risco de ter unha parte débil, pero é mellor que permanecer estancado.
Leva moito camiño por percorrer e se ... sistemd non é a solución a todo. Pero tampouco queda con SysVinit.
PD: Teña en conta a ironía de que usei a PC do meu colega "I cling to windows-server defender" para que poida lelo por certo. xD
Só unha cousa, aos defensores doutros INIT que proporcionan datos técnicos e ligazóns ... CHAPO !!! Encántame ver argumentos e datos coma este. Só unha nota: os datos anteriores a outubro de 2014 son meramente históricos.
Moitas cousas que se comentan xa se arranxaron e moitos bancos de probas publicados en 2013 xa foron revisados.
@rolo
Se é certo, se viches o vídeo, o que NON fixeches, podes ver que o rexistro é de 8 MB, nada máis e así sucesivamente e todo está corrompido, por certo, podes enviar a saída de journald a syslog en texto plano? Si, pero aínda así se toca os rexistros creados por journald, iso ocorre, o sistema colga e, é comprensible, a ver, o xornal colga no PID1 xunto con cousas tan complexas como systemd, falla, ves que non o fai. ten algunha parte do código que non permite editar algo que non sexa o mesmo PID de journald, así como non ten a capacidade de continuar escribindo máis aló do rexistro está corrompido, o que demostra que ademais de pensar en modo Windows, LP é un mal programador.
Non me digas que será só en centos, a versión máis estable da distro que usa systemd, clon de RHEL7, e non informe nin penso informar do erro.
A verdade é que canto máis leo os comentarios pro systemd, decátome de que realmente son como unha relixión, ou estás a favor ou es o inimigo, pero, desas relixións tipo ISIL, as do estado islámico, totalmente extremista, de feito, sei por experiencia, amantes do sistema, eles pensan que si, ou estás con eles ou es o inimigo. Iso é o que Lennart promove coa súa arrogancia e, por favor, non me jodas con Linus apoiandoo, systemd non era isto, NON FOI, usei systemd nada máis saír en Fedora 15 e foi só un init máis rápido, non substituíu a modularidade GNU / Linux.
Se mato rsyslog, corroo os seus rexistros ou o substitúo por un debuxo, nada máis, só que me quede sen rexistro, nada se colga, o sistema non se ve afectado.
@Rafael Mardojai
Iso é o que fai Devuan, iso foi o que fixo Void Linux e outros que se afastan de systemd.
@Yukiteru
Seguro que ninguén te le, como me din talibáns, non te len porque utilizas Windows ou comentaches dela e porque creo que poucos dos amantes do sistema entenden a parte técnica do que dis e aí está o problema.
======
A verdade é que aínda creo que unha persoa coñecida no 2006 tiña razón sobre algo:
"Non quero que a xente use Linux nin o saiba, estes rapaces de Ubuntu teñen a pelota chea"
Eu- "Por que?"
"Cando algo se coñece para as masas, caga, fode e hai moitas mostras diso"
Eu- "como cales?"
"Mira o que lle pasou a Debian, agora ten un fillo parvo chamado Ubuntu e recorda que dentro duns anos imos ter" hackers "e" frikis "que chuparon Ubuntu e non saberán distinguir Ext3 de NTFS"
Algo estaba ben .... systemd triunfa entre os que saben, como di Allan McRae, porque non lle importa como arranca a súa máquina, para el é o botón, a maxia e teño un aviso. Entre aqueles aos que non lles interesa máis que "traballar" con boas funcións, total, para que o servidor utilice realmente LFS ou Gentoo ou BSD e logo os que lles encanta porque acende o seu PC máis rápido con luces de cores, fermosos sons e xogos de azar , pero non saben o que é un syscall.
@SynFlag se non o len por decisión propia, en canto ao sistema operativo que uso, se estou no meu traballo e comento desde un PC con Windows, é porque é o único que teño a man, agás o servidor que está en Debian Wheezy e obviamente desde o servidor non podo comentar aquí.
Incluso na casa víronme obrigado a usar o PC da miña irmá porque o meu PC morreu (o MB e a fonte de enerxía conspiraron contra min), e aínda así, cando teño tempo, monto un LiveCD e uso Sabayon (con OpenRC) para comentar aquí, como estou facendo xusto cando escribo estas palabras.
Agora, se me din ou pensan que son un talibán antisistema, iso non me importa. Como dixen, usei systemd e sei que a perna coxea, non só iso, normalmente leo moito a lista systemd para saber sobre as cousas que veñen nas novas versións e tamén para estar ao tanto dos cambios que se fan. e das discusións que alí teñen lugar. Agora, se algún amante do systemd entende o aspecto técnico do que falo e poño nas miñas ligazóns (as ligazóns ao systemd git repo sobre todo), e aínda así non é capaz de ver a realidade, iso só me permite pensar que vendo nos seus ollos e o extremismo na súa forma de ver / pensar / sentir / amar / glorificar / eloxiar / adorar o sistema é tan xenial que non importa se ata o propio Linus expulsa o **** fóra do sistema. aínda estar enraizado nas súas ideas de que son correctas.
Ola! Non son moi experto e gustaríame saber para que serve este "systemd" e por que se fala tanto, cal é o problema e que alternativa hai? grazas
O comentario SynFlag! Son de "frikis", "frikis" e "pro linuxeros" ata o mesmo.
E ese é o futuro que nos espera; Ubuntu incluso na sopa; Portátiles Linux para acceder a Steam e xogar ao último xogo. E lexións de pequenos frikis que non saben de que vai a vaina.
PostScript: o concepto de fondo de systemd é unha merda.
os botóns adk e foro non están visibles na páxina principal
Así, segundo @SynFlag, agora todos os que non son anti-systemd son un fanático relixioso extremista n00b e a peste que corrompe GNU / Linux. Cunha opinión tan estreita coma esta, non sei se paga a pena debater sobre este tema. Mellor deixar correr a auga e a longo prazo sucederá o que ten que pasar.
É certo, chega un punto que xa non se pode discutir. só o tempo diranos se sytemd vai ser algo positivo para o mundo do software libre ou non.
Tamén me dá a idea de que se esta distribución baseada en debian que non vai usar systemd chega a bo porto, axudará a calmar o espírito dos que non queren saber nada sobre systemd.
como cando apareceu gnome 3 e se construíu unha tremenda resistencia, ata que apareceron a canela "fork" e a unidade permitindo seguir usando as aplicacións gnome nun escritorio con máis configuracións e un deseño máis pensado para o PC e non tanto para o tacto
Quizais iso, Rolo (a aparición de Devuan), poida ser un punto de consenso. Creo que todos o necesitamos para conter un clima de debate polarizado e belicoso. Devuan será un espazo para a creación e continuidade dun xeito de facer e que axudará a calmar os ánimos. O proceso que vivimos en Debian foi doloroso, non obstante debemos afrontar a situación, non queda máis remedio que aceptar a separación. Isto acaba sendo un pouco como divorcios. Esta bifurcación pode ser a transcrición dun tratado de paz e parte del. Había alternativas, por suposto, Slackware, Gentoo, Funtoo, Crux, PCLinux OS, agora Manjaro (por citar algúns) ... pero a escena "deb" requiría unha alternativa sen systemd. Parece claro que ninguén vai convencer a ninguén, os argumentos están sobre a mesa e non hai consenso (a pesar de que systemd ten boas ideas e os perigos que supón este software son evidentes). É hora de bifurcar e obter liberdade para o usuario (porque se trata de software libre, non?).
Un dos factores que influíu no proceso foi o sentimento de "decepción" por parte de algúns de nós que depositamos a nosa confianza en Debian. É por iso que Devuan preséntase como un garfo e non como derivado. Hai tensión porque a ninguén lle gusta o que pasou; nin os pro-systemd (de aí certos ataques furiosos que intentan difamar) nin os anti-systemd (que optaron pola bifurcación). No entorno está o "canto talento podemos perder?", Tanto por unha banda como por outra.
Todos os usuarios de Debian miran a distro dun xeito "certo" (isto tamén se pode aplicar a outras distribucións). Hai quen admira a súa calidade técnica, outros o seu contrato social, a súa influencia no mundo Linux, o respecto que gañou ao longo dos anos, a súa estabilidade en contornas críticas de produción ... Nalgúns usuarios esta percepción alterouse, aparecendo decepción . Decepción, desencanto, chámalle como queiras. De aí á separación só hai un pequeno paso.
O divorcio de Debian é similar ao que ocorreu con NetBSD e OpenBSD. Aínda que o tempo o dirá. Vexo moitas expectativas no garfo e iso faime pensar que non será unha distribución fugaz e estéril. Hoxe mesmo houbo un membro do equipo gnome comentando a lista de correo de Devuan (aínda que o fixo torpemente), isto, na miña opinión, suxire que Devuan xera interese e quere, dalgún xeito, dialogar.
En fin, boa fin de semana.
@rolo
Dicir que o vídeo se pode enganar ou que o software é unha falacia e un insulto total, na miña vida de PU ** enganei algo para crear un mito, nunca, gábome de ver ese fracaso polos meus medios, non polos meus trucos. Todos van ao **** que ao ***** e non vou poñer máis en debates systemd porque está totalmente mal, ninguén quere entender nada e todo é como unha relegión, o que, odio , porque todo é por dogma de fe. Sexa feliz con systemd.
@SynFlag a violencia está mentindo
O que demostra este vídeo é a falsidade da afirmación de que se un dos módulos systemd está arruinado, fai que systemd falla, xa que obviamente, polo que o teu vídeo mostra que non ocorreu, xddddd e por certo o diario funciona como root, polo tanto, se entra un terceiro e fode maliciosamente o rexistro binario do diario, non me preocuparía o systemd senón a seguridade do seu ordenador. xdddddd. Finalmente, no asunto do vídeo, replica o que se mostra editando con nano o ficheiro /var/log/journal/24f02f5b2b16758b820ea6a751ed6efb/system.journal e cando reinicie comproba que hai un novo system.journal e un sistema @@ 24f02f5b2b16758 @@ 820f6f751bXNUMXbXNUMX. Diario que é o binario corrompido.
Noutras palabras, o diario dáse conta de que o ficheiro está corrompido, polo que non o renomea e volve crear un novo, non vexo cal é o problema nese? Crear.
Pregúntome que pasaría se arruinara un ficheiro de rexistro de texto sen formato cun editor hexadecimal, seguramente ata que te decates de que o ficheiro estaba corrompido, todos os datos serían destruídos
Falemos un pouco do xornal, que é unha das críticas máis comúns a systemd.
journal é un compoñente moi importante de systemd, que captura as mensaxes Syslog, as mensaxes de rexistro do núcleo, a RAM e as mensaxes iniciais de inicio, así como as mensaxes escritas en STDOUT / TDERR e pon toda esta información a disposición do usuario.
Pero o máis importante é que o xornal pode usarse en paralelo ou en substitución dun daemon syslog tradicional, como rsyslog ou syslog-ng, polo tanto, un administrador sys prudente pode ter rsyslog ou syslog-ng como segunda ferramenta de consulta, ademais de transformar rexistros de diario. en texto plano por se o binario se corrompe
Outro dato importante sobre o xornal é que se non se crea o cartafol / var / log / journal, a información só se garda temporalmente, que se perde con cada reinicio.
por exemplo, cando entrei systemd en debian a persistencia do rexistro non estaba activa polo que tiven que crear manualmente o cartafol de diario
http://0pointer.net/blog/projects/journalctl.html
Os que saben inglés, non poden perder as conversas que están a ter lugar entre os desenvolvedores de devuan, jaromil dimkr max2344 entre outros na canle IRC de freenode #devuan.
Moi divertido lendo as investigacións do código systemd xa que o difundiron a propósito para infectar (crear dependencias innecesarias).
Systemd amólame ... de fronte ... é difícil. Pouca documentación ou o carallo slim só funciona con KDM ou gdm e nun sistema lixeiro quero que lxdm slim non o admita nin o compile ... Serio que incluso antes ... estaba contento con que deberían. A verdade é que empecei a usar openrc como se di en gentoo e axudou ... Moito
@rolo
Vostede é un malformador insolente e informativo para dicilo. É o peor insulto que me digas que minto ou falsifico datos, realmente me disgusta como para defender algo atacas a persoas que fan PoC serios coma min. O rexistro está corrompido, o sistema falla, reiniciar o servizo non funciona polo que non queda outra que reiniciar a máquina, que non é a mellor nun servidor pirateado, me dirás que se a seguridade se comprometía, o mellor é reiniciar ou reinstalar e é o único que me debería preocupar cando o sistema di que se excusan e non fan unha análise en quente de QUE PASOU? para chegar a ese punto? Obviamente, es un produto máis do novo administrador de sistemas se chega a iso que se plantexou usando Ubuntu e ten a seguridade dun DOS 5.0 no teu PC, entón o que digas tómoo de quen vén, moléstame que dubida tamén O que falsifica es ti, respondiches ao mesmo sistema operativo coas actualizacións dese día? Seguro que non, así que tenta mentirlle a outro. Que falta de capacidade tes, vai traballar como taxista máis que iso dubido que che dea, deixe de xogar con Linux e siga buscando pr0n
Vexamos pombo (synflag), o pai amosarache como conseguir que o diario continúe funcionando despois de que o noso ficheiro de rexistro binario do diario estea corrompido por algún motivo, sen ter que reiniciar o ordenador.
Neste exemplo partimos dunha instalación base de debian 8 jessie.
Por defecto, systemd-journal.service inclúe a función "storage = auto", polo tanto, para ter un rexistro persistente dos rexistros, é necesario crear o ficheiro en / var / log / journal / previamente.
# mkdir -p / var / log / journal /
Para que o diario comece a escribir os rexistros, NON ten que reiniciar a computadora, simplemente faga:
# systemctl recarga systemd-journal.service
o
# systemctl forza-recarga systemd-journal.service
### agora imos simular que o rexistro binario do diario está corrompido ###
# cd / var / log / journal
#ls
24f02f5b2b19808b820ea0a980ed6efb
# cd 24f02f5b2b19808b820ea0a980ed6efb
# nanosystem.revista
### agora modificamos algunha liña do ficheiro para simular que está corrompido
#diario
### como se esperaba non pasa nada
#### ten que reiniciarse o ordenador para que o diario cree un novo binario? NON
# systemctl forza-recarga systemd-journal.service
#ls
system@24f02f5b2b19808b820ea0a980ed6efb-0000000000000001-0005069a53abf581.journal
sistema.xornal
#diario
### Como podemos ver, o diario crea un novo ficheiro de rexistro binario e agora podemos acceder á información de novo sen ter que reiniciar o ordenador en ningún momento
https://www.youtube.com/watch?v=hEagyMdkN4A&feature=youtu.be
conclusión: synflag ou ignorante ou fabulador
déixeo que te decore finito
por erro de dixitación e abuso de copiar e pegar escribín systemd-journal.service cando en realidade o servizo chámase systemd-journald.service
Pichon?, ... que equivocado estás delgado, en serio .. Xa o sabía, informa do bicho con sombreiro vermello para ver o que dixeron, acertarei a resposta, a ver se colles:
Se elimina o ficheiro de saída ou sobreescribe partes do ficheiro, o daemon non pode facer nada ao respecto: se un atacante ten permisos para modificar o ficheiro de saída, xa gañou. O demonio podería comprobar algunhas desas cousas, pero iso sería bastante ineficiente e non sería realmente útil para nada. Se queres, podes configurar unha sinatura criptográfica periódica con 'journalctl –setup-keys'. Vexa a páxina de man de journalctl.
Journalctl depende de rsyslog, non se reinicia automaticamente en caso de erro no rexistro, que rsyslog non precisa, total, ten que empregar para adiante para enviar a rsyslog e así está escrito a pesar de todo e o rexistro de rexistro está rexenerado , é un defecto de deseño de xornal, se non queres velo, bótame.
@rolo
No vídeo (non sei se o fixeches) vexo que no minuto 2:11 úsase ls e non ls -l o que permitiría ver o tamaño que tiña orixinalmente o ficheiro system.journal, entón edítano con nano e engade liñas baleiras, reinicia o servizo a man e no minuto 3:15 volven facer ls e non ls -l, despois no minuto 3:20 ven o rexistro con journalctl, isto mostra o rexistro actual que está ben.
Agora veñen as miñas preguntas:
1 - porque se usa ls e non ls -l, para poder ver o tamaño orixinal que tiña o rexistro antes de ser editado
2 - que pasou co vello tronco? onde o colocou systemd no rexistro binario corrupto?
3 - con que comando systemd podes reparar o teu rexistro binario corrupto ... que non se supón que debes eliminar
lembranzas
@anónimo
Agora veñen as miñas preguntas:
1 - porque se usa ls e non ls -l, para poder ver o tamaño orixinal que tiña o rexistro antes de ser editado
2 - que pasou co vello tronco? onde o colocou systemd no rexistro binario corrupto?
3 - con que comando systemd podes reparar o teu rexistro binario corrupto ... que non se supón que debes eliminar
1 a verdade que non o pensei, só usa ls para ver que ficheiros había no directorio, pero se estás interesado podes replicalo, o procedemento está detallado e fágoo en virtualbox (a instalación dunha base de debian é un anaco de bolo)
2 o vello rexistro permanece no mesmo directorio, só systemd renoméao cun montón de números e letras (amosado no vídeo)
3 En calquera caso, podería tentar empregar aplicacións de terceiros (supoño algún editor hexadecimal) xa que se systemd puidese reparar o ficheiro corrupto non o renomearía nin crearía un novo. En calquera caso, e como xa mencionei noutras ocasións nesta publicación, un administrador sys prudente podería usar rsyslog ou syslog-ng como segunda ferramenta de consulta, ademais de transformar os rexistros de diario en texto plano no caso de que o binario se corrompa.
Quero dicir, non é a idea de convencer a ninguén para que use systemd (incluso me encantaría que no instalador de debian exista a posibilidade de escoller o int). pero non vou gardar silencio cando lin ignorantes ou fabulosos que seguen repetindo mentiras sobre systemd, xa que existe un blog, cando se ve que eses refráns non coinciden coa realidade. e como dixo Aristóteles, a única verdade é a realidade 😉
@rolo
Mirei de novo o vídeo e se, alí figuraba, só o nome numérico era tan longo que o vin, pensei que ese era o directorio .... Nome soberano.
Respecto á reparación do binario, si, é lóxico o que dis ... se puidese reparalo non crearía un novo.
Finalmente quédame con que non debería ser un binario para que isto non suceda e poder velo sen ferramentas especiais con journalctl ... aínda non entendo o que o levou a usar un formato binario.
Un saúdo e grazas por responder
Rolo, dedícate a outra cousa:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393
Sabíao sen sabelo ... Como notas a diferenza entre un que está probando cousas e outro que só fai vídeos de peidos
Veño a pechar o ocote de Rolo, o erro que se ve no meu PoC fora denunciado, así que, pecha o ocote pichon:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4393
Vexamos fabulosos:
1 Afirmou que para que o diario resolvese o problema era necesario reiniciar o PC como en Windows TOTALMENTE FALSO
Mostreiche que era mentira e no vídeo que fixeches en ningún momento usas o comando systemctl force-reload systemd-journald.service porque se o empregases o teu argumento fallaría (ou non sabías o comando , o que demostraría que es un ignorante ou non o usou intencionadamente, o que demostraría que es un contador de historias)
2 Vostede di que hai informes de erros, por un lado é totalmente irrelevante xa que normalmente a xente denuncia moitas tonterías como un erro (para que entenda que non todos os informes de erros son un verdadeiro erro) incluso me dá a idea de que informou vostede mesmo. E por outra banda, todos os programas teñen erros (cantos erros informados ten sysvinit (un programa que ten uns 20 anos)) e o bo do informe é que axuda aos desenvolvedores a descubrir e resolver problemas (algúns máis rápidos) , outros máis lentos)
3 Di que co erro que xera no diario, cando reinicia o sistema, falla xa que no vídeo pode ver que ten que reiniciar forzosamente a caixa virtual. COMPLETAMENTE FALSO
A verdade é que systemd non falla xa que o sistema comeza perfectamente (se non arrincase systemd daríalle pánico ao núcleo e tería que entrar no modo de recuperación)
O que che pasa é que o sistema está comprobado cando tenta editar un binario cun editor de texto e os factores poden ser moitos, como a memoria asignada, o estado do sistema operativo (no vídeo o sistema leva moito tempo para arrincar e desactivar o que suxire que non se trata dunha instalación limpa de 0 (recomendable para este tipo de casos), etc. Só podo dicirche que o binario que editei unhas 10 ou 20 veces e nunca se comprobou. Isto tamén demostra que es un ignorante ou un contador de historias.
4 Agora dis que o xornal depende de rsyslog TOTALMENTE FALSO, o certo é que calquera pode comprobalo instalando ou desinstalando rsyslog e vendo que o xornal funciona perfectamente
Agradeceríame moito que deixase esa obsesión pouco saudable comigo, non é culpa miña que sexas ignorante ou fabuloso
Conclusión:
Non queres usar systemd, paréceme xenial, agora non tes necesidade de espallar terror con mentiras para conseguir seguidores da túa cruzada antisistema. Vivín e deixei vivir, que hai un lugar para todos no mundo do software libre 😉
unha aclaración sobre o punto 3, alguén me diría que como systemd está en pid1 un fallo da máquina implicaría ese casco systemd. Dúas cousas, primeiro aquí o que se afirmou é que systemd fallou debido ao fallo do diario, pero en realidade hai unha verificación para introducir un binario (que se está a usar en tempo real) cun editor de texto, tamén aclaro que en todos os as probas que realicei nunca comprobaron a máquina virtual. En segundo lugar, ninguén no seu xuízo pode afirmar que Linux non está etiquetado como xddd,
¿Fabuloso?, Fraco, frea un pouco, fabuloso a túa vella que di que tiro a goma cando non a toco cun pau, volvo respectar:
1.- Ten que reiniciar ou forzar o reinicio do servizo, o que non é o ideal e en CentOS 7 cando tentei o reinicio do servizo non fixera nada, non esquezas que é a versión 208 non a nova 217 ou 216 de Fedora.
2.- ¿Irrelevante e os que denuncian erros? ... es un idiota, nin sequera che respondo
3.- UNHAPPY, a versión que tentei ese mesmo día do vídeo, que podes ver, caeu todo o sistema operativo, por que cres que a orto infeliz mentira? Non son un simio mentireiro, vai tomar cindor pajero.
4.- Depende auto-rexenerarse a si mesmo, non o fai por si mesmo de feito suxerínllelo aos devs do sistema como característica, que se rexenerase sen deixar de rexistrar a menos que se reinicie o servizo, tomárono como o que son para engadir, así que chupa a miña polla e dime grazas papá por colaborar mentres vexo porno.
Adeus fraco, canso de falar cos monos para iso prefiro ir ao zoo, cando estás ao nivel do meu ano charlamos.
@SynFlag Pido desculpas, non sabía que estabas enfermo, realmente pensei que eras un fabuloso e ignorante, pero co que acabas de escribir decátome de que en realidade es un delirio.
bueno nada, espero que gradues mellor a túa medicación e volvas á realidade, forza! podes!!!
Lin, leo e relo pero non entendo nada, só sei que dende que Xubuntu 14.04.1 saíu á data non tiven ningún problema co meu portátil ou coa miña impresora láser hp 1102, non sei nada, son usuario e non sei se systemd é peor ou non é adecuado para init, pero repito que non teño problemas con xubuntu. 🙂
Lin, leo e relo e só sei que revivo un vello tema. XD