Redhat

Nicolas George

28/05/2020 à 13:33

Jo Engo , dans le message
<pan$dbd78$c7ffc3a2$544a64d7$, 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.

Stéphane CARPENTIER

28/05/2020 à 18:47

Le 28-05-2020, Jo Engo 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.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Le 28-05-2020, Jo Engo <yl@icite.fr> 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.

--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Vous avez filtré cet utilisateur ! Consultez son message

Le 28-05-2020, Jo Engo 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.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

jp willm

01/06/2020 à 16:12

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).
--
jp willm
http://willms.yj.fr/willms/index.html

Stéphane CARPENTIER

01/06/2020 à 18:02

Le 01-06-2020, jp 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.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

jp willm

01/06/2020 à 19:01

Le 01/06/2020 à 18:02, Stéphane CARPENTIER a écrit :

Le 01-06-2020, jp 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.

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.
--
jp willm
http://willms.yj.fr/willms/index.html

Stéphane CARPENTIER

01/06/2020 à 20:32

Le 01-06-2020, jp willm a écrit :

Le 01/06/2020 à 18:02, Stéphane CARPENTIER a écrit :
Le 01-06-2020, jp 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.

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.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

festiventu

01/06/2020 à 21:32

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 ...

jp willm

01/06/2020 à 21:48

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/>
--
jp willm
http://willms.yj.fr/willms/index.html

JKB

01/06/2020 à 23:27

Le 01 Jun 2020 18:32:04 GMT,
Stéphane CARPENTIER écrivait :

Le 01-06-2020, jp willm a écrit :
Le 01/06/2020 à 18:02, Stéphane CARPENTIER a écrit :
Le 01-06-2020, jp 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.

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.

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
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Le 01 Jun 2020 18:32:04 GMT,
Stéphane CARPENTIER <sc@fiat-linux.fr> écrivait :

Le 01-06-2020, jp willm <nicole.jeanpaul.willm@wanadoo.fr> a écrit :

Le 01/06/2020 à 18:02, Stéphane CARPENTIER a écrit :

Le 01-06-2020, jp willm <nicole.jeanpaul.willm@wanadoo.fr> 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.

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.

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

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Vous avez filtré cet utilisateur ! Consultez son message

Le 01 Jun 2020 18:32:04 GMT,
Stéphane CARPENTIER écrivait :

Le 01-06-2020, jp willm a écrit :
Le 01/06/2020 à 18:02, Stéphane CARPENTIER a écrit :
Le 01-06-2020, jp 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.

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.

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
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Stéphane CARPENTIER

02/06/2020 à 00:01

Le 01-06-2020, jp 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.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Le 01-06-2020, jp willm <nicole.jeanpaul.willm@wanadoo.fr> 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.

--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Vous avez filtré cet utilisateur ! Consultez son message

Le 01-06-2020, jp 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.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Redhat

10 réponses

Veuillez sélectionner un problème