|
|
Ce n'est pas vraiment EC, mais je vous invite à débattre : est-ce que ça
vaut le coup de me mettre à red hat, vu que c'est une distribution qui est utilisée/demandée par de nombreuse boîtes. Quelle machine pour la red hat ? un r-pi ? (j'ai abandonné mandrake/mandriva pour DebIan, je pourrai revenir du côté obscur de la force avec red hat, mais je préfère y consacrer une machine. Est-ce une bonne idée ?) |
|
|
|
Jo Engo , dans le message
<pan$dbd78$c7ffc3a2$544a64d7$e71372f3>, a écrit : > Ce n'est pas vraiment EC, mais je vous invite à débattre : est-ce que ça > vaut le coup de me mettre à red hat Non. |
|
|
Le 28-05-2020, Jo Engo <yl> a écrit :
> Ce n'est pas vraiment EC, Pourquoi ? Qu'est-ce qui n'est pas en charte ? T'as une distribution Red Hat à base de Windows 10 ? > mais je vous invite à débattre : est-ce que ça > vaut le coup de me mettre à red hat, vu que c'est une distribution qui > est utilisée/demandée par de nombreuse boîtes. Tu es admin système et tu ne connais pas Red Hat ? Si c'est le cas, ça peut valoir le coup d'avoir une Red-Hat (ou cent OS, c'est pareil mais encore moins bleeding edge, ce qui n'est pas rien, mais aussi utilisé). > Quelle machine pour la red hat ? Ce que tu as sous la main. > un r-pi ? Ils ont ça en entreprise ? Dans quelle entreprise ? Ou alors pour de l'embarqué ? > (j'ai abandonné mandrake/mandriva pour DebIan, je pourrai revenir du côté > obscur de la force avec red hat, mais je préfère y consacrer une machine. > Est-ce une bonne idée ?) C'est quoi ton but ? C'est quoi l'intérêt d'y consacrer une machine ? Pour découvrir, une vm est suffisante. En gros, il y a deux différences entre les systèmes d'exploitation : - le gestionnaire de package, - ce qui est installé par défaut. Perso, je n'ai jamais réussi à installer un système à base de Red-Hat (ça monte à très vieux puis j'ai plus réessayé). Pour moi, il y a forcément uh moment où tu dois mettre la main dans le cambouis, le plus tôt est le mieux. Ma première distribution, c'était une slackware, j'ai mangé grave pour faire reconnaitre le lecteur de CD et la carte graphique. Il fallait aussi recompiler mon noyau et tout ça (vers 94/95). À l'époque la doc était éparse (plein de HOWTO sur le CD de la distribution) et entièrement en anglais (à l'époque c'était un problème pour moi). Par contre, une fois que ça marchait, je n'ai jamais eu de problème : je savais où chercher et comment réparer. Pour Red Hat, à chaque fois que j'ai essayé, puisqu'on me disait que c'était plus simple, l'installation s'est toujours bien passée tout se faisait tout seul sans que j'ai de problème, puis une fois l'installation finie, ça marchait pas et je ne savais pas pourquoi donc je dégageais. Puis, est venu Ubuntu. C'était super, ça s'installait nickel et ça marchait tout seul. Sauf qu'il fallait que j'installe les applications qui me semblaient de base (LaTeX et vim par exemple). Sauf que ça lançait des trucs que je ne savais pas ce que c'était ni à quoi ça servait mais ça me bouffait mes ressources. Sauf que les montées de versions c'était pas glorieux. Sauf que quand ça merdait, je ne savait pas ce qui merdait, ni pourquoi, ni quoi faire. Sauf que les packages n'étaient pas toujours à leurs dernière version et pouvaient avoir beaucoup de retard. Le plus gros problème, c'est que comme Ubuntu faisait tout pour moi, je n'avais aucune information et je ne savais pas comment intervenir. Comme pour Red Hat. Pour réparer un truc simple, il fallait que je me documente pour comprendre ce qu'il se passait (Ah ! C'est pas lilo, c'est grub ! C'est quoi grub, ça marche comment ?). Maintenant, je suis passé à Arch Linux. J'ai eu du mal à l'installer. J'ai dû installer des trucs qui me semblaient de base : mais je le savais et ça ne m'a pas installé des trucs qui ne me sont pas utiles. Les « montées de versions » se sont toutes bien passées, je n'ai pas de problème. Il faudra voir si c'est facile à résoudre quand j'ai des problèmes. Mais aujourd'hui, toutes les erreurs que j'ai eu lors de mes montées de version étaient expliquées sur la page d'accueil d'Arch Linux. Je n'ai pas besoin d'installer manuellement des packages pour une version plus à jour. J'ai essayé LFS il y a quelques années. C'est très formateur, mais il faut vraiment du temps. Beaucoup de temps. Trop de temps pour l'installation, ensuite j'ai pas bien compris comment les mises à jour devaient se faire, mais j'imagine que c'est un travail à temps complet et je ne suis pas allé au bout. |
|
|
Le 28/05/2020 à 18:47, Stéphane CARPENTIER a écrit :
[..] > montées de version étaient expliquées sur la page d'accueil d'Arch > Linux. Je n'ai pas besoin d'installer manuellement des packages pour une > version plus à jour. > J'ai essayé LFS il y a quelques années. C'est très formateur, mais il > faut vraiment du temps. Beaucoup de temps. Trop de temps pour > l'installation, ensuite j'ai pas bien compris comment les mises à jour > devaient se faire, mais j'imagine que c'est un travail à temps complet > et je ne suis pas allé au bout. Même constat sur Fedora (petit fils de Red Hat) pour moi: j'essaie une fois par an et j'abandonne en général 2 jours après. Contrairement aux autres distributions Debian testing, Emmabuntus DE4 ou Mint DE, par exemple que je teste en VM. Dans la vraie vie, je suis sous Xubuntu 20.04 (le X collé à Ubuntu est important). Quasiment aucun problème que ce soit pour une utilisation basique (mon épouse) ou plus avancée sans être complexe (moi). Emmabuntus est très prometteur pour les utilisations basiques. La prochaine version de Fedora utilisera les paquets .deb (version 33 je crois) : peut-être que cela sera plus friendly-user. |
|
|
Le 28/05/2020 à 18:47, Stéphane CARPENTIER a écrit :
> Pour Red Hat, à chaque fois que j'ai essayé, puisqu'on me disait que > c'était plus simple, l'installation s'est toujours bien passée tout se > faisait tout seul sans que j'ai de problème, puis une fois > l'installation finie, ça marchait pas et je ne savais pas pourquoi donc > je dégageais. Pareil en gros pour moi sur Fedora 1, 2, 3. Après : Mepis. Debian. Ubuntu. Xubuntu pendant quelques années. Manjaro (sans problèmes pendant 3-4 années). Artix en ce moment (d'abord testé avec succès sur Virtualbox pendant 2 ans et depuis quelques mois installé pour de vrai sur 3 machines). |
|
|
Le 01-06-2020, jp willm <nicole.jeanpaul.willm> a écrit :
> Artix en ce moment Je ne connaissais pas. en basculant sur Archlinux j'ai découvert systemd. J'ai entendu plein de critiques mais jamais assez intéressantes pour chercher à basculer. Il y a des trucs avec lesquels je suis un peu perdu, mais par rapport à ce qu'il y avait avant c'est quand même plus simple pour d'autres choses. Mais surtout, le plus important pour moi, c'est que ça marche. |
|
|
Le 01/06/2020 à 18:02, Stéphane CARPENTIER a écrit :
> Le 01-06-2020, jp willm <nicole.jeanpaul.willm> a écrit : > Je ne connaissais pas. en basculant sur Archlinux j'ai découvert > systemd. J'ai entendu plein de critiques mais jamais assez intéressantes > pour chercher à basculer. Il y a des trucs avec lesquels je suis un peu > perdu, mais par rapport à ce qu'il y avait avant c'est quand même plus > simple pour d'autres choses. Mais surtout, le plus important pour moi, > c'est que ça marche. Justement, quand systemd "marche", il est très difficile de comprendre comment. J'ai opté pour openrc, et là je retrouve des fichiers de configuration comme on en est habitué sur sysV : <https://www.linuxtricks.fr/wiki/openrc-les-commandes-essentielles> Le démarrage et l'arrêt du système sont très rapides et je n'ai pas un /var/log/journal à nettoyer à tout bout de champ. J'ai installé une foule d'applications, je lance les mises à jour continuellement comme sur Arch et n'ai pas rencontré de problèmes à ce jour. Le système est très fluide et consomme peu de ressources. |
|
|
Le 01-06-2020, jp willm <nicole.jeanpaul.willm> a écrit :
> Le 01/06/2020 à 18:02, Stéphane CARPENTIER a écrit : > Justement, quand systemd "marche", il est très difficile de comprendre > comment. Oui, c'est ce que j'ai écrit en disant que j'étais un peu perdu. Chacune des partie de systemd est relativement simple à comprendre, mais c'est de savoir ce qui est lancé et quand (ie : dans quel ordre) qui est plus difficile à suivre. Le fait que ça puisse être lancé en parallèle fait gagner du temps, mais ça ne simplifie pas la lecture. Je ne me suis pas plongé dans la compréhension de systemd, j'ai juste regardé les parties qui posaient problème lors de l'installation. > J'ai opté pour openrc, et là je retrouve des fichiers de configuration > comme on en est habitué sur sysV : Ouais, mais sysV c'était pas tout rose non plus. > Le système est très fluide et consomme peu de ressources. J'ai pas de problème à ce niveau-là. Je ne sais pas encore si le mieux est de me plonger dans systemd pour optimiser ou de changer au risque d'avoir des surprises. Mais j'ai d'autres priorités pour l'instant. |
|
|
Le 28/05/2020 à 18:47, Stéphane CARPENTIER a écrit :
> Ma première distribution, c'était une slackware, j'ai mangé grave pour > faire reconnaitre le lecteur de CD et la carte graphique. Il fallait > aussi recompiler mon noyau et tout ça (vers 94/95). À l'époque la doc > était éparse (plein de HOWTO sur le CD de la distribution) et > entièrement en anglais (à l'époque c'était un problème pour moi). Me too, une slack avec un noyo 1.2.13. Quelle époque épique !!! En 1996, en plein été. > Par contre, une fois que ça marchait, je n'ai jamais eu de problème : je > savais où chercher et comment réparer. Je confirme > Puis, est venu Ubuntu. D'abord, il est venu Lesbian a.k.a Debian J'ai eu une Hamm 2.0. J'ai jeté le CD. J'avais l'impression de ne pas être le patron de mon 486DX33, puis de mon K6-233 > J'ai essayé LFS il y a quelques années. C'est très formateur, mais il > faut vraiment du temps. Beaucoup de temps. Trop de temps pour > l'installation, ensuite j'ai pas bien compris comment les mises à jour > devaient se faire, mais j'imagine que c'est un travail à temps complet > et je ne suis pas allé au bout. Puis j'ai installé FreeBSD, puis NetBSD ... |
|
|
Le 01/06/2020 à 20:32, Stéphane CARPENTIER a écrit :
> Ouais, mais sysV c'était pas tout rose non plus. Ce qui me plaît dans le concept openrc : Separation of code and configuration (init.d / conf.d) <https://wiki.gentoo.org/wiki/OpenRC> Les principaux avantages d'OpenRC sont sa rapidité, sa gestion des dépendances entre services, et la possibilité de paralléliser (dans une certaine mesure) le démarrage des services. <https://linuxfr.org/news/petit-etat-de-l-art-des-systemes-d-initialisation-1> > J'ai pas de problème à ce niveau-là. Je ne sais pas encore si le mieux > est de me plonger dans systemd pour optimiser ou de changer au risque > d'avoir des surprises. Mais j'ai d'autres priorités pour l'instant. J'ai lu des côté du front, mais j'ai quand même retenu certains arguments présentés entre autres ici : <https://nosystemd.org/> |
|
|
Le 01 Jun 2020 18:32:04 GMT,
Stéphane CARPENTIER <sc> écrivait : > Le 01-06-2020, jp willm <nicole.jeanpaul.willm> a écrit : > Oui, c'est ce que j'ai écrit en disant que j'étais un peu perdu. Chacune > des partie de systemd est relativement simple à comprendre, mais c'est > de savoir ce qui est lancé et quand (ie : dans quel ordre) qui est plus > difficile à suivre. Le fait que ça puisse être lancé en parallèle fait > gagner du temps, mais ça ne simplifie pas la lecture. Non, le fait que ce soit lancé en parallèle ne fait pas toujours gagner du temps. Sur les environnements restreints en mémoire (256 à 512 Mo de mémoire, courant dans l'embarqué), c'est même beaucoup plus lent au démarrage parce que le système swappe d'emblée. Il me reste une machine de 256 Mo de mémoire qui pilote un scanner particulier (SCSI). Cette machine a des disques U320. Il lui fallait deux minutes pour démarrer avec init, il lui faut 45 minutes avec systemd. Dans le premier cas, le démarrage était séquentiel, la mémoire était suffisante. Dans le second, tout est lancé en même temps et le swap de 512 Mo est juste suffisant ! Même remarque avec une station diskless pourtant munie de 8 Go de mémoire et d'un i5 (on peut atteindre un bon quart d'heure). Quant à l'ordre de démarrage, c'est souvent un peu la roulette russe. Des configurations qui fonctionnaient avec une version du bouzin ne fonctionneint plus avec la version suivante. Je ne parle même pas de je ne sais plus quelle version de systemd qui écrasait certaines règles udev dont, sur l'un de mes serveur, le nom d'une interface réseau ! Heureusement que c'était celle d'un LAN ! Et, cerise sur le gâteau, je me suis aperçu que lors d'une mise à jour de systemd, le truc était capable de se mettre en vrac lors de l'extinction de la machine: il ne rend plus la main et il faut arrêter le serveur au bouton. Pratique lorsqu'il est à l'autre bout de la France et qu'on n'a plus de bandeau de prises commandables. > Je ne me suis pas > plongé dans la compréhension de systemd, j'ai juste regardé les parties > qui posaient problème lors de l'installation. En fait, tout pose problème dans systemd lorsqu'on commence à creuser et qu'on a une configuration qui n'est pas celle de madame Michu. Sur des postes diskless avec des swaps en iSCSI, la configuration du truc est rigologène. Ça finit par se faire, mais c'est beaucoup plus compliqué que ce qui se faisait avec SysV. Je ne parle même pas des modules qui écrasent les scripts de /etc/init.d à moins que ce soit le contraire, et des bouts qui traînent dans /etc/systemd/system et /etc/systemd/user qui écrasent la conf du système joyeusement. >> J'ai opté pour openrc, et là je retrouve des fichiers de configuration >> comme on en est habitué sur sysV : > Ouais, mais sysV c'était pas tout rose non plus. >> Le système est très fluide et consomme peu de ressources. > J'ai pas de problème à ce niveau-là. Je ne sais pas encore si le mieux > est de me plonger dans systemd pour optimiser ou de changer au risque > d'avoir des surprises. Mais j'ai d'autres priorités pour l'instant. Le problème de systemd vis à vis de Linux est le même que celui de Linux vis à vis de POSIX. Les sources POSIX sont polluées de linuxismes, ce qui fait qu'il faut patcher pour compiler ailleurs que sous Linux. systemd, de la même manière, devient un prérequis pour certains logiciels. On le fout dehors par la fenêtre, il rentre par la porte. Autant dompter la bête. Et virer Linux pour des Unix plus fiables sur le long terme. À titre personnel, il ne me reste plus qu'un seul serveur sous Linux (debian/testing). Tous les autres sont sous NetBSD, que du bonheur, pas de systemd, ça fait exactement ce que ça doit en consommant nettement moins de ressources. JKB |
|
|
Le 01-06-2020, jp willm <nicole.jeanpaul.willm> a écrit :
> Le 01/06/2020 à 20:32, Stéphane CARPENTIER a écrit : >> Ouais, mais sysV c'était pas tout rose non plus. > Ce qui me plaît dans le concept openrc : > Separation of code and configuration (init.d / conf.d) Oui, c'est surtout intéressant en fonction de la gestion des montés de versions. Mais sinon, c'est surtout une affaire de goût. Je n'ai pas vraiment de préférence à partir du moment où c'est homogène. ><https://wiki.gentoo.org/wiki/OpenRC> C'est intéressant, mais je vois aussi une des raisons qui font que je ne me pose pas de question pour changer. La première feature, c'est le support des cgroups. Je n'ai rien pour ou contre les cgroups, mais dans une critique j'ai lu que les cgroups c'est mal car c'est trop dépendant de systemd et c'est donc trop dépendant de Linux et donc les applications vont être moins portables. Vouloir supporter un truc qui est mal (en disant que c'est une innovation) me gêne. Soit c'est bien, soit c'est mal, mais si c'est mal dans un cas et bien dans l'autre, il est plus question de goût que d'argument factuel. Une liste de bugs n'est pas une raison et le fait que je n'ai pas eu le temps d'approfondir le sujet n'en est pas une non plus. J'ai vu des critiques mais pas des analyses, ie : comment une critique est traitée dans un autre système. Par exemple, une énorme critique est que systemd est monolitique, mais je n'ai pas vu d'explication sur les alternatives. Or, les plus grosses critiques ne sont pas sur les bugs mais sur la conception. Dans ce lien, il est question de l'utilisation plus que de la conception de openrc. Parce que même si le côté monolitique est mauvais, le fait de savoir que s'il y a un problème avec un évènement il faut regarder du côté de systemd possède un certain intérêt. > Les principaux avantages d'OpenRC sont sa rapidité, sa gestion des > dépendances entre services, et la possibilité de paralléliser (dans > une certaine mesure) le démarrage des services. ><https://linuxfr.org/news/petit-etat-de-l-art-des-systemes-d-initialisation-1> C'est aussi intéressant, même si c'est pas tout récent, mais c'est pareil. Ça me dit ce que je peux faire d'autre mais ça ne me dit pas pourquoi c'est mieux. OK, j'ai compris, il y a des défauts de conception avec systemd. OK, j'ai du mal à comprendre comment ça démarre, mais avant de dire que ça vient du système et pas de moi, il faut que je m'y plonge. OK, openrc est rapide mais chez moi systemd est rapide et consomme peu de ressources. OK, gnome est lié à systemd et c'est mal, mais je n'utilise pas gnome. OK, systemd est orienté desktop et pas serveur, mais ça tombe bien j'ai un desktop. En quoi les alternatives corrigent toutes les critiques sans contrepartie ? Pour quelle raison me prendre la tête à changer un truc qui marche bien alors que j'ai plein de choses à faire ? > J'ai lu des côté du front, mais j'ai quand même retenu certains > arguments présentés entre autres ici : ><https://nosystemd.org/> Oui, c'est pareil, ils tapent sur systemd avec une liste de bugs et de fonctionnalités. Mais je ne peux pas croire que les autres systèmes soient exempt de bugs. Ensuite, il y a plein d'alternatives. Sauf qu'il n'y a aucune justification sur les alternatives. Ça veut dire que systemd c'est mal et que toutes les alternatives sont bien ? Pour quitter systemd il y a des raisons factuelles mais pour choisir une alternative c'est une question de goût ? Désolé, mais ça ne passe pas. Je ne dis pas que openrec est mal et qu'il ne faut pas l'utiliser. Je dis que je ne vois pas l'intérêt de modifier la structure de mon système qui marche, juste parce que des gens ont décidé de partir en guerre contre systemd. Même si la guerre est justifiée, je le conçois. Tant que je n'en ai aucune utilité et que la guerre contre systemd ressemblera trop à une guerre de religion, je regarderai de loin. À mon avis, si systemd est vraiment si mal et que le reste est vraiment mieux, Archlinux quittera systemd pour aller vers autre chose. |
|
|
Stéphane CARPENTIER , dans le message
<slrnrdaum3.ra.sc>, a écrit : > une critique j'ai lu que les cgroups c'est mal car c'est trop dépendant > de systemd et c'est donc trop dépendant de Linux et donc les > applications vont être moins portables. Vouloir supporter un truc qui est > mal (en disant que c'est une innovation) me gêne. Les applications n'ont rien à savoir au sujet des cgroups, donc ça ne les rend pas moins portables. Les cgroups sont utilisés autour des applications, pour mieux les contrôler. Seuls quelques outils d'administration ont besoin de spécificités pour les cgroups ; c'est normal que les outils d'administration ne soient pas portables. > À mon avis, si systemd est vraiment si mal et que le reste est vraiment > mieux, Archlinux quittera systemd pour aller vers autre chose. Tout à fait. D'ailleurs, je trouve qu'il est important de remarquer que ceux dont l'occupation est de faire marcher les distributions importantes ont préféré utiliser systemd. Personnellement, je vois : - SysV init, qui est une grosse daube, mais une grosse daube que les dinosaures connaissent, donc qu'ils veulent garder ; - systemd, qui souffre d'un excès de fonctionnalités et d'un certain facisme de ses auteurs, mais qui fonctionne ; - des systèmes d'init rudimentaires, avec les inconvénients de SysV init et pas les avantages de systemd ; - des systèmes d'init mieux conçus, mais qui souffrent d'un manque d'énergie dans le développement. |
|
|
Le 02/06/2020 à 00:01, Stéphane CARPENTIER a écrit :
> Pour quelle raison me prendre la tête à changer un truc > qui marche bien alors que j'ai plein de choses à faire ? Le jour où ce "truc qui marche bien" sera devenu encore plus obèse et abscons, mais sera indécrottable de toute distribution Linux, on ne se posera plus cette question. On est en pleine politique, mais cela vaut le coup de lire un peu : [..] Je ne suis pas informaticien, mais j'observe que l'opensource est partout et commence à être contrôlé par de très grandes multinationales. Embrace, extend and extinguish : <https://fr.wikipedia.org/wiki/Embrace,_extend_and_extinguish> > À mon avis, si systemd est vraiment si mal et que le reste est vraiment > mieux, Archlinux quittera systemd pour aller vers autre chose. Je me suis aussi déjà fait cette réflexion : espérons... Toutefois, j'ai lu qu'un des principaux développeurs de Arch travaille chez IBM Redhat, chez qui ?uvre aussi l'inventeur de systemd. |
|
|
Le 02/06/2020 à 01:01, Nicolas George a écrit :
> - des systèmes d'init mieux conçus, mais qui souffrent d'un manque d'énergie > dans le développement. S6 ? |
|
|
Discussions similaires | |
Redhat Entreprise ou maj de Redhat 9
|
|
RedHat ES3 et RedHat classique
|
|
Gel de ma Redhat
|
|
4 cds redhat EL 3.0
|
Fuseau horaire GMT +2. Il est actuellement 11h22. | Privacy Policy
|