-
saart il y a 5 ans | lien | sur : Les logiciels libres, un instrument pour restaurer une souveraineté numérique de l’Europe
Super ! Vivement la mise en application -_-
-
“Difficile à retenir pour un humain” –> pas beaucoup plus que le premier avec cette méthode justement.
“beaucoup moins robuste” –> 14 charactères, s'ils recouvrent un nombre suffisant de symboles de façon vraiment aléatoire (On est d'accord, ça n'est pas le cas içi, mais faisons un arrondi), c'est bien plus que nécessaire pour être incassable.
Et en plus, il y a hélas beaucoup de sites qui limitent encore la taille maximale des mots de passe.
Bref, les choses sont suffisamment complexes pour que personnellement je déconseille l'utilisation des insultes :).
-
-
“Et pas l'inverse hein !” –> Le plus important de l'histoire…
-
J'hésite entre le rire et les pleurs. De mémoire, une partie de leur com était justement de pousser à ouvrir les développements en IA pour éviter qu'une IA trop dangereuse soit dans les mains d'un seul acteur. Je suppose que ça va si c'est leurs main à eux, les “gentils” ? (Ça ou c'est juste du bullshit de com… )
-
Et bien moi, j'ai trouvé ça très intéressant ^^. Question, il y a plusieurs fois l'action “LOG” (“-j LOG” en tout cas) dans les commandes, mais pas dans la partie “Les différentes actions”; quelle est la différence? Y a-t-il des LOG/DROP, LOG/REJECT et LOG/ACCEPT?
-
Si d'autres se posaient la même question, la réponse se trouve dans la “man iptables-extensions” :
LOG
Turn on kernel logging of matching packets. When this option is set for a rule, the Linux kernel will print some information on all matching packets (like most IP/IPv6 header fields) via the kernel log (where it can be read with dmesg(1) or read in the syslog).
This is a “non-terminating target”, i.e. rule traversal continues at the next rule. So if you want to LOG the packets you refuse, use two separate rules with the same matching criteria, first using target LOG then DROP (or REJECT).
-
Merci pour les fleurs. Et concernant les logs, le principe ici c'est que tout ce qui n'est pas accepté est journalisé. Après, ne pas oublier qu'il s'agit d'une introduction de prise en main qui se veut générale. Pour les détails, il vaut mieux voir la doc écrite par Oskar Andreasson, beaucoup plus assomman^^^^^complète. :o)
-
Le principe est très simple :
- “tu” (la machine) analyses ce qui se passe, en premier… LOG
- et, ensuite “tu” décides de l'action à émettre, souvent du DROP ou du REJECT, et parfois tu peux, en tant qu'administrateur décider de laisser passer les paquets (règles ACCEPT). Cette action très ciblée dépend du besoin…
Car non, les LOG ne servent pas qu'à journaliser ce qui doit être rejeté ou supprimé sans avis. Ils servent à analyser la situation, correspondant à un critère. Ensuite, vient l'action.
-
-
Ah c'est top ca, j'ai les mêmes problemes, sauf qu'au lieu de relancer un script sur server au hasard je me connecte au site web pour telecharger la conf du “serveur recommandé”. A tester!
-
Je ne pense pas que git soit le meilleur outil pour backupper ce genre de choses par contre. Ne serait-ce que parce que le versioning par défault impose de changer tous les mots de passe si on veut changer le mot de passe “master”.
-
Je ne pense pas que git soit le meilleur outil pour backupper ce genre de choses par contre
C'est plus dans une otique de distribution que de backup que git est intégré : même base de mots de passe sur son ordi, tel, tablette, etc. en lecture et écriture (Password Store est, au passage, un super client android).
le versioning par défault impose de changer tous les mots de passe si on veut changer le mot de passe “master”.
Pas sûr de voir ce que tu entends par là ? Les fichiers sont chiffrés avec une (ou des) clé GPG. Dans le cas d'un changement de clé, oui, après le
pass init new-gpg-idl'intégralité des fichiers sera modifié car re-chiffré, mais les mots de passe ne changent pas pour autant.Donc pas de notion de “mot de passe master” c'est juste des fichiers textes tout bêtes, chiffrés, stockés dans un dépôt git si besoin, et un super moteur de fuzzy search pour taper dedans.
-
-
nikaro plus de 5 ans | lien | sur : IBM rachète Red Hat, le numéro un de l'« open source », pour 34 milliards de dollars
[Comment removed by author]
-
En tant qu'ancien IBMer parti il y a peu… Ca me fait assez peur pour RedHat. IBM à l'habitude d'appliquer un rouleau compresseur après un rachat pour “intégrer” le rachat, sauf que bien souvent ça à plus tendance à détruire le rachat qu'autre chose, cf le rachat de Softlayer. En plus IBM c'est un gros mastodonte avec des couches et des couches de bureaucratie et de management inutile voir pénalisante, un peu à l'opposé de ce que j'avais entendu sur redhat.
Après, si on veut être optimiste, il y a pas mal d'effort de la part d'IBM pour essayer de se renouveler, si ça pouvait être RedHat qui infusait à IBM, on est pas à l'abri de bonnes choses.
-
-
IBM est une grosse structure en mal de renouveau, Red Hat est une cash-machine à l'heure actuelle, étant passé de 1, puis 2 puis 3 milliards de dollars de revenus très régulièrement.
-
-
-
-
En allemand, on a un mot qui n'existe pas dans la langue française : kaputtsparen. C'est le fait de faire des économies jusqu'à ce qu'on arrive à un point où l'on casse tout. C'est le genre de truc qui arrive régulièrement lorsqu'une boîte en reprend une autre. À voir ce qui se dit sur les mailing lists, y'a quand-même de la nervosité dans l'air quant à l'avenir des projets communautires.
C'est noté pour les distribs, mais je reste un inconditionnel de CentOS, Debian et Slackware.
-
-
-
-
-
Firefox à 5% ? On n'en était pas ~ à 10% aux dernières nouvelles ?
“Les années 90 constituent pour moi le pinnacle de l’informatique […] Microsoft a imposé Windows presque partout” Huuuuuu x)