Bonsoir,
j'ai lu peut être un peu trop en diagonale le fil parlant de systemd.
il y a quelque chose qui à l'air de ressembler à une guerre de génération ;)
d'un coté, les dinos qui ne juraient que par "make menuconfig" (ou un truc
plus vieux, me rappelle plus) pour optimiser leur machine.
de l'autre, les jeunes qui ne connaissent que apt-get, yum ect ...
Pour mettre tout le monde d'accord, j'utilise pour poster une debian jessie
sur raspberry, donc systemd avec en face une slackware 11.0, donc init
classique avec malgré tout un support minimal de rc.xxxx start/stop.
Je n'ai pas de problème majeur ni avec l'un, ni avec l'autre.
En lisant en diagonale, j'ai lu ou cru avoir lu que des intervenants
considéraient le principe des liens symboliques comme un paquet de
spaghetti, quelque chose d'inutilisable.
Mais voilà, linux a percé en dehors du monde fermé des dinosaures,des
serveurs de courrier, de fichier etc ....
Par exemple,je ne pense pas exagérer en disant que + 50% des communications
téléphoniques dans les entreprises partent d'un noyau linux.
Tout ces joyeux industriels ont eu besoin de quelque chose de standardisé,
de pratique et de pas trop "dinosaurien" pour assurer une réussite de chaque
mise à jour ou adjonction de fonctionnalité.
Et là, dans la vrai vie, les fichiers init à la slackware atteigne vite leur
limite.
Bonsoir,
j'ai lu peut être un peu trop en diagonale le fil parlant de systemd.
il y a quelque chose qui à l'air de ressembler à une guerre de génération ;)
d'un coté, les dinos qui ne juraient que par "make menuconfig" (ou un truc
plus vieux, me rappelle plus) pour optimiser leur machine.
de l'autre, les jeunes qui ne connaissent que apt-get, yum ect ...
Pour mettre tout le monde d'accord, j'utilise pour poster une debian jessie
sur raspberry, donc systemd avec en face une slackware 11.0, donc init
classique avec malgré tout un support minimal de rc.xxxx start/stop.
Je n'ai pas de problème majeur ni avec l'un, ni avec l'autre.
En lisant en diagonale, j'ai lu ou cru avoir lu que des intervenants
considéraient le principe des liens symboliques comme un paquet de
spaghetti, quelque chose d'inutilisable.
Mais voilà, linux a percé en dehors du monde fermé des dinosaures,des
serveurs de courrier, de fichier etc ....
Par exemple,je ne pense pas exagérer en disant que + 50% des communications
téléphoniques dans les entreprises partent d'un noyau linux.
Tout ces joyeux industriels ont eu besoin de quelque chose de standardisé,
de pratique et de pas trop "dinosaurien" pour assurer une réussite de chaque
mise à jour ou adjonction de fonctionnalité.
Et là, dans la vrai vie, les fichiers init à la slackware atteigne vite leur
limite.
Bonsoir,
j'ai lu peut être un peu trop en diagonale le fil parlant de systemd.
il y a quelque chose qui à l'air de ressembler à une guerre de génération ;)
d'un coté, les dinos qui ne juraient que par "make menuconfig" (ou un truc
plus vieux, me rappelle plus) pour optimiser leur machine.
de l'autre, les jeunes qui ne connaissent que apt-get, yum ect ...
Pour mettre tout le monde d'accord, j'utilise pour poster une debian jessie
sur raspberry, donc systemd avec en face une slackware 11.0, donc init
classique avec malgré tout un support minimal de rc.xxxx start/stop.
Je n'ai pas de problème majeur ni avec l'un, ni avec l'autre.
En lisant en diagonale, j'ai lu ou cru avoir lu que des intervenants
considéraient le principe des liens symboliques comme un paquet de
spaghetti, quelque chose d'inutilisable.
Mais voilà, linux a percé en dehors du monde fermé des dinosaures,des
serveurs de courrier, de fichier etc ....
Par exemple,je ne pense pas exagérer en disant que + 50% des communications
téléphoniques dans les entreprises partent d'un noyau linux.
Tout ces joyeux industriels ont eu besoin de quelque chose de standardisé,
de pratique et de pas trop "dinosaurien" pour assurer une réussite de chaque
mise à jour ou adjonction de fonctionnalité.
Et là, dans la vrai vie, les fichiers init à la slackware atteigne vite leur
limite.
On point est de dire qu'on ne peut pas balayer d'un revers de main les
arguments de ceux qui n'apprécient que moyennement (euphémisme) systemd.
On point est de dire qu'on ne peut pas balayer d'un revers de main les
arguments de ceux qui n'apprécient que moyennement (euphémisme) systemd.
On point est de dire qu'on ne peut pas balayer d'un revers de main les
arguments de ceux qui n'apprécient que moyennement (euphémisme) systemd.
Bonsoir,
j'ai lu peut être un peu trop en diagonale le fil parlant de systemd.
il y a quelque chose qui à l'air de ressembler à une guerre de génération ;)
d'un coté, les dinos qui ne juraient que par "make menuconfig" (ou un truc
plus vieux, me rappelle plus) pour optimiser leur machine.
de l'autre, les jeunes qui ne connaissent que apt-get, yum ect ...
Pour mettre tout le monde d'accord, j'utilise pour poster une debian jessie
sur raspberry, donc systemd avec en face une slackware 11.0, donc init
classique avec malgré tout un support minimal de rc.xxxx start/stop.
Je n'ai pas de problème majeur ni avec l'un, ni avec l'autre.
En lisant en diagonale, j'ai lu ou cru avoir lu que des intervenants
considéraient le principe des liens symboliques comme un paquet de
spaghetti, quelque chose d'inutilisable.
Mais voilà, linux a percé en dehors du monde fermé des dinosaures,des
serveurs de courrier, de fichier etc ....
Par exemple,je ne pense pas exagérer en disant que + 50% des communications
téléphoniques dans les entreprises partent d'un noyau linux.
Tout ces joyeux industriels ont eu besoin de quelque chose de standardisé,
de pratique et de pas trop "dinosaurien" pour assurer une réussite de chaque
mise à jour ou adjonction de fonctionnalité.
Et là, dans la vrai vie, les fichiers init à la slackware atteigne vite leur
limite.
Bonsoir,
j'ai lu peut être un peu trop en diagonale le fil parlant de systemd.
il y a quelque chose qui à l'air de ressembler à une guerre de génération ;)
d'un coté, les dinos qui ne juraient que par "make menuconfig" (ou un truc
plus vieux, me rappelle plus) pour optimiser leur machine.
de l'autre, les jeunes qui ne connaissent que apt-get, yum ect ...
Pour mettre tout le monde d'accord, j'utilise pour poster une debian jessie
sur raspberry, donc systemd avec en face une slackware 11.0, donc init
classique avec malgré tout un support minimal de rc.xxxx start/stop.
Je n'ai pas de problème majeur ni avec l'un, ni avec l'autre.
En lisant en diagonale, j'ai lu ou cru avoir lu que des intervenants
considéraient le principe des liens symboliques comme un paquet de
spaghetti, quelque chose d'inutilisable.
Mais voilà, linux a percé en dehors du monde fermé des dinosaures,des
serveurs de courrier, de fichier etc ....
Par exemple,je ne pense pas exagérer en disant que + 50% des communications
téléphoniques dans les entreprises partent d'un noyau linux.
Tout ces joyeux industriels ont eu besoin de quelque chose de standardisé,
de pratique et de pas trop "dinosaurien" pour assurer une réussite de chaque
mise à jour ou adjonction de fonctionnalité.
Et là, dans la vrai vie, les fichiers init à la slackware atteigne vite leur
limite.
Bonsoir,
j'ai lu peut être un peu trop en diagonale le fil parlant de systemd.
il y a quelque chose qui à l'air de ressembler à une guerre de génération ;)
d'un coté, les dinos qui ne juraient que par "make menuconfig" (ou un truc
plus vieux, me rappelle plus) pour optimiser leur machine.
de l'autre, les jeunes qui ne connaissent que apt-get, yum ect ...
Pour mettre tout le monde d'accord, j'utilise pour poster une debian jessie
sur raspberry, donc systemd avec en face une slackware 11.0, donc init
classique avec malgré tout un support minimal de rc.xxxx start/stop.
Je n'ai pas de problème majeur ni avec l'un, ni avec l'autre.
En lisant en diagonale, j'ai lu ou cru avoir lu que des intervenants
considéraient le principe des liens symboliques comme un paquet de
spaghetti, quelque chose d'inutilisable.
Mais voilà, linux a percé en dehors du monde fermé des dinosaures,des
serveurs de courrier, de fichier etc ....
Par exemple,je ne pense pas exagérer en disant que + 50% des communications
téléphoniques dans les entreprises partent d'un noyau linux.
Tout ces joyeux industriels ont eu besoin de quelque chose de standardisé,
de pratique et de pas trop "dinosaurien" pour assurer une réussite de chaque
mise à jour ou adjonction de fonctionnalité.
Et là, dans la vrai vie, les fichiers init à la slackware atteigne vite leur
limite.
Doug713705 , dans le message <nu9roj$73i$, a
écrit :On point est de dire qu'on ne peut pas balayer d'un revers de main les
arguments de ceux qui n'apprécient que moyennement (euphémisme) systemd.
Quand ce sont de vrais arguments, précis et concrets, ils sont pris en
compte.
Mais quand ce ne sont que de vagues affirmations avec une tournure
compoltiste (« dépendances pieuvre », « essuyer le plâtre », « comportement
mal documenté et peu fiable » (alors qu'il suffit de regarder pour se rendre
compte que systemd est plutôt trop documenté que pas assez), « bien trop
souvent ératique »...).
Si tu veux qu'on prenne tes objections au sérieux, fais-en de solides, en
entrant dans les détails techniques.
Doug713705 , dans le message <nu9roj$73i$1@golgoth99.redatomik.org>, a
écrit :
On point est de dire qu'on ne peut pas balayer d'un revers de main les
arguments de ceux qui n'apprécient que moyennement (euphémisme) systemd.
Quand ce sont de vrais arguments, précis et concrets, ils sont pris en
compte.
Mais quand ce ne sont que de vagues affirmations avec une tournure
compoltiste (« dépendances pieuvre », « essuyer le plâtre », « comportement
mal documenté et peu fiable » (alors qu'il suffit de regarder pour se rendre
compte que systemd est plutôt trop documenté que pas assez), « bien trop
souvent ératique »...).
Si tu veux qu'on prenne tes objections au sérieux, fais-en de solides, en
entrant dans les détails techniques.
Doug713705 , dans le message <nu9roj$73i$, a
écrit :On point est de dire qu'on ne peut pas balayer d'un revers de main les
arguments de ceux qui n'apprécient que moyennement (euphémisme) systemd.
Quand ce sont de vrais arguments, précis et concrets, ils sont pris en
compte.
Mais quand ce ne sont que de vagues affirmations avec une tournure
compoltiste (« dépendances pieuvre », « essuyer le plâtre », « comportement
mal documenté et peu fiable » (alors qu'il suffit de regarder pour se rendre
compte que systemd est plutôt trop documenté que pas assez), « bien trop
souvent ératique »...).
Si tu veux qu'on prenne tes objections au sérieux, fais-en de solides, en
entrant dans les détails techniques.
Pourtant l'objection de la pieuvre est absolument évidente.
A partir du
moment où un certain nombre de logiciels d'usage courant (exemple Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they don’t have time to
develop missing functionality in OpenRC 3) supporting non-systemd +
systemd at the same time likely resulting in bugs and a lot of support
time, they decided it is much easier to just require systemd/logind.
This also get the features that systemd and logind offer and avoid any
weird bugs (as most GNOME developers seem to use systemd).
Pourtant l'objection de la pieuvre est absolument évidente.
A partir du
moment où un certain nombre de logiciels d'usage courant (exemple Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they don’t have time to
develop missing functionality in OpenRC 3) supporting non-systemd +
systemd at the same time likely resulting in bugs and a lot of support
time, they decided it is much easier to just require systemd/logind.
This also get the features that systemd and logind offer and avoid any
weird bugs (as most GNOME developers seem to use systemd).
Pourtant l'objection de la pieuvre est absolument évidente.
A partir du
moment où un certain nombre de logiciels d'usage courant (exemple Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they don’t have time to
develop missing functionality in OpenRC 3) supporting non-systemd +
systemd at the same time likely resulting in bugs and a lot of support
time, they decided it is much easier to just require systemd/logind.
This also get the features that systemd and logind offer and avoid any
weird bugs (as most GNOME developers seem to use systemd).
d'un coté, les dinos qui ne juraient que par "make menuconfig" (ou un
truc plus vieux, me rappelle plus) pour optimiser leur machine.
make config ?
Heureux homme. Je ne nie pas la "difficulté" qu'il y a à configurer *en
détail* une Slackware mais ce n'est certainement pas au niveau des
service que pourraient se situer les problèmes mais plutôt dans
l'éventuel manque de convivialité des outils mis à disposition qui
globalement disposent au mieux d'une interface Dialog et bien souvent
l'outil le plus adapté reste un éditeur de texte.
Tout ces joyeux industriels ont eu besoin de quelque chose de
standardisé, de pratique et de pas trop "dinosaurien" pour assurer une
réussite de chaque mise à jour ou adjonction de fonctionnalité.
Et là, dans la vrai vie, les fichiers init à la slackware atteigne vite
leur limite.
Ça reste à démontrer, ton téléphone ne fait certainement pas à la fois
client et serveur de mails, serveur de DNS, serveur d'impression et
serveur de fichiers, etc. Il fait téléphone SIP et au mieux il se connecte
sur un annuaire ldap et n'a pas 42 services optionnels mais simplement le
minimum pour booter et faire son boulot.
d'un coté, les dinos qui ne juraient que par "make menuconfig" (ou un
truc plus vieux, me rappelle plus) pour optimiser leur machine.
make config ?
Heureux homme. Je ne nie pas la "difficulté" qu'il y a à configurer *en
détail* une Slackware mais ce n'est certainement pas au niveau des
service que pourraient se situer les problèmes mais plutôt dans
l'éventuel manque de convivialité des outils mis à disposition qui
globalement disposent au mieux d'une interface Dialog et bien souvent
l'outil le plus adapté reste un éditeur de texte.
Tout ces joyeux industriels ont eu besoin de quelque chose de
standardisé, de pratique et de pas trop "dinosaurien" pour assurer une
réussite de chaque mise à jour ou adjonction de fonctionnalité.
Et là, dans la vrai vie, les fichiers init à la slackware atteigne vite
leur limite.
Ça reste à démontrer, ton téléphone ne fait certainement pas à la fois
client et serveur de mails, serveur de DNS, serveur d'impression et
serveur de fichiers, etc. Il fait téléphone SIP et au mieux il se connecte
sur un annuaire ldap et n'a pas 42 services optionnels mais simplement le
minimum pour booter et faire son boulot.
d'un coté, les dinos qui ne juraient que par "make menuconfig" (ou un
truc plus vieux, me rappelle plus) pour optimiser leur machine.
make config ?
Heureux homme. Je ne nie pas la "difficulté" qu'il y a à configurer *en
détail* une Slackware mais ce n'est certainement pas au niveau des
service que pourraient se situer les problèmes mais plutôt dans
l'éventuel manque de convivialité des outils mis à disposition qui
globalement disposent au mieux d'une interface Dialog et bien souvent
l'outil le plus adapté reste un éditeur de texte.
Tout ces joyeux industriels ont eu besoin de quelque chose de
standardisé, de pratique et de pas trop "dinosaurien" pour assurer une
réussite de chaque mise à jour ou adjonction de fonctionnalité.
Et là, dans la vrai vie, les fichiers init à la slackware atteigne vite
leur limite.
Ça reste à démontrer, ton téléphone ne fait certainement pas à la fois
client et serveur de mails, serveur de DNS, serveur d'impression et
serveur de fichiers, etc. Il fait téléphone SIP et au mieux il se connecte
sur un annuaire ldap et n'a pas 42 services optionnels mais simplement le
minimum pour booter et faire son boulot.
Ce n'est donc pas une guerre de génération avec d'un côté les vieux
et de l'autre les jeunes, mais une guerre entre ceux qui veulent que
ça fonctionne à tous les coups et ceux qui se contrefichent
d'essuyer les plâtres avec des briques.
J'ajoute qu'il y a un effet de bord rigolo entre systemd, udev et le
noyau. En faisant récemment une mise à jour (qui n'a touché que
systemd), j'ai eu la surprise de voir tous les modules noyau déchargés
avec l'impossibilité de les recharger. Obligation de redémarrer mon
serveur. Ce genre de comportement est inacceptable.
Ce n'est donc pas une guerre de génération avec d'un côté les vieux
et de l'autre les jeunes, mais une guerre entre ceux qui veulent que
ça fonctionne à tous les coups et ceux qui se contrefichent
d'essuyer les plâtres avec des briques.
J'ajoute qu'il y a un effet de bord rigolo entre systemd, udev et le
noyau. En faisant récemment une mise à jour (qui n'a touché que
systemd), j'ai eu la surprise de voir tous les modules noyau déchargés
avec l'impossibilité de les recharger. Obligation de redémarrer mon
serveur. Ce genre de comportement est inacceptable.
Ce n'est donc pas une guerre de génération avec d'un côté les vieux
et de l'autre les jeunes, mais une guerre entre ceux qui veulent que
ça fonctionne à tous les coups et ceux qui se contrefichent
d'essuyer les plâtres avec des briques.
J'ajoute qu'il y a un effet de bord rigolo entre systemd, udev et le
noyau. En faisant récemment une mise à jour (qui n'a touché que
systemd), j'ai eu la surprise de voir tous les modules noyau déchargés
avec l'impossibilité de les recharger. Obligation de redémarrer mon
serveur. Ce genre de comportement est inacceptable.
moment où un certain nombre de logiciels d'usage courant (exemple Gnome)
moment où un certain nombre de logiciels d'usage courant (exemple Gnome)
moment où un certain nombre de logiciels d'usage courant (exemple Gnome)
le problème ne serait pas pas plutôt support ? Suse et Redhat le font eu
même si contrat.pour Debian ou autre, c'est le prestataire.
le problème ne serait pas pas plutôt support ? Suse et Redhat le font eu
même si contrat.pour Debian ou autre, c'est le prestataire.
le problème ne serait pas pas plutôt support ? Suse et Redhat le font eu
même si contrat.pour Debian ou autre, c'est le prestataire.
Le Fri, 21 Oct 2016 01:19:24 +0200,
Eric Stern écrivait :le problème ne serait pas pas plutôt support ? Suse et Redhat le font eu
même si contrat.pour Debian ou autre, c'est le prestataire.
Lorsqu'un serveur est en rade, je me contrefiche du support. Ce qui
est hébergé ne fonctionne plus.
Le Fri, 21 Oct 2016 01:19:24 +0200,
Eric Stern <xdv5@coulommiers.org> écrivait :
le problème ne serait pas pas plutôt support ? Suse et Redhat le font eu
même si contrat.pour Debian ou autre, c'est le prestataire.
Lorsqu'un serveur est en rade, je me contrefiche du support. Ce qui
est hébergé ne fonctionne plus.
Le Fri, 21 Oct 2016 01:19:24 +0200,
Eric Stern écrivait :le problème ne serait pas pas plutôt support ? Suse et Redhat le font eu
même si contrat.pour Debian ou autre, c'est le prestataire.
Lorsqu'un serveur est en rade, je me contrefiche du support. Ce qui
est hébergé ne fonctionne plus.