Sytoka Modon a écrit 4544 commentaires

En parallèle, il y a un gros boulot sur Jessie pour que tout marche bien ;-)

Ceci dis, la méthode a ses limites. Par exemple, lorsque le paquetage entraîne aussi la libc avec elle vers testing ou plus, personnellement, je ne joue plus ;-)

Je dirais qu'il suffit de faire sa configuration avec un noyau standard puis de faire un 'lsmod' pour avoir la liste des modules utilisées. Ensuite, il faut jouer avec les options du make du noyau pour ne construire que ces modules et dans l'idéal, les mettre en dur et non en module.

Avant scilab n'était pas libre donc n'était pas diffuser dans les distributions. Maintenant, il ne marche plus sur la grande majorité des PC… Je ne sais pas quelle sont les objectifs de l'équipe de développement mais elle aide bien à la diffusion de la plate-forme de python/numpy ;-)

Cela pourrait peut être dépendre de son firmware mais pour la gamme pro-curve, c'est assez récent ;-) Ceci dis, je n'ai pas de 2650 sous la main donc je ne peux pas te dire pour la commande loop-protect.

Sur les derniers procurve, il n'y a pas que le SPF à mettre… Il faut aussi utiliser la commande 'loop-protect'. Perso, je rajoute aussi en plus du 'broadcast-limit' sur les interfaces…

Tu l'as configuré pour le protéger contre les loop car ce n'est pas forcément super bon pour le commutateur.

Autre piste : tu n'aurais pas du 220 sur une terre qui remonte par un port par exemple ?

J'avais des mots clefs constant comme 'nom', 'prénom'… en début de ligne. Je ne voulais pas que connaissant ces mots clefs constant en position, on puisse récupérer une information quelconque. D'où du blabla de longueur aléatoire avant et après. Peut être ce blabla ne servait à rien, peut être pouvait-il servir en cas de bogue de 'protocole'… N'étant pas expert dans le sujet, je me suis dis que cela ne pouvait juste pas faire de mal ;-)

C'est pas un peu tache ta procédure ? Je sais bien que tu taches de bien faire ;-)

Comme dans le journal, certains posts parle de système bancaire, je me souviens avoir conçu un site web il y a plus de 10 ans ou les personnes donnaient leur numéro de carte bleu. Comme nous n'étions pas fanatique de garder cette information dans le serveur de notre laboratoire de recherche (publique), je chiffrais de suite le numéro de la carte ainsi qu'un certain nombre d'information attenant via un clef publique GPG (en prenant soin de mettre une longue séquence ASCII de longueur variable avant et après afin de rendre le truc encore plus compliqué).

La clef privé GPG était sur deux clefs USB dans d'autres bâtiments, sous la responsabilité de comptables. Au final, on n'a heureusement jamais eu le moindre soucis.

Je suis d'accord globalement avec toi. Ceci dis, étant dans un laboratoire de recherche publique, c'est très difficile de participer puisque quasiment tous nos achats passent par des bons de commande et des factures…

Ah ah, tu perds ton pantalon ;-)

Ca vous arrive jamais de décrocher ;-)

Perso ma liste de course, c'est un bout de papier, dos d'enveloppe… plier en 4 dans une poche arrière. Bilan carbone proche de zéro !

Ensuite, je ne connais pas d'autres moyens que l'onduleur

Un transfo d'isolement élimine aussi pas mal de merde. Ceci dis, pour un particulier, cela va revenir plus cher et ne gère pas les coupures de 30s…

Sinon, les onduleurs inertiels ou les piles à combustible ne semblent pas cibler le grand public actuellement ;-(

D'ailleurs je vois que le lien de ton site perso est sur un blogspot

Je devrais effectivement l'enlever car cela fait des années que je n'y vais plus ;-)

Sinon Torvalds a lever son majeur en direction de NVidia et pour avoir rencontrer il y a peu des personnes collaborant avec eux, le geste de Linus les as fait grandement réfléchir (c'est pas pour cela qu'ils ont changé à 180° de direction pour le moment). Ceci dis, le jour ou il y a eu un problème, Linus s'est aussi sorti les doigts de ses moufles et a transcendé git ;-)

La licence CC avec clause non commerciale n'est pas libre. Donc si tu l'utilises, tu es dans le monde des logiciels privateurs. Je me souviens d'un débat il y a pas mal de temps dont la conclusion était que la notion de commercial n'était pas si claire que cela et donc que toute clause portant dessus rendait la chose non libre.

Bilan pour du logiciel libre, en gros GPL, AGPL, LGPL, BSD, MIT, Arstitic Licence (perl) pour du code et pour le reste Free Art License 1.3 (Art Libre).

Plus lent mais plus fiable, le arping…

On doit pouvoir faire simple et rapide sur un petit réseau (sans VLAN) avec un simple fping suivis d'un arp (avec une petite tempo entre les deux…).

Merci pour le FXP que je ne connaissais pas (même si pas normalisé). Ceci dis, il me semble que dans le monde du libre, l'ensemble des mirroirs de fait avec du rsync sur ssh (ou sur rsync).

Pour être honnête, c'est facile de lancer deux serveurs ssh avec deux configurations différentes (et deux ports).

C'est juste qu'il plus correct en français d'employer le mot "chiffrer".

Je suis nul en Français mais il ne me semble pas y avoir vu pendant ma scolarité la notion de plus correcte ;-)

Avec ssh, tu as un beau 'yes' à répondre par exemple la première fois…

Utilisant tant openssh que vsftp, le tout chiffré, tu ne donnes pas d'argument clair sur ta phrase : SFTP est clairement plus avancé, propre et sécurisé, mais ce qui démolie complètement FTPS, c'est qu'il est BIEN PLUS SIMPLE !!!

En pratique, les algo de chiffrement sont les mêmes.

Une question que je me pose, je veux que les utilisateurs toto et titi aient accès au serveur sftp mais n'est pas /bin/bash comme shell sur la machine A mais qu'ils aient /bin/bash sur les autres machines B C D… Sachant que toto et titi sont dans un annuaire LDAP. Par contre, l'utilisateur tutu garde son SHELL /bin/bash partout.

Dans le temps, avec NIS, il était assez simple de changer le SHELL d'un utilisateur sur une machine, avec LDAP et SSSD, pour le moment, je ne sais pas comment faire.

Un accès FTPS permet par exemple de donner un accès fichier sans SHELL à certains utilisateurs.

La technologie évolue… Depuis 25 ans, la virtualisation a intégré un grand nombre de CPU. Avec les containers, avec Xen et KVM, pas mal d'API ont été mis en place pour dialoguer entre les couches de manière performantes. Ce n'est pas du micro noyau mais parfois, cela s'en rapproche. Voire par exemple Qubes : https://wiki.qubes-os.org/

Entre temps aussi, des langages comme Erlang très robuste sur l'aspect multi-tâche du fait de son aspect immutable sont aussi arrivés à maturation. Rust devrait aussi être bien plus robuste que le C la dessus.

Bref, je ne sais pas si le Hurd version 1 sera vraiment un jour autre chose qu'un laboratoire mais ce ne serait pas étonnant d'avoir un jour une version 2 qui reprenne un peu toutes les meilleures idées.

GNU/Linux est libre et en production. Pourquoi vouloir un Hurd en production de suite. Il y a très peu de ressources humaines sur ce projet, laisse les s'amuser dessus ou contribue !