Je note, avant de tout oublier, si ça vous intérese, lisez, sinon passez
au message suivant ^^
- J'ai finalement tout fait avec gparted, ce qui m'a évité d'avoir à
manipuler les uuid (monter /, lire le contenu de fstab, copier-coller les
uuid
- gparted m'a fait une belle frayeur en plantant au milieu du
processus. Je n'ai pas réussi à comprendre où ça a planté précisément
mais je n'ai pas eu de pertes de données, j'ai reprogrammé les opérations
qui n'avaient pas été faites
- gparted a déduit une seul opération «shrink» de réduire/déplacer/
agrandir mais c'est pas grave parce que
- gparted fait un repartitionnement «intelligent» il ne recopie que les
secteurs utilisés donc ça a été très rapide, ç'aurait sans doute été
encore plus rapide avec un deuxième disque
- j'ai supprimmé la partition /opt dont je n'ai pas l'usage et j'ai
oublié de rectifier fstab regimbage au démarrage, il (debian) me demande
le mot de passe de root que j'ai dû définir puis oublier ^^ vu que je me
sers de sudo, je ne me souviens plus de comment je m'en suis sorti en
démarrant en single ou avec SystemRescueCD que j'avais sous la main (en
fait je m'en était servi pour repartitionner -_o j'ai commenté l'entrée
de fstab et depuis tout roule
Doug713705 , dans le message <pb0gnf$ba6$, a écrit :
Je ne parle pas de faire une bouse générique autant imbitable que non maintenanble mais d'un script maison adapté à la situation rencontrée et pas à celle du voisin.
Même comme ça. Faire un script shell fiable est très difficile. C'est précisément en partant dans cette direction que tu bâtis un truc qui va faire n'importe quoi, typiquement le contraire de ce qu'on veut, dès qu'il rencontre un cas imprévu.
Doug713705 , dans le message <pb0gnf$ba6$1@golgoth99.redatomik.org>, a
écrit :
Je ne parle pas de faire une bouse générique autant imbitable que non
maintenanble mais d'un script maison adapté à la situation rencontrée et
pas à celle du voisin.
Même comme ça. Faire un script shell fiable est très difficile. C'est
précisément en partant dans cette direction que tu bâtis un truc qui va
faire n'importe quoi, typiquement le contraire de ce qu'on veut, dès
qu'il rencontre un cas imprévu.
Doug713705 , dans le message <pb0gnf$ba6$, a écrit :
Je ne parle pas de faire une bouse générique autant imbitable que non maintenanble mais d'un script maison adapté à la situation rencontrée et pas à celle du voisin.
Même comme ça. Faire un script shell fiable est très difficile. C'est précisément en partant dans cette direction que tu bâtis un truc qui va faire n'importe quoi, typiquement le contraire de ce qu'on veut, dès qu'il rencontre un cas imprévu.
Doug713705
Le 15-04-2018, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5ad3ca45$0$9295$) :
Je ne parle pas de faire une bouse générique autant imbitable que non maintenanble mais d'un script maison adapté à la situation rencontrée et pas à celle du voisin.
Même comme ça. Faire un script shell fiable est très difficile. C'est précisément en partant dans cette direction que tu bâtis un truc qui va faire n'importe quoi, typiquement le contraire de ce qu'on veut, dès qu'il rencontre un cas imprévu.
Très difficile, tu exagères. Tu penses déjà à vouloir résoudre des cas qui n'existent pas dans la plupart des réalités de terrains. Il est quand même beaucoup plus simple de résoudre un problème qu'on a identifié localement qu'une myriade de problèmes dont on ne connait rien. Il ne s'agit pas non plus de tenter de résoudre le problème de la partition manquante mais simplement de savoir si les données attendues (ici le FS) sont disponibles au moment où on en a besoin (ici au démarrage du service). La réponse est "oui" ou "non", pas "peut-être attends un peu on ne sait jamais avec le réseau des fois ça peut revenir, saloperie de NFS c'est toujours ça qui lâche, vas-y retente maintenant". Bien sûr que le script du sysadmin du coin aura besoin d'évoluer lorsque de nouveaux cas imprévus seront découverts mais: - Ces cas seront peu nombreux. Logiquement le sysadmin du coin connait son infrastructure. Il peut ne pas avoir pensé à tout mais tous les cas possibles seront vites identfiés. - La réactivité sera bien meilleure que celle de l'upstream qui aura besoin d'attendre la confirmation du rapport de bug, puis devra allouer des ressources pour réssoudre le problème. Le tout si et seulement si l'upstream estime important de le résoudre rapidement (et avec LP aux commandes on sait que c'est parfois difficile). -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Le 15-04-2018, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<5ad3ca45$0$9295$426a74cc@news.free.fr>) :
Je ne parle pas de faire une bouse générique autant imbitable que non
maintenanble mais d'un script maison adapté à la situation rencontrée et
pas à celle du voisin.
Même comme ça. Faire un script shell fiable est très difficile. C'est
précisément en partant dans cette direction que tu bâtis un truc qui va
faire n'importe quoi, typiquement le contraire de ce qu'on veut, dès
qu'il rencontre un cas imprévu.
Très difficile, tu exagères. Tu penses déjà à vouloir résoudre des cas qui
n'existent pas dans la plupart des réalités de terrains.
Il est quand même beaucoup plus simple de résoudre un problème qu'on a
identifié localement qu'une myriade de problèmes dont on ne connait rien.
Il ne s'agit pas non plus de tenter de résoudre le problème de la
partition manquante mais simplement de savoir si les données attendues
(ici le FS) sont disponibles au moment où on en a besoin (ici au démarrage
du service).
La réponse est "oui" ou "non", pas "peut-être attends un peu on ne sait
jamais avec le réseau des fois ça peut revenir, saloperie de NFS c'est
toujours ça qui lâche, vas-y retente maintenant".
Bien sûr que le script du sysadmin du coin aura besoin d'évoluer lorsque
de nouveaux cas imprévus seront découverts mais:
- Ces cas seront peu nombreux. Logiquement le sysadmin du coin connait
son infrastructure. Il peut ne pas avoir pensé à tout mais tous les
cas possibles seront vites identfiés.
- La réactivité sera bien meilleure que celle de l'upstream qui aura
besoin d'attendre la confirmation du rapport de bug, puis devra
allouer des ressources pour réssoudre le problème. Le tout si et
seulement si l'upstream estime important de le résoudre rapidement
(et avec LP aux commandes on sait que c'est parfois difficile).
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Le 15-04-2018, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5ad3ca45$0$9295$) :
Je ne parle pas de faire une bouse générique autant imbitable que non maintenanble mais d'un script maison adapté à la situation rencontrée et pas à celle du voisin.
Même comme ça. Faire un script shell fiable est très difficile. C'est précisément en partant dans cette direction que tu bâtis un truc qui va faire n'importe quoi, typiquement le contraire de ce qu'on veut, dès qu'il rencontre un cas imprévu.
Très difficile, tu exagères. Tu penses déjà à vouloir résoudre des cas qui n'existent pas dans la plupart des réalités de terrains. Il est quand même beaucoup plus simple de résoudre un problème qu'on a identifié localement qu'une myriade de problèmes dont on ne connait rien. Il ne s'agit pas non plus de tenter de résoudre le problème de la partition manquante mais simplement de savoir si les données attendues (ici le FS) sont disponibles au moment où on en a besoin (ici au démarrage du service). La réponse est "oui" ou "non", pas "peut-être attends un peu on ne sait jamais avec le réseau des fois ça peut revenir, saloperie de NFS c'est toujours ça qui lâche, vas-y retente maintenant". Bien sûr que le script du sysadmin du coin aura besoin d'évoluer lorsque de nouveaux cas imprévus seront découverts mais: - Ces cas seront peu nombreux. Logiquement le sysadmin du coin connait son infrastructure. Il peut ne pas avoir pensé à tout mais tous les cas possibles seront vites identfiés. - La réactivité sera bien meilleure que celle de l'upstream qui aura besoin d'attendre la confirmation du rapport de bug, puis devra allouer des ressources pour réssoudre le problème. Le tout si et seulement si l'upstream estime important de le résoudre rapidement (et avec LP aux commandes on sait que c'est parfois difficile). -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Nicolas George
Doug713705 , dans le message <pb0jnk$ba6$, a écrit :
Très difficile, tu exagères.
Non, je n'exagère pas. Le shell est un langage très rudimentaire et plein de pièges subtils et pénibles.
Il est quand même beaucoup plus simple de résoudre un problème qu'on a identifié localement qu'une myriade de problèmes dont on ne connait rien.
Et en résolvant ce problème local, on s'en prépare deux pour plus tard.
Bien sûr que le script du sysadmin du coin aura besoin d'évoluer lorsque de nouveaux cas imprévus seront découverts mais:
Et chaque nouvelle couche double le nombre de problèmes potentiels.
- La réactivité sera bien meilleure que celle de l'upstream qui aura besoin d'attendre la confirmation du rapport de bug, puis devra allouer des ressources pour réssoudre le problème.
Et puis surtout prendre le temps de réfléchir à une solution qui marche vraiment. C'est ça qui fait toute la différence.
Doug713705 , dans le message <pb0jnk$ba6$2@golgoth99.redatomik.org>, a
écrit :
Très difficile, tu exagères.
Non, je n'exagère pas. Le shell est un langage très rudimentaire et
plein de pièges subtils et pénibles.
Il est quand même beaucoup plus simple de résoudre un problème qu'on a
identifié localement qu'une myriade de problèmes dont on ne connait rien.
Et en résolvant ce problème local, on s'en prépare deux pour plus tard.
Bien sûr que le script du sysadmin du coin aura besoin d'évoluer lorsque
de nouveaux cas imprévus seront découverts mais:
Et chaque nouvelle couche double le nombre de problèmes potentiels.
- La réactivité sera bien meilleure que celle de l'upstream qui aura
besoin d'attendre la confirmation du rapport de bug, puis devra
allouer des ressources pour réssoudre le problème.
Et puis surtout prendre le temps de réfléchir à une solution qui marche
vraiment. C'est ça qui fait toute la différence.
Doug713705 , dans le message <pb0jnk$ba6$, a écrit :
Très difficile, tu exagères.
Non, je n'exagère pas. Le shell est un langage très rudimentaire et plein de pièges subtils et pénibles.
Il est quand même beaucoup plus simple de résoudre un problème qu'on a identifié localement qu'une myriade de problèmes dont on ne connait rien.
Et en résolvant ce problème local, on s'en prépare deux pour plus tard.
Bien sûr que le script du sysadmin du coin aura besoin d'évoluer lorsque de nouveaux cas imprévus seront découverts mais:
Et chaque nouvelle couche double le nombre de problèmes potentiels.
- La réactivité sera bien meilleure que celle de l'upstream qui aura besoin d'attendre la confirmation du rapport de bug, puis devra allouer des ressources pour réssoudre le problème.
Et puis surtout prendre le temps de réfléchir à une solution qui marche vraiment. C'est ça qui fait toute la différence.
Doug713705
Le 16-04-2018, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5ad465d3$0$7190$) :
Doug713705 , dans le message <pb0jnk$ba6$, a écrit :
Très difficile, tu exagères.
Non, je n'exagère pas. Le shell est un langage très rudimentaire et plein de pièges subtils et pénibles.
C'est un outil documenté de longue date. Les capacités et limites en sont connues depuis longtemps et il est employé avec succès depuis des lustres. Même si la situation change au fur et à mesure du progrès des technos Il n'est pas devenu plus difficile du jour au lendemain sans prévenir. Les mecs ne savent pas coder en shell et voudrait coder from scratch un init complet /o
Il est quand même beaucoup plus simple de résoudre un problème qu'on a identifié localement qu'une myriade de problèmes dont on ne connait rien.
Et en résolvant ce problème local, on s'en prépare deux pour plus tard.
Bien sûr que le script du sysadmin du coin aura besoin d'évoluer lorsque de nouveaux cas imprévus seront découverts mais:
Et chaque nouvelle couche double le nombre de problèmes potentiels.
N'importe quoi, ce n'est pas systématiquement le cas. Et si ça l'était ce serait nécessairement également valable et même pire pour systemd qui aurait tout un tas de combinaisons suppléméntaires à traiter puisqu'il tente de traiter tous les cas. Tous les arguments que tu peux employer contre init et une poignée de scripts bien pensés sont totalement appliquables à systemd sauf que dans un cas on traite parfaitement un problème local totalement cerné alors que dans l'autre on tente de deviner quel pourrait être le problème parmi n solutions possibles (explosion combinatoire garantie). Si c'est pour qu'à là fin un joli "K2000" rouge à la con me chie une erreur parce qu'il a été impossible de déterminer ce qu'il fallait faire alors je n'ai vraiment pas besoin de cette "solution" qui n'en est pas une.
- La réactivité sera bien meilleure que celle de l'upstream qui aura besoin d'attendre la confirmation du rapport de bug, puis devra allouer des ressources pour réssoudre le problème.
Et puis surtout prendre le temps de réfléchir à une solution qui marche vraiment. C'est ça qui fait toute la différence.
Tu te rends bien compte qu'un serveur down en prod ne peut pas vraiment attendre que l'upstream prenne une décision, que le patch soit codé, testé, poussé, que la distribution empaquète le tout et que la mise à jour de tout ça finisse par arriver sur un dépot. Je ne dis pas qu'il ne faut pas prendre son temps pour faire de bons outils mais honnêtement ça ne semble vraiment pas être le chemin pris par systemd qui a plutôt tendance à pousser de la merde le plus vite possible. La situation est d'autant plus grave que systemd a été adopté et poussé en prod alors qu'il n'était clairement pas mûr, loin s'en faut ! Alors les discours sur "le temps de réfléchir", c'est juste LOL concernant systemd. Personne n'a vraiment réfléchi à systemd. Le truc a été poussé à la rache (https://www.la-rache.com). Ton discours serait crédible si systemd avait réèllement apporté ce qui avait été annoncé et qu'il n'avait pas fait l'objet d'un puissant lobbying pour être adopté en masse par les grandes distributions avant qu'il ne soit sec obligeant tout le monde à creuser encore plus le trou pour se sortir de la situation. Sauf que la sortie est par le haut les gars ! Ce projet est tout simplement pitoyable à plus d'un niveau. -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Le 16-04-2018, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<5ad465d3$0$7190$426a74cc@news.free.fr>) :
Doug713705 , dans le message <pb0jnk$ba6$2@golgoth99.redatomik.org>, a
écrit :
Très difficile, tu exagères.
Non, je n'exagère pas. Le shell est un langage très rudimentaire et
plein de pièges subtils et pénibles.
C'est un outil documenté de longue date.
Les capacités et limites en sont connues depuis longtemps et il est
employé avec succès depuis des lustres.
Même si la situation change au fur et à mesure du progrès des technos
Il n'est pas devenu plus difficile du jour au lendemain sans prévenir.
Les mecs ne savent pas coder en shell et voudrait coder from scratch
un init complet /o
Il est quand même beaucoup plus simple de résoudre un problème qu'on a
identifié localement qu'une myriade de problèmes dont on ne connait rien.
Et en résolvant ce problème local, on s'en prépare deux pour plus tard.
Bien sûr que le script du sysadmin du coin aura besoin d'évoluer lorsque
de nouveaux cas imprévus seront découverts mais:
Et chaque nouvelle couche double le nombre de problèmes potentiels.
N'importe quoi, ce n'est pas systématiquement le cas.
Et si ça l'était ce serait nécessairement également valable et même
pire pour systemd qui aurait tout un tas de combinaisons suppléméntaires
à traiter puisqu'il tente de traiter tous les cas.
Tous les arguments que tu peux employer contre init et une poignée de
scripts bien pensés sont totalement appliquables à systemd sauf que dans
un cas on traite parfaitement un problème local totalement cerné alors
que dans l'autre on tente de deviner quel pourrait être le problème
parmi n solutions possibles (explosion combinatoire garantie).
Si c'est pour qu'à là fin un joli "K2000" rouge à la con me chie
une erreur parce qu'il a été impossible de déterminer ce qu'il fallait
faire alors je n'ai vraiment pas besoin de cette "solution" qui n'en est
pas une.
- La réactivité sera bien meilleure que celle de l'upstream qui aura
besoin d'attendre la confirmation du rapport de bug, puis devra
allouer des ressources pour réssoudre le problème.
Et puis surtout prendre le temps de réfléchir à une solution qui marche
vraiment. C'est ça qui fait toute la différence.
Tu te rends bien compte qu'un serveur down en prod ne peut pas vraiment
attendre que l'upstream prenne une décision, que le patch soit codé,
testé, poussé, que la distribution empaquète le tout et que la mise à
jour de tout ça finisse par arriver sur un dépot.
Je ne dis pas qu'il ne faut pas prendre son temps pour faire de bons
outils mais honnêtement ça ne semble vraiment pas être le chemin pris par
systemd qui a plutôt tendance à pousser de la merde le plus vite possible.
La situation est d'autant plus grave que systemd a été adopté et poussé
en prod alors qu'il n'était clairement pas mûr, loin s'en faut !
Alors les discours sur "le temps de réfléchir", c'est juste LOL concernant
systemd.
Personne n'a vraiment réfléchi à systemd. Le truc a été poussé à la
rache (https://www.la-rache.com).
Ton discours serait crédible si systemd avait réèllement apporté ce qui
avait été annoncé et qu'il n'avait pas fait l'objet d'un puissant
lobbying pour être adopté en masse par les grandes distributions avant
qu'il ne soit sec obligeant tout le monde à creuser encore plus le trou
pour se sortir de la situation. Sauf que la sortie est par le haut les gars !
Ce projet est tout simplement pitoyable à plus d'un niveau.
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Le 16-04-2018, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5ad465d3$0$7190$) :
Doug713705 , dans le message <pb0jnk$ba6$, a écrit :
Très difficile, tu exagères.
Non, je n'exagère pas. Le shell est un langage très rudimentaire et plein de pièges subtils et pénibles.
C'est un outil documenté de longue date. Les capacités et limites en sont connues depuis longtemps et il est employé avec succès depuis des lustres. Même si la situation change au fur et à mesure du progrès des technos Il n'est pas devenu plus difficile du jour au lendemain sans prévenir. Les mecs ne savent pas coder en shell et voudrait coder from scratch un init complet /o
Il est quand même beaucoup plus simple de résoudre un problème qu'on a identifié localement qu'une myriade de problèmes dont on ne connait rien.
Et en résolvant ce problème local, on s'en prépare deux pour plus tard.
Bien sûr que le script du sysadmin du coin aura besoin d'évoluer lorsque de nouveaux cas imprévus seront découverts mais:
Et chaque nouvelle couche double le nombre de problèmes potentiels.
N'importe quoi, ce n'est pas systématiquement le cas. Et si ça l'était ce serait nécessairement également valable et même pire pour systemd qui aurait tout un tas de combinaisons suppléméntaires à traiter puisqu'il tente de traiter tous les cas. Tous les arguments que tu peux employer contre init et une poignée de scripts bien pensés sont totalement appliquables à systemd sauf que dans un cas on traite parfaitement un problème local totalement cerné alors que dans l'autre on tente de deviner quel pourrait être le problème parmi n solutions possibles (explosion combinatoire garantie). Si c'est pour qu'à là fin un joli "K2000" rouge à la con me chie une erreur parce qu'il a été impossible de déterminer ce qu'il fallait faire alors je n'ai vraiment pas besoin de cette "solution" qui n'en est pas une.
- La réactivité sera bien meilleure que celle de l'upstream qui aura besoin d'attendre la confirmation du rapport de bug, puis devra allouer des ressources pour réssoudre le problème.
Et puis surtout prendre le temps de réfléchir à une solution qui marche vraiment. C'est ça qui fait toute la différence.
Tu te rends bien compte qu'un serveur down en prod ne peut pas vraiment attendre que l'upstream prenne une décision, que le patch soit codé, testé, poussé, que la distribution empaquète le tout et que la mise à jour de tout ça finisse par arriver sur un dépot. Je ne dis pas qu'il ne faut pas prendre son temps pour faire de bons outils mais honnêtement ça ne semble vraiment pas être le chemin pris par systemd qui a plutôt tendance à pousser de la merde le plus vite possible. La situation est d'autant plus grave que systemd a été adopté et poussé en prod alors qu'il n'était clairement pas mûr, loin s'en faut ! Alors les discours sur "le temps de réfléchir", c'est juste LOL concernant systemd. Personne n'a vraiment réfléchi à systemd. Le truc a été poussé à la rache (https://www.la-rache.com). Ton discours serait crédible si systemd avait réèllement apporté ce qui avait été annoncé et qu'il n'avait pas fait l'objet d'un puissant lobbying pour être adopté en masse par les grandes distributions avant qu'il ne soit sec obligeant tout le monde à creuser encore plus le trou pour se sortir de la situation. Sauf que la sortie est par le haut les gars ! Ce projet est tout simplement pitoyable à plus d'un niveau. -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Nicolas George
Doug713705 , dans le message <pb1t2q$mt6$, a écrit :
C'est un outil documenté de longue date. Les capacités et limites en sont connues depuis longtemps et il est
Oui. On sait depuis longtemps à quel point le shell est casse-figure. Enfin, ceux qui réfléchissent à ce genre de choses le savent. Les autres se cassent la figure, et parfois ne s'en rendent même pas compte.
employé avec succès depuis des lustres.
Oui. Et surtout employé avec échec depuis des lustres.
Les mecs ne savent pas coder en shell et voudrait coder from scratch un init complet /o
Exactement.
N'importe quoi, ce n'est pas systématiquement le cas.
Potentiellement si.
Et si ça l'était ce serait nécessairement également valable et même pire pour systemd qui aurait tout un tas de combinaisons suppléméntaires à traiter puisqu'il tente de traiter tous les cas.
La différence est qu'il tente de traiter les cas proprement, pas en ajoutant une solution ad-hoc à un endroit improbable.
Tous les arguments que tu peux employer contre init et une poignée de scripts bien pensés
Ah, les scripts shell bien pensés. Ceux qui s'écrivent avec une corne de licorne sur du papier fait à base d'écorce d'Yggdrasil.
Tu te rends bien compte qu'un serveur down en prod
Tu te rends bien compte que si tu as un serveur en prod, tu n'es pas censé bricoler des scripts d'init ?
Doug713705 , dans le message <pb1t2q$mt6$1@golgoth99.redatomik.org>, a
écrit :
C'est un outil documenté de longue date.
Les capacités et limites en sont connues depuis longtemps et il est
Oui. On sait depuis longtemps à quel point le shell est casse-figure.
Enfin, ceux qui réfléchissent à ce genre de choses le savent. Les autres
se cassent la figure, et parfois ne s'en rendent même pas compte.
employé avec succès depuis des lustres.
Oui. Et surtout employé avec échec depuis des lustres.
Les mecs ne savent pas coder en shell et voudrait coder from scratch
un init complet /o
Exactement.
N'importe quoi, ce n'est pas systématiquement le cas.
Potentiellement si.
Et si ça l'était ce serait nécessairement également valable et même
pire pour systemd qui aurait tout un tas de combinaisons suppléméntaires
à traiter puisqu'il tente de traiter tous les cas.
La différence est qu'il tente de traiter les cas proprement, pas en
ajoutant une solution ad-hoc à un endroit improbable.
Tous les arguments que tu peux employer contre init et une poignée de
scripts bien pensés
Ah, les scripts shell bien pensés. Ceux qui s'écrivent avec une corne de
licorne sur du papier fait à base d'écorce d'Yggdrasil.
Tu te rends bien compte qu'un serveur down en prod
Tu te rends bien compte que si tu as un serveur en prod, tu n'es pas
censé bricoler des scripts d'init ?
Doug713705 , dans le message <pb1t2q$mt6$, a écrit :
C'est un outil documenté de longue date. Les capacités et limites en sont connues depuis longtemps et il est
Oui. On sait depuis longtemps à quel point le shell est casse-figure. Enfin, ceux qui réfléchissent à ce genre de choses le savent. Les autres se cassent la figure, et parfois ne s'en rendent même pas compte.
employé avec succès depuis des lustres.
Oui. Et surtout employé avec échec depuis des lustres.
Les mecs ne savent pas coder en shell et voudrait coder from scratch un init complet /o
Exactement.
N'importe quoi, ce n'est pas systématiquement le cas.
Potentiellement si.
Et si ça l'était ce serait nécessairement également valable et même pire pour systemd qui aurait tout un tas de combinaisons suppléméntaires à traiter puisqu'il tente de traiter tous les cas.
La différence est qu'il tente de traiter les cas proprement, pas en ajoutant une solution ad-hoc à un endroit improbable.
Tous les arguments que tu peux employer contre init et une poignée de scripts bien pensés
Ah, les scripts shell bien pensés. Ceux qui s'écrivent avec une corne de licorne sur du papier fait à base d'écorce d'Yggdrasil.
Tu te rends bien compte qu'un serveur down en prod
Tu te rends bien compte que si tu as un serveur en prod, tu n'es pas censé bricoler des scripts d'init ?
Doug713705
Le 16-04-2018, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5ad47c53$0$5218$) :
Tu te rends bien compte qu'un serveur down en prod
Tu te rends bien compte que si tu as un serveur en prod, tu n'es pas censé bricoler des scripts d'init ?
Entendre ça de la part de ceux qui mettent systemd en prod... euh... Tu ne le mets pas au point sur la prod mais une fois au point, oui, tu peux le coller en prod. Ça se fait _tous les jours_ dans la vraie vie. Et bricoler un unit systemd ou un script d'init, je ne vois pas vraiment la différence sauf que l'un des deux plantera pour des raisons indéterminées et indéterminables et pas l'autre. Ah, au fait: https://github.com/systemd/systemd/issues On y trouve quelques perles récentes d'une rare qualité. Ça fout carrément la trouille. De toutes façons nous ne tomberons pas d'accord. Je reconsidérerai systemd quand il sera mûr, d'ici 10 ou 15 ans environ. -- Les partouzeurs de miss métro Patrouillent au fond des souterrains Mais ils rêvent d'être en hélico À s'faire de nèg' et du youpin... H.F. Thiéfaine- 113ème Cigarette Sans Dormir
Le 16-04-2018, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<5ad47c53$0$5218$426a74cc@news.free.fr>) :
Tu te rends bien compte qu'un serveur down en prod
Tu te rends bien compte que si tu as un serveur en prod, tu n'es pas
censé bricoler des scripts d'init ?
Entendre ça de la part de ceux qui mettent systemd en prod... euh...
Tu ne le mets pas au point sur la prod mais une fois au point, oui, tu
peux le coller en prod.
Ça se fait _tous les jours_ dans la vraie vie.
Et bricoler un unit systemd ou un script d'init, je ne vois pas vraiment
la différence sauf que l'un des deux plantera pour des raisons
indéterminées et indéterminables et pas l'autre.
Ah, au fait:
https://github.com/systemd/systemd/issues
On y trouve quelques perles récentes d'une rare qualité. Ça fout
carrément la trouille.
De toutes façons nous ne tomberons pas d'accord.
Je reconsidérerai systemd quand il sera mûr, d'ici 10 ou 15 ans environ.
--
Les partouzeurs de miss métro
Patrouillent au fond des souterrains
Mais ils rêvent d'être en hélico
À s'faire de nèg' et du youpin...
H.F. Thiéfaine- 113ème Cigarette Sans Dormir
Le 16-04-2018, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5ad47c53$0$5218$) :
Tu te rends bien compte qu'un serveur down en prod
Tu te rends bien compte que si tu as un serveur en prod, tu n'es pas censé bricoler des scripts d'init ?
Entendre ça de la part de ceux qui mettent systemd en prod... euh... Tu ne le mets pas au point sur la prod mais une fois au point, oui, tu peux le coller en prod. Ça se fait _tous les jours_ dans la vraie vie. Et bricoler un unit systemd ou un script d'init, je ne vois pas vraiment la différence sauf que l'un des deux plantera pour des raisons indéterminées et indéterminables et pas l'autre. Ah, au fait: https://github.com/systemd/systemd/issues On y trouve quelques perles récentes d'une rare qualité. Ça fout carrément la trouille. De toutes façons nous ne tomberons pas d'accord. Je reconsidérerai systemd quand il sera mûr, d'ici 10 ou 15 ans environ. -- Les partouzeurs de miss métro Patrouillent au fond des souterrains Mais ils rêvent d'être en hélico À s'faire de nèg' et du youpin... H.F. Thiéfaine- 113ème Cigarette Sans Dormir
Nicolas George
Doug713705 , dans le message <pb2f05$tt3$, a écrit :
Je reconsidérerai systemd quand il sera mûr, d'ici 10 ou 15 ans environ.
Et en attendant tu utilises un truc qui a été pourri avant d'être mûr. Cherchez la cohérence.
Doug713705 , dans le message <pb2f05$tt3$1@golgoth99.redatomik.org>, a
écrit :
Je reconsidérerai systemd quand il sera mûr, d'ici 10 ou 15 ans environ.
Et en attendant tu utilises un truc qui a été pourri avant d'être mûr.
Cherchez la cohérence.
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Doug713705 , dans le message <pb1t2q$mt6$, a écrit :
C'est un outil documenté de longue date. Les capacités et limites en sont connues depuis longtemps et il est
Oui. On sait depuis longtemps à quel point le shell est casse-figure. Enfin, ceux qui réfléchissent à ce genre de choses le savent. Les autres se cassent la figure, et parfois ne s'en rendent même pas compte.
Enfin, on voit que tu n'as pas touché à PowerShell™ⓒⓡ ! -- Serge http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 16/04/2018 à 12:35, Nicolas George a écrit :
Doug713705 , dans le message <pb1t2q$mt6$1@golgoth99.redatomik.org>, a
écrit :
C'est un outil documenté de longue date.
Les capacités et limites en sont connues depuis longtemps et il est
Oui. On sait depuis longtemps à quel point le shell est casse-figure.
Enfin, ceux qui réfléchissent à ce genre de choses le savent. Les autres
se cassent la figure, et parfois ne s'en rendent même pas compte.
Enfin, on voit que tu n'as pas touché à PowerShell™ⓒⓡ !
--
Serge http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Doug713705 , dans le message <pb1t2q$mt6$, a écrit :
C'est un outil documenté de longue date. Les capacités et limites en sont connues depuis longtemps et il est
Oui. On sait depuis longtemps à quel point le shell est casse-figure. Enfin, ceux qui réfléchissent à ce genre de choses le savent. Les autres se cassent la figure, et parfois ne s'en rendent même pas compte.
Enfin, on voit que tu n'as pas touché à PowerShell™ⓒⓡ ! -- Serge http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
