OpenRC sur les isos Manjaro pour les haters Systemd

Aujourd'hui, en lisant mon RSS, j'ai découvert une nouvelle intéressante que le Blog Le look du réplicateur, et c'est que dans la communauté Manjaro plusieurs ISO ont été lancés avec la particularité qu'ils n'utilisent pas Systemd comme init, sinon OuvertRC, le système de démarrage utilisé par Gentoo.

OuvertRC

Je ne sais pas pour vous, mais le thème Systemd me touche déjà beaucoup, et plus je lis, plus je me rends compte que même si pour l'utilisateur final (ou pour beaucoup) cela ne représente rien de super pertinent, à le moins pour moi, je n'aime pas le chemin que cela prend. Je crois qu'une saison noire arrive dans le monde de GNU / Linux, où les fourchettes et le mécontentement éclateront même dans les déserts arides.

Mais passons aux choses sérieuses. Dans le forum Manjaro, ils ont publié, comme je l'ai déjà dit, des isos utilisés par OpenRC. Et pour ceux qui ont peur d'installer ces versions, je laisse la vidéo sur la façon de le faire.

Télécharger des ISO avec OpenRC

Le premier ISO que nous verrons est la version NetInstall. Cette ISO a les caractéristiques suivantes:

  • Basé sur le profil Manjaro-Net (n'a pas d'environnement de bureau pré-installé)
  • Basé sur la branche Testing.
  • Seuls les pilotes gratuits
  • Utiliser la série du noyau Linux 3.14
  • N'utilise pas Plymouth
  • Il a été testé dans Virtualbox

La langue peut être sélectionnée au début en appuyant sur la touche F2. Une fois le processus de démarrage terminé, nous trouverons l'invite, où nous utiliserons pour accéder:

  • Utilisateur: root
  • Mot de passe: manjaro

Pour démarrer l'installation comme indiqué dans la vidéo précédente, nous écrirons:

setup

Liens pour télécharger les ISO

manjaro-net-0.8.11-openrc-i686.iso (32 bit)
(md5sum: 80be54ecfb0360b2a8e544344f72113c)

manjaro-net-0.8.11-openrc-x86_64.iso (64 bit)
(md5sum: ef205f70f3b3428545fdf1420db10b74)

Instructions après l'installation

Dans le Forum sur Manjaro Ils nous offrent quelques données pour la post-installation:

Nous ajoutons le référentiel openrc-eudev en suivant ces instructions.

1) Nous ajoutons ce qui suit à la fin de /etc/pacman.conf

[openrc-eudev] SigLevel = Serveur TrustAll facultatif = http://downloads.sourceforge.net/project/mefiles/Manjaro/$repo/$arch

Nous ajoutons et importons les clés:

sudo pacman-key -r 518B147D sudo pacman-key --lsign-key 518B147D

2) Nous mettons à jour le système

sudo pacman -Syu

3) Nous installons notre environnement de bureau préféré, l'exemple utilise lxde

sudo pacman -S lxde

Vous trouverez des informations sur l'installation des environnements de bureau dans le wiki.

4) Nous installons un gestionnaire de session:

sudo pacman -S lxdm-consolekit
Le gestionnaire de session doit également être défini dans le fichier /etc/conf.d/xdm et il y a plus d'informations ici ! y ici !

5) Nous installons des packages comme l'applet pour networkmanager

sudo pacman -S applet-gestionnaire-de-réseau

6) Nous redémarrons le système

sudo redémarrage

Je pense qu'il va sans dire que pour cela, nous devons être connectés à Internet via un câble. Si nous utilisons le WiFi, vous pouvez voir comment le faire dans ce lien.

ISO Manajaro avec OpenRC et OpenBox

Dans le cas de l'Openbox ISO, certaines choses doivent être prises en compte:

  • L'objectif principal est de faire le processus d'installation plus facile et permettre configurer forme graphique la red (en utilisant wid) et le partitionnement à l'aide GParted éventuellement.
  • La configuration comprend Navigateur Web Openbox WM, LXTerminal, PCMan et NetSurf (pour chercher informations dans le wiki o google), et ainsi de suite
  • Utilisez le programme d'installation de la console.

Liens pour télécharger les ISO avec OpenRC:

manjaro-openbox-openrc-2014-11-13-i686.iso (32 bit)
(md5sum: 9be7e75c75ab296f955a3396386c4764)

manjaro-openbox-openrc-2014-11-13-x86_64.iso (64 bit)
(md5sum: 07fd57df022118dfc9e2794a0ca3d26e)

Manjaro XFCE ISO avec OpenRC

Uniquement expérimentalement et pour 64 bits, il existe également un ISO avec XFCE:

manjaro-xfce-openrc-2014-11-14-x86_64.iso (64 bit)
(md5sum: e132f294f2ffd99c6cbc371d1e7a6d72)


Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données: Miguel Ángel Gatón
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.

  1.   l'un de certains dit

    Vous avez raison, le problème de systemd commence à dégager une certaine odeur puisque OpenRC est le successeur naturel de l'init actuel. Nous verrons où cette histoire se termine.

  2.   Wilhelm dit

    "Bien que pour l'utilisateur final (ou pour beaucoup) cela ne représente rien de super pertinent"

    Je pense la même chose, ce n'est pas pertinent car en tant qu'utilisateurs, cela ne nous a pas affectés dans le fonctionnement de l'OS lui-même.

    En fait, le seul grand (debian), a donné des nouvelles de "scandale" sur le sujet, et bien qu'ils disent qu'il y a d'autres raisons, toutes liées à systemd (et ne devraient pas).

    Les autres grosses distributions, elles n'ont pas posé de problème (ou du moins manifesté avec des piques et des torches), Fedora, Ubuntu et OpenSUSE.

    Cela me donne l'impression que c'est un combat entre programmeurs, puisque par exemple opensuse 13.2 a une bonne acceptation / critique et personne dans les revues ne parle de systemd (même si c'est pour établir un débat),

    Maintenant, pourquoi tout le temps de passer de systemd à OpenRC, si au final cela ne les affecte pas.

    1.    dero dit

      Personnellement, le truc systemd me met mal à l'aise, j'ai de l'insécurité, un bon poste.

    2.    Yukiteru dit

      Dans Fedora, il y a eu un débat sur systemd quand il a été décidé de le mettre comme init, il y avait quelques détracteurs du système, principalement parce qu'ils n'acceptaient pas de l'utiliser comme init par défaut car il était très frais et avait de nombreux défauts, cependant , la plupart des principaux développeurs font partie de l'équipe de développement principale et étaient liés à systemd, donc le remplacement d'Upstart par systemd était un signe d'imposition, en plus du problème qu'Upstart était un développement Ubuntu et a un CLA assez froncé sur, ce qui a finalement aidé tout le monde à accepter systemd sans poser de questions. OpenRC était hors de question à l'époque, car il lui manquait de nombreuses fonctionnalités dont il dispose actuellement, y compris la parallélisation et la prise en charge des groupes de contrôle.

  3.   anonyme dit

    Bonne nouvelle! une distribution binaire qui publiera openrc… .c'est comme une aubaine.
    C'est le chemin qu'archlinux aurait dû emprunter depuis le début, je me souviens quand j'ai dû approuver archlinux pour accéder à systemd. J'ai maintenant la possibilité de retester une distribution binaire avec openrc + eudev qui est exactement ce que j'utilise ici dans gentoo.
    Merci aux gens de Manjaro !!!

    # eix -Ic openrc
    [I] sys-apps / openrc (0.13.6@24/11/14): OpenRC gère les services, le démarrage et l'arrêt d'un hôte
    #eix-Ic eudev
    [I] sys-fs / eudev (2.1.1@31/10/14): prise en charge de la dénomination des périphériques dynamiques et persistants Linux (alias devfs en espace utilisateur)

  4.   xiep dit

    Merci pour l'info, elav!

    Je partage votre opinion sur systemd et je suis également préoccupé par la dérive que Linux a prise depuis l'apparition de ce nouvel init. Si Wheezy devient trop vieux avant l'arrivée du fork Debian, je penserai à essayer Manjaro OpenRC, car je n'ai pas le temps libre pour préparer un système Gentoo (j'ai apprécié de le faire mais certainement le temps de compilation de Gentoo l'est aussi étendu pour ma situation personnelle).

    Salutations!

  5.   Cristian dit

    Elav vous pouvez décrire en moins de 10 mots pour un utilisateur qui ne comprend pas trop la "polémique", il y a quelque temps il y a plusieurs articles sur le blog qui sont très techniques, et ils ne finissent pas d'expliquer le contexte de la " non initié "... jamais Ils m'ont dit que peu importe la technique, une explication doit être comprise même par votre grand-mère pour être bonne.

    En fait dans fedora, il y a quelque temps, le problème devenait insupportable, à tel point que plusieurs utilisateurs de bureau pensaient passer aux centos, pour contourner le problème

    1.    Luis dit

      Je m'inscris pour cette demande.

      Systemd fonctionne bien pour moi. Quel est le problème qui cause tant de mouvement?

      Disons que je ne sais pas.

    2.    Daryo dit

      systemd est le programme en charge du démarrage du système, mais les développeurs de celui-ci ont décidé de l'étendre et maintenant non seulement le démarrage mais aussi des choses comme cron (programme pour exécuter des programmes automatiquement), le réseau, les journaux système qui sont d'ailleurs binaires, entre autres

      Beaucoup ne regardent pas favorablement un changement aussi brutal, d'autant plus qu'il s'agit de nouveaux logiciels donc avec beaucoup plus de bugs que de programmes qui avaient fonctionné toute leur vie, en plus de générer des dépendances lors de la programmation et par exemple gnome est de plus en plus lié à ce système. Le rendant moins portable vers d'autres plates-formes Unix.

      Je ne sais pas si mon autre commentaire n'a pas passé la modération mais il disait que j'aimais systemd mais ils ne devraient pas le laisser monopoliser toutes les distributions et laisser des alternatives comme cela a toujours été fait sous Linux pour ceux qui ont des besoins différents.

    3.    Daryo dit

      Je dois dire qu'avant le programme chargé de démarrer le système au démarrage était system v, qui fonctionnait depuis longtemps jusqu'à ce qu'il soit remplacé dans la plupart des distributions par systemd xD.

    4.    animé dit

      À ce que dit @daryo, j'ajoute ce qui suit (ce qui est aussi mon avis):

      J'ai toujours aimé la philosophie Unix où un programme ne fait qu'une chose, mais le fait bien. Quand Systemd veut contrôler tout ce que @daryo vous a dit, j'ai un petit doute et que se passerait-il si Systemd était en quelque sorte compromis? Eh bien, cela entraînerait peut-être tout ce qu'il contrôle.

      À cela, j'ajoute (et c'est peut-être plus par habitude), que j'ai toujours aimé que mes journaux système soient de purs fichiers texte, mais avec Systemd tout est binaire, et des commandes telles que:

      cat log.txt

      o

      tailf log.txt

      Où nous pourrions utiliser d'autres options comme GREP pour filtrer certains contenus, mais Systemd utilise une commande nommée journalctl.

      En plus de ce qui précède, je dois dire qu'étant RedHat le principal exposant derrière Systemd, je reçois une alerte que je ne peux pas désactiver. Peut-être que je me trompe, mais cela n'a pas l'air bien .. Et je me demande toujours quel est le besoin de contrôler le démarrage, le cron, le réseau et combien de services existent? Que veulent-ils dire par là?

      1.    Alexandre dit

        Grâce à votre commentaire et à ce que j'ai enquêté, je peux confirmer vos soupçons, cette alerte est correcte Broder.
        Vous verrez que j'ai lu sur TCP Stealth, c'est une thèse allemande où ils accusent Red Hat de faciliter l'espionnage industriel aux systèmes d'écoute des 5 yeux:
        J'ai déjà écrit à ce sujet, si vous avez le talent nécessaire, je sais que vous l'avez, vous pouvez tirer vos propres conclusions:
        https://gnunet.org/sites/default/files/ma_kirsch_2014_0.pdf
        http://heise.de/ct/artikel/GCHQ-NSA-El-programa-HACIENDA-2293098.html#TCP furtif

      2.    Yukiteru dit

        Juste pour compléter votre gentil commentaire @elav, systemd est si élevé au NIH qu'il prétend maintenant contrôler ce qui suit:

        1.- Gestion des connexions Internet avec IPv4 et IPv6, en utilisant systemd-networkd et systemd-nspawn.
        2.- Gestion DNS via un cache DNS interne, résolu par le système.
        3.- Gestion DNS multicast dans les réseaux internes, en utilisant systemd-networkd.
        4.- Gestion des terminaux TTY sous Linux, en utilisant systemd-consoled. (Au revoir KMScon?)
        5.- Gestion des sessions et des privilèges via logind.
        6.- Contrôle de coredump, en utilisant des fichiers binaires et en ignorant les directives du noyau.
        7.- Contrôle des logs, utilisation des fichiers en binaire, et saut des directives du noyau.
        8.- Contrôle des événements ACPI à l'aide de logind. (Systemd-212 a ajouté plusieurs maux de tête aux développeurs Nvidia avec divers bogues qui ont rendu le système inutile)
        9.- Prise en charge PPPoE pour networkd, un travail toujours en cours.
        10.- Prise en charge de DHCP dans le client et le serveur. (Que font-ils avec ça? Aucune idée)
        11.- Prise en charge des systèmes avec réinitialisation d'usine, qui est d'ailleurs étroitement liée à BTRFS (ne soyez pas surpris si BTRFS devient plus tard une dépendance de systemd, bon Lennart l'adore)
        12 ..- Prise en charge des conteneurs virtualisés (Xen et KVM principalement)
        13.- Prise en charge de la gestion et de l'initialisation des périphériques (ce que fait udev)
        14.- Manipulation des systèmes de cryptage de disque.
        15.- Chargement des modules du firmware et du noyau.
        16.- Gestion du nom d'hôte (il crée jusqu'à un identifiant unique de votre PC), des locaux, de l'heure, de la synchronisation NTP, de sysctl (variables de contrôle du noyau), et même du générateur de nombres aléatoires (Very WTF ceci, et cela soulève beaucoup de soupçon)
        17.- Gestion des systèmes de fichiers temporaires.

        En bref, ce sont les choses que je sais que fait systemd, si quelqu'un en sait plus que le dire :).

        PS: systemd n'offre plus de support pour les scripts LSB et SysV depuis systemd-214, donc je ne sais pas à quel point leur support "hérité" est vrai maintenant ou à quel point ils sont conformes aux normes. Je dis que le LSB est toujours la norme sous Linux, ou est-ce que je me trompe?

        1.    Alan Herrera dit

          Merci de m'avoir fait savoir, je pensais aller à BTRFS mais sachant que Lennart l'aime bien, vous savez peut-être qu'il doit être horrible et espionner la NSA-IBM

    5.    anonyme dit

      Il y a peu de place pour résumer et expliquer tant ... c'est un cheval de Troie géant, qu'ils n'essaient même pas de déguiser. Que fait un système de démarrage en mettant des services réseau, dhcp dns et même je pense avahi ... dans systemd? Le pouvoir de décision est perdu en ne pouvant pas gérer les services
      qui ne sont pas voulues et qui ne viennent pas à moi qui peuvent être désactivées, je ne les veux pas dans le paquet systemd!
      Dans OpenRC, c'est celui qui décide de ce qui est démarré dans chaque niveau d'exécution, certains services ont des dépendances sur d'autres services mais ils sont très peu nombreux et sont répertoriés ... tandis que dans systemd, tout fait ce qu'il veut pour le moment Il en a envie … Pour gagner environ 5 secondes au démarrage et être rapide à l'arrêt.
      Systemd est si complexe qu'il est impossible de savoir ce qu'il fait, vous devez vous résigner à penser qu'il est votre maître et qu'il ne vous fait rien de mal.
      Systemd rompt le concept selon lequel les choses doivent être faciles et compréhensibles en termes de démons ou de services et de niveaux d'exécution, personne qui utilise systemd ne sait parfaitement ce qui se passe dans ses services à tout moment.
      Systemd n'autorise pas l'utilisation de syslog-ng de manière native, ils ont configuré journald pour qu'il marche dessus et il ne le laisse pas fonctionner, c'est-à-dire, ou utilisez-vous journald ou naninga!. Le journal système est quelque chose de fondamental pour la sécurité et l'audit de ce qui s'est passé et se passe avec les connexions locales et distantes, mais journald utilise un format binaire que seul jornalctl peut le voir .... Très souvent journald est corrompu "mystérieusement" son fichier binaire et comme il le voit corrompu, il le supprime une fois et commence par un nouveau, oubliant tous les journaux qui existaient déjà.
      Je peux continuer pendant des heures, mais le pire problème est que Lennart ne donne rien à ceux qui rapportent ces erreurs et pour autant que je sache, il n'accepte les correctifs de personne.
      Je pensais qu'en entrant dans systemd, ils rapporteraient des bogues et des correctifs, que le systemd devrait accepter ... mais je crois honnêtement que Lennart et RedHat ont un autre plan pour le reste des distributions .... comme je l'ai déjà dit , CHEVAL DE TROYA de RedHat.
      Honnêtement, pour moi, systemd n'est pas réparable, l'idée derrière sa conception est terriblement mauvaise, il vaut mieux démarrer un système de démarrage à partir de zéro que d'essayer de réparer ce francestein.

      1.    animé dit

        AMEN!! @anonyme..

      2.    Kunagi dit

        J'utilise systemd (Fedora) depuis quelques années et j'en suis venu à ceci:
        Le problème sent bizarre, car plus de choses ajoutent plus de désactivation / redirection.
        Le journal que j'ai dirigé vers rsyslog directement. Certains de vos journaux binaires ont déjà été rompus.
        Depuis dns, j'utilise bind, s'ils l'intègrent dans systemd, je continuerai à l'utiliser de la même manière, même si je dois tout modifier.
        J'utilise XFCE donc ça m'économise beaucoup de ce que gnome veut intégrer.
        C'est comme un éléphant dans un magasin de porcelaine.

      3.    Tito dit

        Vrai; même ils ne savent pas comment l'appeler. Nous sortons pour mettre à jour quotidiennement, corriger les bugs et autres conneries. C'est un sujet qui me met assez en colère; mais pas seulement à cause du fait que SystemD est une merde souveraine; sinon comment ils l'ont fait.
        Il est clair que dans le monde Linux, il existe plusieurs entreprises qui essaient de tout contrôler; voir Canonical, RedHat et Gnome, (même Miguel de Icaza lui-même a quitté Gnome).
        Si j'utilise Linux, c'est parce que je le contrôle et c'est la base et la philosophie de celui-ci; Afin de ne pas savoir ce qu'il fait, je monte des machines avec W Server déjà en cours d'exécution.
        Ce qui me rend triste, c'est que Debian ait succombé. En fait, la possibilité de créer un fork parallèle sans SystemD est envisagée.
        Espérons que la chose ne va pas plus; ou je me vois migrer toutes mes machines vers BSD.

      4.    Yukiteru dit

        @ anonyme, commentez l'homme, vous ne pouvez pas avoir plus raison.

        systemd est une chose folle qui n'a aucune explication dans beaucoup de choses, la vérité suscite beaucoup de suspicion dans tout ce qu'elle fait et ne permet pas à d'autres outils de le faire, la vérité est que je ne sais pas comment les gens de Debian se permettent de mettre ceci, mais à la fin, ils ont déjà pris cette décision, et pour la première fois depuis de nombreuses années, j'ai arrêté d'utiliser Debian comme système d'exploitation principal, et je continuerai de le faire jusqu'à ce que systemd quitte Debian pour une option plus transparente.

    6.    Tito dit

      En bref. SystemD est nul.
      Il stocke les journaux au format binaire, il est exécuté en tant que processus parent de tous les autres, (Pid 1), de sorte que si l'un d'entre eux se brise, le système devient irrécupérable; Cela va à l'encontre de tout ce que représente Linux, c'est-à-dire des fichiers de texte brut (qu'est-ce que c'est que des fichiers binaires?
      Allez, c'est de la merde. Je n'aime rien du tout.
      Mais grâce à des entreprises comme Canonical, Gnome et Red Hat; nous allons le manger avec des pommes de terre.
      Que si, alors qu'il existe d'autres options; Je ne l'utiliserai pas, ni sur les serveurs que j'administre, ni sur mes machines personnelles.
      Cela devient déjà une succursale de la société Redmond.

      1.    sephiroth dit

        Je ne veux défendre personne, mais je me souviens bien que canonique était totalement contre systemd en faveur de parvenu. quand debian a cédé à systemd, il a fini par glisser vers ubuntu.

  6.   Daryo dit

    De plus, ces bogues peuvent compromettre la sécurité du système et la stabilité d'un serveur, par exemple, c'est pourquoi ceux qui se plaignent le plus de ces choses sont l'administrateur système.

  7.   Alexandre dit

    Et que dire de Mageia, c'est incroyable qu'un KDE puisse fonctionner sur 512 Mo de RAM, impeccable.
    http://mirror.cedia.org.ec/mageia/iso/cauldron/

  8.   Sergio E. Duran dit

    quelques questions; Est-il facile de gérer les services dans OpenRC? et à quel point est-il facile de l'installer en l'utilisant par défaut dans une installation Manjaro avec systemd? ce que j'aime chez systemd, c'est qu'avec la simple commande systemctl enable (service) .service ou un systemctl disable (service) .service je peux gérer mes services facilement, SI je suis intéressé à connaître OpenRC et surtout si ça sent un peu étrange tout cela de systemd, d'ailleurs; Je suis un utilisateur novell

    1.    Sergio E. Duran dit

      Au fait; Il dit que je suis sous Windows parce que j'utilise le remplacement de l'agent utilisateur

    2.    anonyme dit

      OpenRC est très simple à manipuler, je vous donne un exemple avec le service d'impression cupsd.

      Pour le démarrer.
      # démarrage de cupsd de service rc
      * Démarrage de cupsd .. [ok]

      Pour l'arrêter.
      # rc-service cupsd arrêt
      * Arrêt de cupsd… [ok]

      Pour le redémarrer.
      # rc-service cupsd redémarrage
      * Arrêt de cupsd… [ok]
      * Démarrage de cupsd .. [ok]

      Pour le mettre pour démarrer dans le niveau d'exécution par défaut.
      # rc-update ajouter les valeurs par défaut de cupsd
      * service cupsd ajouté au niveau d'exécution par défaut [ok]

      Pour le supprimer du niveau d'exécution par défaut.
      # rc-update par défaut de cupsd
      * service cupsd supprimé du niveau d'exécution par défaut [ok]

      Pour voir l'état de tous les services à tous les niveaux d'exécution.
      # rc-statut -a

      Pour voir l'état d'un niveau d'exécution, dans cet exemple, default.
      # rc-status par défaut

      Ici à gentoo, OpenRC est le système de démarrage par défaut et le restera pour toujours, nous avons systemd en portage pour les kamikazes, qui heureusement il y en a peu….
      Pour remplacer journald, nous utilisons syslog-ng et logrotate, ici dans gentoo le journal système sort via la console virtuelle vt12 qui est control + alt + F12, ou vous pouvez le voir en continu dans n'importe quel terminal graphique en tant qu'utilisateur root avec:

      # tailf / var / log / messages

      1.    Sergio E. Duran dit

        Et l'installer sur mon Manjaro?

      2.    Sergio E. Duran dit

        Je dis; Je ne vais pas perdre tous les fichiers et ma belle XFCE juste pour passer à OpenRC 🙂

      3.    Sergio E. Duran dit

        Prêt; Je l'ai installé en utilisant sudo pacman -S manjaro-openrc bluez-openrc (ce dernier parce que j'ai bluetooth)

      4.    Sergio E. Duran dit

        Maintenant, mon problème est que le gestionnaire d'alimentation XFCE4 ne fonctionne pas avec upower-pm-utils 🙁 et je n'ai pas les options typiques de suspension et d'hibernation

    3.    Yukiteru dit

      OpenRC est très simple, la gestion des services est un jeu d'enfant, juste pour donner un exemple:

      Activer un service: rc-update add cronie default

      Démarrez un service: /etc/init.d/cronie start ou rc-config start cronie

      Arrêter un service: /etc/init.d/cronie stop ou rc-config stop cronie

      Simple et pas vraiment complexe.

  9.   Yukiteru dit

    @elav ce qui nous attend est à long terme, allant des tempêtes de sable, de la pluie de trolls, des fourches en vrac, des divisions de groupes de développement, et beaucoup se demandent si migrer vers BSD est une meilleure option que de rester coincé dans systemd, parce que oui.

    Personnellement, j'applaudis cette initiative de Manjaro, c'est une option pour ceux qui ne veulent pas rester avec systemd, quelque chose que j'aime, en ce moment je suis dans Gentoo et j'aime ça, je me sens à l'aise avec la liberté que ça me donne , mais maintenant Cela m'est venu plusieurs fois à l'esprit de faire le changement vers FreeBSD, et je peux faire le saut ce mois-ci, tout dépend de mon temps et de la commande de certaines choses pour mener à bien la migration.

    1.    Yukiteru dit

      Rien de tout cela ne réfute la réalité de systemd, Lennart est très doué pour éviter les choses et les responsabilités, je recommande qu'au lieu de simplement lire des articles, de lire le code systemd ou au moins de lire la liste de développement de systemd, vous découvrirez des choses qui réfutent ce que ces trois articles disent que c'est arrivé, et soutiennent davantage les détracteurs de systemd.

      1.    chouchouter dit

        Son argument est d'établir qu'il y a des connaissances qui réfutent ce que j'ai montré, mais ne présentent jamais les preuves, donc je ne peux pas me fier à son existence.
        https://lists.debian.org/debian-ctte/2013/12/msg00234.html

      2.    Yukiteru dit

        @pamp mon argument est un peu plus supportable car je l'ai expliqué ci-dessus dans le commentaire 25 de cette même entrée, et je l'ai exposé dans de nombreuses autres entrées concernant systemd, en plus de l'exposer dans l'irc Debian et la liste de cette distribution, aussi mon invitation, c'est que vous créez vos propres opinions et pour cela il vous suffit de lire un peu la liste de développement de systemd. Aussi juste pour piquer votre curiosité, je vous donne ce lien dans lequel ils disent clairement que systemd-214 n'offre plus de support pour les scripts SysV et LSB, avec l'excuse du «nettoyage de code».

        http://lists.freedesktop.org/archives/systemd-devel/2014-June/019925.html

        Maintenant, dites-moi: où est le support du standard LSB qui est censé avoir été créé afin de créer une base commune pour toutes les distributions? Parce que laissez-moi vous dire quelque chose, rien d'autre sur son premier lien Lennart plump, se vante et remplit sa bouche en disant que systemd prend en charge l'utilisation des scripts SysV et LSB, quand la vérité est que le support est abandonné et remplacé par un générateur de fichiers init , en passant, a plusieurs bogues et à la fin il n'y a pas d'autre option que de créer un fichier init complet.

        Salutations.

    2.    Tito dit

      Les avis, c'est comme le cul, on en a tous un.
      Ce que cet homme dit peut très bien lui convenir, mais ce n'est pas mon cas. Et l'opinion d'un homme qui écrit sur un portail Web n'est pas que c'est la parole de Dieu. C'est votre opinion, point final.
      Donc "réfuté", rien.
      La bonne chose qui nous reste est que nous pouvons utiliser ce que nous voulons vraiment; sans chercher à être "taliban" et imposer nos critères aux autres.
      Pour moi, SystemD est une vraie merde. Et il y a des gens qui aiment ça. Bienvenue!
      Ni mon opinion n'est bonne ni celle de ceux qui ne pensent pas comme moi, c'est de la merde; ils sont simplement différents.
      C'est ce qui nous distingue des autres systèmes d'exploitation; nous pouvons choisir.
      Ne nous lançons pas dans des combats inutiles qui ne mènent nulle part.

      1.    anonyme dit

        @Tite
        Vous n'auriez pas pu mieux le dire ... amen.
        Il faut être aveugle pour ne pas se rendre compte de la perversité que systemd conduit à tout couvrir, marcher sur, couvrir et déplacer des projets qui fonctionnent parfaitement, en les remplaçant par des versions qui n'atteignent ou ne deviennent jamais stables, même s'il n'y a pas de compatibilité entre les cœurs et plus de deux les versions antérieures de systemd.
        Debian semble avoir eu le tremblement de terre et ils ont réussi à se réveiller, j'espère juste qu'ils se penchent vers eudev et openrc, donc le développement de gentoo debian manjaro et de quelques autres qui utilisent openrc serait unifié, ce qui l'améliorerait beaucoup en peu de temps, gagner toute la communauté.

      2.    dah65 dit

        J'appuie vos propos.

        Il y a des gens qui citent d'autres personnes (les opinions qui les intéressent, en général), et les utilisent comme preuves.

        Pour ma part, je n'ai pas d'avis sur systemd. Je ne sais pas si c'est techniquement meilleur que upstart ou openrc, mais ce qui semble clair, c'est que la possibilité de sysvinit est exclue par TOUTES les distributions, Debian étant la seule à le conserver encore dans Wheezy en raison de sa politique. Mais la prochaine Debian stable, Jessie, allait être une Debian sans sysvinit.

        Ce qui est clair, c'est que sur le plan éthique, il s'agit de logiciels 100% libres; Quant à sa partie technique, je n'ai ni étudié le code ni comparé avec ses alternatives, donc je n'ai pas d'avis motivé. Mais même Ubuntu actuel utilise des parties de systemd même si elles ont encore du upstart, et je doute qu'elles l'aient fait parce que Canonical est «acheté» par Red Hat.

        Systemd n'est pas "diabolique", s'il vous plaît, nous ne combattons pas Skynet (Terminator), ou HAL9000 ("2001 Space Odyssey"), ni le côté obscur de la Force qui cherche à dominer les Jedi. Ce n'est pas non plus qu'en s'installant dans une équipe, il prend tout en charge et fait disparaître même les produits alimentaires du garde-manger.

        Et que "ça déplace des projets qui fonctionnent parfaitement" (commentaire 52), j'ai eu des problèmes avec un réseau NFS domestique dans les ordinateurs qui accèdent au serveur car le processus d'arrêt de l'ordinateur client déconnecte le réseau avant de démonter le système NFS, et l'arrêt se figerait, la seule solution étant d'appuyer sur le bouton marche / arrêt pour l'éteindre de force (bug rapporté par différents utilisateurs); J'ai dû créer un script qui démonte les fichiers NFS à exécuter avant d'arrêter la machine cliente. D'autre part, l'ordinateur serveur NFS se connecte via wifi, et de temps en temps la connexion est perdue: je ne sais pas si le problème est le gestionnaire de réseau ou il est dans dhcpd, ou où.

        Je ne dis pas que ces problèmes disparaissent avec systemd; Je l'ignore, car je ne l'ai pas utilisé. C'est juste un exemple que dire que les projets que systemd remplace fonctionnent parfaitement est une exagération.

      3.    Yukiteru dit

        Une chose est une opinion et une autre est un argument, certes le premier est très varié comme vous dites @Tito, mais le second est quelque chose de plus concis et ciblé, ce n'est pas quelque chose qui peut être si facilement manipulé, du moins, pas dans le cas du logiciel libre, où nous avons le code à portée de main pour le réviser.

        @pamp nous dit que les arguments présentés ont été réfutés depuis longtemps, et comme premier test, il nous met au courant des opinions de Lennart (pas des arguments). Mais ce que ce gars dit dans ses commentaires est une chose (les nombres 4 et 8 sont juste à mourir de rire), et ce qu'il fait en code systemd en est une autre. Une attitude que j'ai vue à plusieurs reprises chez Lennart depuis que j'ai commencé à développer des choses comme Avahi et Pulseaudio, et qui peut simplement être corroborée en lisant les listes de développement et les rapports de bogues des deux logiciels.

      4.    Yukiteru dit

        @ Dah65 certainement, beaucoup de gens utilisent des preuves en utilisant les opinions de tiers, une mauvaise habitude pour ceux qui ne peuvent pas enquêter eux-mêmes sur les problèmes d'avoir leur propre opinion et même de créer des arguments valables avec lesquels participer à une discussion constructive .

        Dans mon cas, je me tiens au courant des changements de systemd grâce à la liste de développement, même si je n'aime pas l'outil, je ne l'aime pas du tout, mais je n'arrête pas de lire à ce sujet au niveau utilisateur et technique, et la raison Pour cela, c'est très simple, si je dois m'occuper d'un client qui utilise ledit init, je sais ce que je dois faire et comment m'occuper de n'importe quelle situation.

        Maintenant, à propos de ce que les services exécutent sans problème, c'est une erreur, il existe de nombreux scripts SysV avec des problèmes, et la même chose se produit dans systemd, mais au moins lorsque vous signalez une erreur dans un SysV, ils sont corrigés ou vous pouvez le faire dans un façon simple comme vous l'avez commenté, dans systemd, après avoir fait un rapport de bogue, vous pouvez trouver un WONTFIX ou CLOSED, grâce à Lennart ou Kay, selon le cas et je n'exagère pas en disant cela, un exemple ici:

        https://bugzilla.redhat.com/show_bug.cgi?id=753882

        Lisez le commentaire 48, vous n'avez aucune perte. Clement's 53 en est un autre qui n'a aucune perte, surtout pour sa solution archaïque mais fonctionnelle au problème que Lennart ne veut pas résoudre et qui a d'ailleurs été rapporté en 2011.

    3.    mario dit

      Ces «mythes» qui les ont établis? Certains sont supprimés de la galerie car "systemd n'est pas portable sans raison". Il est tout à fait vrai qu'il n'est pas portable (et il l'admet en disant qu'il est très personnalisé pour Linux)
      Cela suppose des erreurs, comme l'hypothèse que BSD n'est pas intéressé (les gars de BSD disent le contraire: "Jordan Hubbard - FreeBSD: Les 10 prochaines années (MeetBSD 2014)"), même s'il était portable, ils ne l'adopteraient pas et des choses comme ça (mythe 13,14,15).

      Si l'intention de Poettering est que nous réécrivions des scripts, exclusifs à votre système (http://0pointer.de/blog/projects/systemd-for-admins-3.html) nous allons nous tromper. En principe, un script init classique ne se soucie pas de votre destination. Des modifications minimes sont apportées pour fonctionner sous GNU, UNIX ou BSD. Eh bien, c'était jusqu'à maintenant (sauf si OpenRC est utilisé). Quoi qu'il en soit, je pense que des choses comme celles-ci produiront un schisme entre Linux pour le bureau et les serveurs. Ubuntu et les utilisateurs dérivés ne verront les changements qu'à la fin de l'année prochaine.

      1.    anonyme dit

        @ Dah65

        Eh bien, puisque vous dites que systemd n'est pas la perversité personnifiée, alors dites-moi pourquoi ils ne mettent pas dans les options Makefile pour désactiver tous ses modules au moment de la compilation, afin que ceux d'entre nous qui n'aiment pas avoir ces "modules optionnels" qui marchent dessus d'autres paquets, afin que nous puissions les compiler et créer nos propres versions de systemd plafonnées!
        Savez-vous pourquoi ils ne le font pas? Parce que sa forme de développement s'appelle l'imposition forcée et que 95% des utilisateurs n'ont pas de NPI, ils profitent de la valeur par défaut, nous l'avons déclinée pour vous tous.
        C'est comme ça que les logiciels libres ou open source ou ce qu'ils veulent appeler ne fonctionnent pas, maintenant ça me fait rire, car avec le nouveau fork de Debian, beaucoup de gens pensent que c'est un gaspillage de force et je me demande toujours à quel point c'est difficile c'était pour mettre des options de compilation supplémentaires au Makefile?
        Le sujet ne donne pas plus, c'est comme vouloir mélanger de l'eau avec de l'huile, c'est pourquoi il y aura des fourches sans fin dans chaque développement où il y aura une imposition de quelques-uns pour tout le reste.

      2.    Yukiteru dit

        @mario est exactement ce que vous dites. Jordan Hubbard a également compris que le BSD init doit être mis à jour non seulement pour s'adapter aux nouvelles technologies, mais également pour prendre en charge les nouvelles fonctionnalités qui sont désormais possibles, mais il contourne le concept que systemd a maintenant de la façon dont elles devraient être faites. choses, et ils le simplifient à la philosophie qui a toujours prévalu sous UNIX, "Faire un programme qui fait une chose et le fait bien", et que dans un init est extrêmement important, puisque nous ne parlons pas d'un démon de plus, nous parlent de l'initialisation d'un système d'exploitation, en plus d'être une mesure de sécurité, par rapport à ce que de nombreux spécialistes commencent déjà à se plaindre de systemd, et c'est démontrable, systemd ressemble beaucoup à svchosts.exe de Windows, faisant du init des services au contrôle du réseau entre autres choses.

  10.   Luis dit

    Les gars, c'est vraiment effrayant.

    Est-ce très compliqué de supprimer d'ArchLinux ????

    Je vais chercher des informations mais je n'ose pas toucher à ce genre de chose de peur de foirer et de perdre mon système.

  11.   manu dit

    D'après les nombreux commentaires que j'ai lus, SYSTEMD est un vrai CHEVAL TROYEN….
    Il y a peu d'informations en espagnol sur la configuration du bureau dans FreeBSD et sur la préparation du système à l'utilisation.

  12.   Raphaël Mardechai dit

    Pauvre système, laissez-le être. xD

  13.   waco dit

    Ce système de haine ne sera pas viral ???? Arch a bien fonctionné pour moi ... s'il est vrai qu'il couvre plus, je ne sais pas si c'est bon ou mauvais! mais peut-être qu'il y a déjà des vulnérabilités pour prendre le contrôle ou un virus qui détruit le système à cause de cela ... s'il est stable et sûr je ne vois pas le problème ... de toute façon je verrai si j'ai le temps et étudier le sujet et faire quelques tests avec openrc

    1.    Daryo dit

      pas si stable. et il est beaucoup plus dangereux que le système v. Pour un utilisateur de bureau comme beaucoup d'entre nous (moi), cela ne représente pas non plus un problème, un démarrage plus rapide fonctionne bien et je ne lis généralement pas les journaux, peu importe leur clarté ou leur format binaire.

      J'ai une théorie que Linux va se développer sur les ordinateurs de bureau (et les gouvernements) et perdre du terrain sur les serveurs (au lieu de prendre un système d'exploitation comme freebsd)

  14.   oscar dit

    Sur le wiki esdebian, ils publient comment installer SysVinit sur Debian Jessie. http://www.esdebian.org/wiki/sysvinit

  15.   anonyme dit

    En lisant sur la sécurité, je découvre que du côté d'Intel, il y a des cartes mères avec des chipsets, généralement dans le northbridge, ils implémentent quelque chose appelé AMR Intel Active Management Technology .... intéressant, heureusement je n'ai pas d'informations, mais je vais commencer à le chercher Côté AMD il n'y a rien de tel.
    Ils imaginent une combinaison d'Intel + AMR + systemd, Dieu nous en préserve.
    https://en.wikipedia.org/wiki/Intel_AMT_versions
    Pas étonnant que la paranoïde de Stallman réclame des biographies gratuites.

  16.   dah65 dit

    Tout d'abord, je n'utilise pas systemd car il n'est pas encore intégré à Kubuntu (je suis avec Netrunner 14, dérivé de Kubuntu 14.04).

    Après avoir clarifié cela, plusieurs choses doivent être précisées:

    1- systemd est en train d'être adopté par les développeurs / packagers de nombreuses distributions différentes (Debian, openSUSE, Arch, Fedora…), mais maintenant il s'avère que les lecteurs de ce blog en savent plus qu'eux sur les avantages et les inconvénients de systemd.

    2- systemd est un logiciel libre, dont le code peut être lu (et compris), par ceux qui ont le temps et les connaissances (ces développeurs / packagers dont je parlais auparavant). Si vous cachez les portes dérobées, elles seraient découvertes. Combien de lecteurs utilisent un micrologiciel ou un pilote propriétaire dont vous n'avez pas lu et que vous ne pouvez pas lire? Je pense qu'il est plus logique d'avoir peur de cela que de ne pas avoir peur de systemd.

    3- Nous travaillons tous avec des paquets binaires, car lorsque je télécharge un .deb depuis les référentiels pour l'installer, je ne télécharge pas de fichier texte brut. Cet argument est donc assez paradoxal.

    4- Dans GNU / Linux il y a déjà des programmes qui font beaucoup de choses: le même noyau, qui intègre de plus en plus de pilotes, et même des microprogrammes propriétaires (mieux vaut mettre une porte dérobée dans le firmware fermé que dans un programme dont le code est publié). Il y a aussi Xorg, qui gère non seulement le serveur graphique mais aussi le clavier, la souris et d'autres choses; Personne ne dit que Xorg «trahit» la philosophie UNIX pour cela, ils veulent le retirer parce qu'il a déjà été dépassé par d'autres projets.

    5- "Linux c'est le choix", bien sûr, mais c'est la liberté de choisir si je veux lire le code, le modifier, le distribuer, etc. Non pas que les distributions soient obligées de donner tous les choix (toutes les architectures de processeur, tous les environnements de bureau, tous les formats de paquet, etc.)

    6- Pour ceux qui envisagent de passer à un BSD, je me souviens avoir lu des informations selon lesquelles dans certains systèmes BSD la NSA américaine avait déjà mis ses griffes. Si cette nouvelle était correcte, je ne sais pas car je n'ai pas suivi le sujet. Mais il est ironique que je fuie quelque chose "parce que Red Hat est derrière et peut-être ..." pour entrer dans quelque chose que "peut-être la NSA est derrière ..."

    En plus d'utiliser GNU / Linux, BSD, Windows ou tout ce que vous voulez que nous utilisions, nous pouvons également utiliser notre logique et notre capacité à raisonner

    1.    animé dit

      Tout d'abord, je n'utilise pas systemd car il n'est pas encore intégré à Kubuntu (je suis avec Netrunner 14, dérivé de Kubuntu 14.04).

      Après avoir clarifié cela, plusieurs choses doivent être précisées:

      1- systemd est en train d'être adopté par les développeurs / packagers de nombreuses distributions différentes (Debian, openSUSE, Arch, Fedora…), mais maintenant il s'avère que les lecteurs de ce blog en savent plus qu'eux sur les avantages et les inconvénients de systemd.

      En d'autres termes, les lecteurs de ce blog, n'étant que des lecteurs, n'ont pas la capacité de se rendre compte si quelque chose est bon ou pas, car il faut être guidé par le bon jugement, les connaissances et l'expérience des packagers et des développeurs.

      2- systemd est un logiciel libre, dont le code peut être lu (et compris) par ceux qui ont le temps et les connaissances (ces développeurs / packagers dont je parlais auparavant). Si vous cachez les portes dérobées, elles seraient découvertes. Combien de lecteurs utilisent un micrologiciel ou un pilote propriétaire dont vous n'avez pas lu et que vous ne pouvez pas lire? Je pense qu'il est plus logique d'avoir peur de cela que de ne pas avoir peur de systemd.

      C'est vrai, c'est du Logiciel Libre, et si quelque chose d'étrange apparaît, les super personnes dont vous avez parlé auparavant et en qui nous devons avoir confiance pourront le remarquer et l'annoncer, ou peut-être pas, car peut-être que ce sont des gens, ils seront tentés se taire en retour de quelque chose.

      3- Nous travaillons tous avec des paquets binaires, car lorsque je télécharge un .deb depuis les référentiels pour l'installer, je ne télécharge pas de fichier texte brut. Cet argument est donc assez paradoxal.

      Lorsque vous téléchargez un .deb, tout ce que vous faites est de télécharger un fichier compressé, que vous pouvez décompresser et par conséquent, voir ce qui est à l'intérieur et est possible, où se trouve le binaire. 😉

      6- Pour ceux qui envisagent de passer à un BSD, je me souviens avoir lu des informations selon lesquelles dans certains systèmes BSD la NSA américaine avait déjà mis ses griffes. Si cette nouvelle était correcte, je ne sais pas car je n'ai pas suivi le sujet. Mais il est ironique que je fuie quelque chose "parce que Red Hat est derrière et peut-être ..." pour entrer dans quelque chose que "peut-être la NSA est derrière ..."

      Je ne sais pas qui sont les utilisateurs qui vont fuir Linux pour aller à BSD, mais par exemple, je n'aurais pas à quitter Linux, je n'aurais qu'à laisser une distribution qui met Systemd derrière vous oui ou oui.

      En plus d'utiliser GNU / Linux, BSD, Windows ou tout ce que vous voulez que nous utilisions, nous pouvons également utiliser notre logique et notre capacité à raisonner

      En bref, ceux d'entre nous qui commentent, lisent et utilisent GNU / Linux dans ce blog ne raisonnent pas. C'est ce que tu veux dire? Quoi qu'il en soit, je vais vous dire d'après mon expérience personnelle et mon raisonnement (que ce soit logique ou non):

      Systemd est coincé sur un bâton. J'ai lu qu'il existe d'autres Inits qui démarrent beaucoup plus rapidement et n'ont donc pas à contrôler DNS, RED, CRON et tout ce que Systemd veut contrôler. Peut-être que pour un utilisateur final, qui ne se soucie que d'allumer l'ordinateur, d'ouvrir un navigateur et d'envoyer des e-mails, peu importe s'il utilise Systemd ou Systemx, mais pour ceux d'entre nous qui gèrent des serveurs, c'est une douleur dans le cul. Et je vous pose la même question que je demande toujours ce qui se passe si Systemd est compromis et va en enfer? Sommes-nous laissés sans RED, sans CRON, sans DNS, sans Init et tout le reste? Là, je vous laisse ça.

      Et attention, je vous dis tout cela sans acrimonie. Cela dit, bienvenue dans ces parties.

      1.    dah65 dit

        Merci pour la bienvenue.

        Répondant sans acrimonie, je précise que je ne développe pas de système et que je ne suis pas payé pour le promouvoir. Et que cela ne m'affecte pas du tout que les autres l'utilisent ou non, c'est leur décision.

        Mais ce que je vois dans cette affaire me semble parfois une hystérie, et je lis les opinions de gens qui, sans avoir étudié le code ni l'avoir utilisé, le qualifient d'ordure, d'imposition, de trahison, et je ne sais pas combien autres choses. Cela me rappelle une situation que j'ai vécue il y a quelques jours, lorsqu'une personne qui reconnaissait n'avoir jamais installé Windows ou savait partitionner un disque dur a commencé à dire que Linux était très difficile ... sans même l'avoir essayé, et ayant également Android sur son smartphone.

        Avez-vous comparé systemd avec sysvinit, avec upstart et avec openrc? Super, vous pouvez prendre une décision en fonction de votre propre expérience. C'est la meilleure, car vous savez aussi que la distribution qui fonctionne sur un ordinateur peut être sans valeur sur un autre, et c'est pourquoi ceux d'entre nous qui ont une certaine expérience de GNU / Linux disent que la meilleure distribution est celle avec laquelle l'utilisateur se sent à l'aise.

        1- «En d'autres termes, les lecteurs de ce blog, parce qu'ils ne sont que des lecteurs, n'ont pas la capacité de se rendre compte si quelque chose est bon ou pas, car il faut être guidé par le bon jugement, les connaissances et l'expérience des packagers et développeurs »

        Je suis un lecteur de ce blog depuis un certain temps (vous verrez mes commentaires dans les anciennes news), donc je suis inclus dans le pack. Et la réponse est que non: être lecteur de tel ou tel blog ne me permet pas (du moins à moi), de juger du bien ou du mal d'un logiciel que je ne connais pas. Je peux lire ce que les autres disent, et dans ce cas, il y a des positions à la fois pour et contre systemd; en fait, chaque fois que le sujet est évoqué dans Phoronix, il y a beaucoup de débats, mais même là, les commentaires argumentés sont rares. Je fais référence à des arguments comme "lorsque systemd appelle le processus X, une boucle infinie se produit, rendant le système inutilisable".

        Et la vérité est qu'en utilisant une distribution ou une autre, vous êtes guidé par le jugement, les connaissances et l'expérience des packagers et des développeurs. L'utilisation de tout système d'exploitation ou programme implique en partie de s'appuyer sur le jugement et l'expérience d'autrui; par exemple, avec Linux, vous acceptez la décision d'utiliser un noyau monolithique au lieu d'utiliser un micro-noyau comme Hurd. Cette décision appartenait à Linus Torvalds, et vous l'acceptez en utilisant son cœur.

        2- «C'est vrai, c'est du Logiciel Libre, et si quelque chose d'étrange apparaît, les super personnes dont vous avez parlé avant et en qui nous devons faire confiance pourront le remarquer et l'annoncer, ou peut-être pas, car peut-être que ce sont des personnes elles sera tenté de se taire en échange de quelque chose. "

        Eh bien, méfiant, pourquoi faire confiance à Linus Torvalds et Richard Stallman et au projet GNU? Je n'ai pas regardé le code de vos programmes, alors peut-être qu'ils me trompent.

        3 - «Et je vous pose la même question que je vous pose toujours, que se passera-t-il si Systemd est compromis et va en enfer? Sommes-nous laissés sans RED, sans CRON, sans DNS, sans Init et tout le reste? Je vais le laisser là. »

        Et si OpenRC est compromis d'une manière ou d'une autre? Ou Upstart? Ou le noyau? Cela m'est arrivé, après une mise à jour «normale» dans Debian Testing, je n'avais plus de grub, je ne pouvais pas entrer dans Debian ou Windows, et à ce moment-là, mon ignorance signifiait que je n'avais que l'option de réinstaller.

        4- «Bref, ceux d'entre nous qui commentent, lisent et utilisent GNU / Linux sur ce blog ne raisonnent pas. C'est ce que tu veux dire? "

        Non, je ne veux pas dire cela; Je n'ai pas l'intention de généraliser d'une situation particulière et concrète à la totalité du comportement d'une ou de mille personnes. Mais je crois que dans le cas de systemd, il est parlé plusieurs fois sans faire une analyse objective et sereine; cela s'est aussi produit avec Wayland-Mir, de nombreuses allégations non fondées étant faites, à la fois contre Wayland et Canonical.

        Aussi, je répète que j'ai lu et commenté ce blog (comme dans d'autres), et que j'utilise GNU / Linux.

        Et je répète aussi ce que j'ai dit précédemment: utilisons le cerveau, analysons ce que nous entendons et lisons, prenons différentes perspectives pour essayer de réfuter à la fois A et non-A, et si possible, faisons notre propre expérience pour fonder nos conclusions sur des faits . Et puis utilisons ce qui nous semble bon.

      2.    waco dit

        euh .. eh bien qu'être compromis est une hypothèse c'est comme tout .. ma question est déjà passée? .. peut-être que les bogues ne sont pas trouvés dans tous les logiciels et ils sont corrigés s'il y a des bogues dans systemd ils le corrigent et comme n'importe quel programme peut avoir ses bugs .. le problème n'est pas qu'il peut échouer, c'est si vous voulez qu'il fasse ou contrôle ce qu'il fait mais pas en supposant qu'il peut échouer tout peut échouer en un instant ... je ne suis pas un fan de systemd du tout, c'est juste mon avis.

        1.    animé dit

          Un bogue peut survenir sur l'ordinateur d'un utilisateur et rien ne peut arriver, mais sur un serveur, les choses sont très, très différentes.

      3.    Yukiteru dit

        @waco certainement si vous rencontrez des bogues dans un logiciel, vous devriez les corriger. Le problème est que systemd a beaucoup d'anciens bogues (certains datant de 2010 et sérieux) et ils ne sont toujours pas corrigés aujourd'hui, ou simplement minimisés, ou simplement marqués par Lennart comme CLOSED ou WONTFIX.

    2.    waco dit

      ton commentaire est très réussi! Nous ne pouvons pas tous tomber dans systemd parce qu'il est à la mode et a été créé comme une campagne de diffamation à ce sujet ... chaque changement a un rejet.

    3.    Yukiteru dit

      Je réponds à vos arguments:

      1.- Les utilisateurs sérieux et curieux, ainsi que les développeurs connaissent les avantages et les inconvénients de l'adoption de systemd dans n'importe quel environnement de développement et de travail, les faiblesses et les forces de systemd ne changent pas en raison de l'un ou l'autre point de vue.

      2.- Il est certain que systemd est un logiciel libre et peut être audité. Le problème n'est pas qu'il a caché des portes dérobées, le problème est qu'il fait des choses qu'un init ne devrait pas faire (contrôle du réseau, dns, consoles TTY, etc.), qu'il a beaucoup de services qui sont supposés pour les autres, que il fait les choses d'une manière complètement différente de la façon dont on s'attend à ce qu'elles soient faites, ce qui enfreint les règles du noyau Linux lui-même (coredump), que beaucoup de ses développeurs se soucient très peu de résoudre les problèmes structurels de systemd (coredump et debug sont parmi les plus graves mais non résolus).

      3.- Une chose est de télécharger un binaire qui s'avère être un programme dont la CONFIGURATION et les LOGS sont toujours en texte brut, et une autre chose est de télécharger un binaire dont la CONFIGURATION et d'autres informations sont stockées en binaire et n'est accessible que par outils, c'est là que les choses changent. Un journal binaire n'offre pas de sécurité (si vous voulez vraiment de la sécurité, cryptez la partition avec AES-256), c'est juste une boîte noire dont vous ne savez rien de ce qui se passe et il se prête à beaucoup de choses, par exemple : Imaginez que vous ayez un cheval de Troie qui exploite une vulnérabilité systemd et par ce biais obtient un accès complet au système, y compris le service de journalisation et l'élévation des privilèges. N'est-ce pas un problème grave? Les journaux binaires gérés directement par systemd ne se retourneraient-ils pas contre vous en étant inauditables sans arriver au point qu'ils ont déjà été modifiés sans le savoir? Il y a le point et la différence entre un programme et un fichier de configuration / logs / dumps en binaire.

      4.- Le noyau est un logiciel conçu dans ce sens, il est conçu dès le départ pour tout contrôler sur votre PC, pas un init. Un init est dédié uniquement à faire en sorte que votre système soulève le noyau et soit utilisable, car c'est la première chose à commencer et la dernière à terminer. C'est pourquoi on l'appelle init (initialisation) car il ne fait que démarrer le système et ne fait rien d'autre, et la raison en est très simple, l'initialisation doit être le logiciel le plus stable et parfait possible, pour éviter cela pour une raison quelconque Cela finit par casser tout le système, c'est une question de stabilité et de sécurité. Xorg, c'est une autre voix, il fait beaucoup de choses c'est vrai, mais rien de plus risqué que de vous laisser avec un système complètement inutilisable, et aussi sa configuration se fait toujours dans de simples fichiers de texte brut.

      5.- Certes, les distributions ne sont pas obligées d'offrir la liberté au sens large, et c'est à cause de cela que la diatribe actuelle est présentée. Mais, nous sommes des utilisateurs et une communauté, et beaucoup d'entre nous ne sont tout simplement pas d'accord avec la mise en œuvre de ce système, c'est pourquoi nous faisons entendre notre voix, qu'ils l'écoutent ou non, c'est une question de ceux qui développent la distribution. , et leur décision aura un impact sur ceux qui décident d'utiliser leur distribution ou non, et cela peut clairement conduire à l'échec de plusieurs distributions en fonction de la façon dont les choses se passent et un exemple est maintenant Debian et sa fourche Devuan.

      6.- Les nouvelles de BSD sont dues à ce qui s'est passé dans OpenSSH et dans la pile IP OpenBSD, une porte dérobée qui affectait d'ailleurs non seulement BSD mais aussi Linux (dans le cas d'OpenSSH), et cela a été corrigé. La situation est attribuée à BSD, car c'est BSD (Theo de Raadt in OpenBSD) qui est en charge du développement de cet outil (OpenSSH) et la situation s'est présentée car certains développeurs qui ne sont plus actifs dans le projet ont planté la porte dérobée . La situation a été résolue et les mesures pertinentes à prendre ont été déclarées au cas où cette situation pourrait affecter ceux qui utilisaient le logiciel. Maintenant: cette situation peut-elle se produire dans systemd? La réponse est simple et le résultat est catastrophique, puisque systemd gère l'escalade des privilèges entre autres choses, une porte dérobée dans systemd signifie un accès total au système, ce qui ne s'est pas produit avec les portes dérobées mentionnées dans BSD.

  17.   oscar dit

    Ils renvoient le fork de Debian sans que systemd ait déjà une page Web. Il semble que le projet avance et très au sérieux. https://devuan.org/

  18.   aaditya bagga dit

    Mise à jour des ISO et de nouveaux téléchargements.
    https://forum.manjaro.org/index.php?board=50.0

  19.   Kéos dit

    L'installateur n'est pas très clair, je ne peux pas suivre leurs étapes, surtout dans la partie des partitions, je ne sais pas pourquoi ils insistent sur ces choses déroutantes.

  20.   Manuel R . dit

    Il y a quelque chose qui attire mon attention à propos de netinstall avec Openrc, quelque part dans l'installation, je continue de voir le message que vous configurez systemd, seront-ils vraiment libres de systemd ou de son utilisation?

    1.    Kéos dit

      Bonjour Manuel, j'observe aussi la même chose lors de l'installation, cela doit être une question de l'installateur car ce qu'il ne fait aucun doute c'est que systemd n'est pas installé, vous confirmez dans le terminal comme ceci: pacman -Qs openrc

      salutations

      1.    Manuel R . dit

        Bonjour keos, tout d'abord je m'excuse de ne pas avoir répondu auparavant. J'apprécie votre réponse, je suis heureux de savoir que Manjaro propose cette option; dès que le support Ubuntu Precise prendra fin (ou peut-être plus tôt) je l'installerai. Cordialement.

  21.   Anonyme dit

    Bon message

    Je vais attendre à Manjaro avec Systemd pendant que la version OpenRC mûrit un peu plus, je veux sortir de systemd… (je transpire)