Avoir le switch intégré permet de gagner en terme de cables, notamment en cables d'alimentation. Sinon, avoir des ports distincts sur lesquelles on peut brancher plusieurs sous-réeau peut également être intéressant ….
LA latence réseau fait que tu ne pourras pas vraiment déterminer qui a buzzé en premier, à moins d'avoir une synchronisation parfaite entre les horloges des systèmes qui buzzent, et d'envoyer la date de l'evenement dans la réponse pour pouvoir comparer. De plus il n'est pas non plus garanti que les utilisateurs recevront en même temps la possibilité de buzzer au même moment (certains auront peut-être leur interface prete à buzzer avant les autres ) … Donc un système basé sur smartphone et communication réseau ne me parait pas très fiable au premier abord.
quitte à avoir le WAN 2.5, ça serait plus cohérent malgré le WiFi d'avoir un LAN 2.5
C'est aussi ce que je me disais, mais d'un autre côté, quand on regarde comment ça marche aujourd'hui dans un foyer, la plupart des communications passent par wifi. Téléphone, ordinateurs, tablettes, console s de jeu … ça fait pas mal de monde. De ce fait le wifi sur un routeur aujourd'hui doit pouvoir encaisser pas mal de trafic ( il suffit que plusieurs personnes dans le foyer regardent des vidéos sur Netflix, amazon and co en HD, pendant qu'un autre fasse une mise à jour de jeu sur une plate-forme dématérialisée pour que ça monte vite, même si ce n'est pas en permanence que le wifi est sollicité). Je comprends donc le choix du 2.5 Gb côté Wan. Celà dit, je ne pense pas non plus qu'une interface à 2.5 GB côté LAN aurait perturbé le wifi (au pire on doit pouvoir mettre en place de la QOS sur les interfaces s'il y a des problèmes de bande passante sur l'une ou l'autre des interfaces).
Une seule interface LAN ça me parait un peu léger … Initialement je ne comprenais pas pourquoi le WAN à 2.5, et le LAN à 1 GB, mais je n'avais pas pris en compte le wifi. Ceà dit, Si le wifi est capable de gérer correctement les multiples connexions, ça peut être un routeur sympa pour une installation domestique. Et le boitier a l'air sympa …
Oups, désolé, j'avais mal compris le sens de ta phrase (j'ai lu tout en pensant à autre chose) : je pensais que tu considérais tout IPV4 obsolete. Celà dit les notions de classes de réseau n'ont pas encore disparu en pratique dans beaucoup de grosses structures (on les retrouve encore dans des docs …), donc voir ça en cours me parait pas forcément inutile. Pour le token rin je te rejoins, maintenant ça doit être marginal.
Quand on pense que dans les écoles (j'étais en école d'ingénieur dans la fin des années 2000), on nous faisait encore apprendre les classes IPv4 (classes A, B, C, …), les topologies token ring ou en étoile, et plein d'autres trucs obsolètes.
Obsolete ? C'est du second degré ? Un ingé qui postule à un emploi sans connaitre IPV4, perso, je ne prends pas.
Penser que c'est l'affichage d'une commande qui va faire adopter IPV6, c'est juste n'importe quoi. Il y a un tas d'autres raisons qui font qu'IPV6 n'est pas adopté. Et c'est avant tout sur ces raisons qu'il faut agir. Quand un seuil suffisant sera atteint il sera temps de changer les affichages par défaut. A la limite, définir le comportement via une variable d'environnement pour que ceux qui ont besoin de l'IPV6 puisse avoir le comportement qui leur convient, pourquoi pas ….
Par contre, il y a complicité d'un Opérateur quelque part (d'après les échanges sur FRnOG sur le sujet)
C'est évident, et il doit y avoir derrière des histoires de chantage à l'emploi ou interet de l'état à laisser perdurer la situation. Sinon il y a longtemps que toutes ces pratiques seraient interdites.
si le processus parent et le processus enfant n'ont pas le même nom, pkill ne fonctionnera pas. Et en lisant la page man de killal, je ne suis pas sûr non plus que cette commande fonctionne :
-w, --wait
Attendre que tous les processus tués meurent. killall vérifiera une fois par seconde s'il existe encore un processus visé, et ne reviendra que lorsqu'il n'y en aura plus. Notez que killall peut attendre indéfiniment si le signal est ignoré, n'a pas d'effet ou si le processus reste à l'état zombie.
Cette commande indique que la valeur de la variable sera accessible aux processus enfants du processus shell courant.
source : le contenu du fichier passé en paramètre est évalué dans le processus shell courant ( il n'y a pas de sous-shell d'exécuté).
pas besoin de la commande source pour faire un export de variable. En pratique la commande source (ou .) permet par exemple de splitter des scripts shell en plusieurs fichiers sources contenant par exemple des fonctions ( une espèce d'include).
Ceux qui m'ont contactés ne raccrochent même pas .. tout juste s'ils ont attendu ma première réponse. Je leur ai dit "désolé mais je n'ai pas le temps" … ilc continuent. C'est comme ça que j'ai compris que j'avais affaire à un robot et j'ai raccroché.
Il y a aussi des gens avec profil d'ingénieur qui ne "produisent" rien ou peu de choses mesurable, mais qui sont plutôt des "facilitateurs" qui vont aider les autres à produire dans une équipe. Je ne sais pas combien il y en a dans les 10% en question, mais je pense que ce n'est pas négligeable.
C'est normal, c'est du trop haut niveau pour des gens "ordinaires". Il faut faire partie de l'élite pour comprendre (et aparamment je n'en fais pas partie non plus ).
Effectivement, et je ne cmprends pas qu'on se base encore sur ce genre de méthodologie aujourd'hui pour estimer la productiité des ingénieurs logiciels.
Les machines virtuelles (kvm,xen,virtualbox) virtualisent le matériel, les conteneurs (lxc, systemd-nspawn, jails, docker, podman) virtualisent un OS et/ou une application.
Je ne suis pas d'accord avec cette définition. Je peux paraître puriste et chiant, mais je l'assume. Ce n'est pas pour couper le cheveu en 4 par pur plaisir, c'est juste que parler de "virtualisation" pour les deux portent à confusion ( et font que les gens s'y perdent). Tu aurais parlé de virtualisation légère j'aurais peut-être moins tiqué, mais ça reste quand même confus. Je réfère utiliser le terme "technologie d'isolation" (ou autre terme plus générique) qui englobe virtualisation et conteneurisation. Parce que dans l'abolu, les conteneurs, ce n'est pas de la virtualisation mais de l'isolation (un super chroot en quelque sorte).
Ce sont des solutions de virtualisation très légères et qui permettraient de faire tourner un version plus récente de Debian (ou juste un serveur Apache/PHP8 pour Docker) sur le serveur en Jessie.
D'abord, ce ne sont pas des solutions de virtualisation : ce sont des solutions de conteneurisation. Tu vas peut-être dire que c'est la même chose mais en fait non. Il y a une grosse nuance qui fait que dans ce cas ça ne marchera pas forcément.
En effet, contrairement à la virtualisation, ou l'hote et les VMs ont leur propre version de noyau, la conteneurisation partage le noyau de l'hôte avec les conteneurs : de ce fait on ne peut pas faire ce que l'on veut avec les versions d'OS qui tournent dessus. Donc, faire tourner une version d'OS plus récente n'est absolument pas garanti : le système dans ton conteneur peut faire appel a des choses qui ne sont pas implémentées dans le noyau et tu te retrouveras avec des conteneurs instables (ça m'est déjà arrivé avec centos). Dans ce cas précis je pense qu'une VM KVM aura plus de chances de faire tourner correctement un OS plus récent.
Là tu mélanges tout. Le CI/CD et les pratiques de développement, dans ce cas on s'en fiche. C'est un sujet qui peut (et doit) être traité indémendamment de docker.
Pour moi le problème n'est pas là etdans l'absolu je ne suis pas sûr que docker doit la réponse au problème remonté: si le serveur doit rester en debian 8 docker n'aidera pas forcément à régler le problème.
[^] # Re: un buzzer distribyé qui passe par du HTTP(s) ou autre c'est complqué
Posté par totof2000 . En réponse au message Recherche logiciel ou site de buzzers virtuels. Évalué à 3.
le prochain taptempo ? :)
[^] # Re: Je trouve les interfaces réseau un peu limitées pour un routeur ...
Posté par totof2000 . En réponse au lien OpenWRT One, une carte de routeur en licence libre développée pour OpenWRT. Évalué à 4.
Avoir le switch intégré permet de gagner en terme de cables, notamment en cables d'alimentation. Sinon, avoir des ports distincts sur lesquelles on peut brancher plusieurs sous-réeau peut également être intéressant ….
# un buzzer distribyé qui passe par du HTTP(s) ou autre c'est complqué
Posté par totof2000 . En réponse au message Recherche logiciel ou site de buzzers virtuels. Évalué à 4.
LA latence réseau fait que tu ne pourras pas vraiment déterminer qui a buzzé en premier, à moins d'avoir une synchronisation parfaite entre les horloges des systèmes qui buzzent, et d'envoyer la date de l'evenement dans la réponse pour pouvoir comparer. De plus il n'est pas non plus garanti que les utilisateurs recevront en même temps la possibilité de buzzer au même moment (certains auront peut-être leur interface prete à buzzer avant les autres ) … Donc un système basé sur smartphone et communication réseau ne me parait pas très fiable au premier abord.
# Je ne comprends pas la demande ....
Posté par totof2000 . En réponse au message Reformater un fichier asciidoc ?. Évalué à 3.
Que veux-tu dire par " je ne trouve pas de formateur pour nettoyer mes fichiers" ?
[^] # Re: Je trouve les interfaces réseau un peu limitées pour un routeur ...
Posté par totof2000 . En réponse au lien OpenWRT One, une carte de routeur en licence libre développée pour OpenWRT. Évalué à 5.
C'est aussi ce que je me disais, mais d'un autre côté, quand on regarde comment ça marche aujourd'hui dans un foyer, la plupart des communications passent par wifi. Téléphone, ordinateurs, tablettes, console s de jeu … ça fait pas mal de monde. De ce fait le wifi sur un routeur aujourd'hui doit pouvoir encaisser pas mal de trafic ( il suffit que plusieurs personnes dans le foyer regardent des vidéos sur Netflix, amazon and co en HD, pendant qu'un autre fasse une mise à jour de jeu sur une plate-forme dématérialisée pour que ça monte vite, même si ce n'est pas en permanence que le wifi est sollicité). Je comprends donc le choix du 2.5 Gb côté Wan. Celà dit, je ne pense pas non plus qu'une interface à 2.5 GB côté LAN aurait perturbé le wifi (au pire on doit pouvoir mettre en place de la QOS sur les interfaces s'il y a des problèmes de bande passante sur l'une ou l'autre des interfaces).
# Je trouve les interfaces réseau un peu limitées pour un routeur ...
Posté par totof2000 . En réponse au lien OpenWRT One, une carte de routeur en licence libre développée pour OpenWRT. Évalué à 4. Dernière modification le 02 décembre 2024 à 12:28.
Une seule interface LAN ça me parait un peu léger … Initialement je ne comprenais pas pourquoi le WAN à 2.5, et le LAN à 1 GB, mais je n'avais pas pris en compte le wifi. Ceà dit, Si le wifi est capable de gérer correctement les multiples connexions, ça peut être un routeur sympa pour une installation domestique. Et le boitier a l'air sympa …
[^] # Re: Cet argument est ridicule ....
Posté par totof2000 . En réponse au journal L'IPv6 ce n'est pas pour demain. Évalué à 2.
Oups, désolé, j'avais mal compris le sens de ta phrase (j'ai lu tout en pensant à autre chose) : je pensais que tu considérais tout IPV4 obsolete. Celà dit les notions de classes de réseau n'ont pas encore disparu en pratique dans beaucoup de grosses structures (on les retrouve encore dans des docs …), donc voir ça en cours me parait pas forcément inutile. Pour le token rin je te rejoins, maintenant ça doit être marginal.
[^] # Re: Cet argument est ridicule ....
Posté par totof2000 . En réponse au journal L'IPv6 ce n'est pas pour demain. Évalué à 1.
Obsolete ? C'est du second degré ? Un ingé qui postule à un emploi sans connaitre IPV4, perso, je ne prends pas.
# Cet argument est ridicule ....
Posté par totof2000 . En réponse au journal L'IPv6 ce n'est pas pour demain. Évalué à 5.
Penser que c'est l'affichage d'une commande qui va faire adopter IPV6, c'est juste n'importe quoi. Il y a un tas d'autres raisons qui font qu'IPV6 n'est pas adopté. Et c'est avant tout sur ces raisons qu'il faut agir. Quand un seuil suffisant sera atteint il sera temps de changer les affichages par défaut. A la limite, définir le comportement via une variable d'environnement pour que ceux qui ont besoin de l'IPV6 puisse avoir le comportement qui leur convient, pourquoi pas ….
[^] # Re: Quelques réponses
Posté par totof2000 . En réponse au journal Les pratiques du sondage dans le libre. Évalué à 5.
Ce commentaire a pour intéret de préciser un peu la question initiale, qui était assez vague. Il manque pas mal de contexte dans le post initial.
# il y a bien des sondages sur linuxfr mais ...
Posté par totof2000 . En réponse au journal Les pratiques du sondage dans le libre. Évalué à 5.
je ne suis pas sûr que ces sondages soient réellement à prendre au sérieux, ni même représentatifs de quoi que ce soit … :)
[^] # Re: Pourquoi c'est si compliqué ?
Posté par totof2000 . En réponse au journal Démarchage robotisé. Évalué à 6.
C'est évident, et il doit y avoir derrière des histoires de chantage à l'emploi ou interet de l'état à laisser perdurer la situation. Sinon il y a longtemps que toutes ces pratiques seraient interdites.
[^] # Re: World War Z
Posté par totof2000 . En réponse au message Création d’un script . Évalué à 2.
si le processus parent et le processus enfant n'ont pas le même nom, pkill ne fonctionnera pas. Et en lisant la page man de killal, je ne suis pas sûr non plus que cette commande fonctionne :
# c'est le propre des processus zombies ....
Posté par totof2000 . En réponse au message Création d’un script . Évalué à 2. Dernière modification le 29 novembre 2024 à 16:42.
ils ne peuvent être tués car ils ne sont ni vivants, ni complêtement morts, d'ou leur nom … :)
Explications sur wikipedia
# ne pas confondre source (ou '.') et export
Posté par totof2000 . En réponse au message Besoin d'un petit cours sur export dans un script bash. Évalué à 2.
export mavariable
Cette commande indique que la valeur de la variable sera accessible aux processus enfants du processus shell courant.
source : le contenu du fichier passé en paramètre est évalué dans le processus shell courant ( il n'y a pas de sous-shell d'exécuté).
pas besoin de la commande source pour faire un export de variable. En pratique la commande source (ou .) permet par exemple de splitter des scripts shell en plusieurs fichiers sources contenant par exemple des fonctions ( une espèce d'include).
[^] # Re: Si tu coupes la parole
Posté par totof2000 . En réponse au journal Démarchage robotisé. Évalué à 5.
Ceux qui m'ont contactés ne raccrochent même pas .. tout juste s'ils ont attendu ma première réponse. Je leur ai dit "désolé mais je n'ai pas le temps" … ilc continuent. C'est comme ça que j'ai compris que j'avais affaire à un robot et j'ai raccroché.
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par totof2000 . En réponse au lien Ingénieur logiciel : un métier de feignasse ? :). Évalué à 2.
ce sont ceux qui ne croient qu'au mythe du nombre de commits pour mesurer leur productivité ?
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par totof2000 . En réponse au lien Ingénieur logiciel : un métier de feignasse ? :). Évalué à 3.
Comment le mesurer concretement, autre qu'à postériori, par l'absence de la personne en question ?
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par totof2000 . En réponse au lien Ingénieur logiciel : un métier de feignasse ? :). Évalué à 2.
j'aurais plutôt dit "C'est pas faux !!!"
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par totof2000 . En réponse au lien Ingénieur logiciel : un métier de feignasse ? :). Évalué à 3.
Il y a aussi des gens avec profil d'ingénieur qui ne "produisent" rien ou peu de choses mesurable, mais qui sont plutôt des "facilitateurs" qui vont aider les autres à produire dans une équipe. Je ne sais pas combien il y en a dans les 10% en question, mais je pense que ce n'est pas négligeable.
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par totof2000 . En réponse au lien Ingénieur logiciel : un métier de feignasse ? :). Évalué à 5.
C'est normal, c'est du trop haut niveau pour des gens "ordinaires". Il faut faire partie de l'élite pour comprendre (et aparamment je n'en fais pas partie non plus ).
[^] # Re: Ça ne fait aucun doute ! (je sors)
Posté par totof2000 . En réponse au lien Ingénieur logiciel : un métier de feignasse ? :). Évalué à 3.
Effectivement, et je ne cmprends pas qu'on se base encore sur ce genre de méthodologie aujourd'hui pour estimer la productiité des ingénieurs logiciels.
[^] # Re: systemd-nspawn
Posté par totof2000 . En réponse au message PHP 8 sur un serveur Debian 8 (jessie) ?. Évalué à 4.
Je ne suis pas d'accord avec cette définition. Je peux paraître puriste et chiant, mais je l'assume. Ce n'est pas pour couper le cheveu en 4 par pur plaisir, c'est juste que parler de "virtualisation" pour les deux portent à confusion ( et font que les gens s'y perdent). Tu aurais parlé de virtualisation légère j'aurais peut-être moins tiqué, mais ça reste quand même confus. Je réfère utiliser le terme "technologie d'isolation" (ou autre terme plus générique) qui englobe virtualisation et conteneurisation. Parce que dans l'abolu, les conteneurs, ce n'est pas de la virtualisation mais de l'isolation (un super chroot en quelque sorte).
[^] # Re: systemd-nspawn
Posté par totof2000 . En réponse au message PHP 8 sur un serveur Debian 8 (jessie) ?. Évalué à 5. Dernière modification le 24 novembre 2024 à 12:06.
D'abord, ce ne sont pas des solutions de virtualisation : ce sont des solutions de conteneurisation. Tu vas peut-être dire que c'est la même chose mais en fait non. Il y a une grosse nuance qui fait que dans ce cas ça ne marchera pas forcément.
En effet, contrairement à la virtualisation, ou l'hote et les VMs ont leur propre version de noyau, la conteneurisation partage le noyau de l'hôte avec les conteneurs : de ce fait on ne peut pas faire ce que l'on veut avec les versions d'OS qui tournent dessus. Donc, faire tourner une version d'OS plus récente n'est absolument pas garanti : le système dans ton conteneur peut faire appel a des choses qui ne sont pas implémentées dans le noyau et tu te retrouveras avec des conteneurs instables (ça m'est déjà arrivé avec centos). Dans ce cas précis je pense qu'une VM KVM aura plus de chances de faire tourner correctement un OS plus récent.
[^] # Re: systemd-nspawn
Posté par totof2000 . En réponse au message PHP 8 sur un serveur Debian 8 (jessie) ?. Évalué à 2.
Là tu mélanges tout. Le CI/CD et les pratiques de développement, dans ce cas on s'en fiche. C'est un sujet qui peut (et doit) être traité indémendamment de docker.
Pour moi le problème n'est pas là etdans l'absolu je ne suis pas sûr que docker doit la réponse au problème remonté: si le serveur doit rester en debian 8 docker n'aidera pas forcément à régler le problème.