Bah, à moins d’être une assoc ou une PME sans le sou, pourquoi tu ne pourrais pas payer pour avoir du support à long terme ?
Je parle du projet qui fournit la distrib. Si Centos était maintenu par une petite entreprise qui souffre en raison du covid, je serais plus compréhensif sur l'abandon subit du support. Dans le cas de Redhat qui de toute façon produit les sources pour sa distrib, maintient le tooling, ce n'est pas vraiment excusable.
sans mise à jour pendant 10 ans
Il est mis à jour d'un point de vue sécurité. Pour une entreprise qui fournit un logiciel et veut fournir du support, c'est intéressant de pouvoir supporter des distrib qui ne varie quasi pas pendant 10 ans. Et l'existence de centos permet de ne pas imposer à ses clients une distrib coûteuse, d'autant plus si le support de la distrib est plus cher que l'appli elle-même.
Du reste il existe de nombreux types de fonctionnement d'entreprise mais dans tous les cas la séparation des responsabilités est toujours un point compliqué. Les sysadmins voudraient pouvoir mettre à jour et rebooter les serveurs quand ils veulent, les gestionnaires d'applications voudraient que rien ne change sans leur accord. C'est un point en partie résolu avec l'usage des solutions de containers, de distribs types atomiques, de séparation des packages OS et applis mais tous les types d'organisations/applications ne le supportent bien et une distrib à support long terme comme ubuntu LTS, RHEL ou Centos permet aux sysadmins de dire : regardez, on vous fournit ce serveur et pendant 10 ans on garde cet accord que chaque premier jeudi du mois on peut mettre à jour vos noeuds #1 de vos cluster serveurs et le rebooter à 3h du matin et les noeuds #2 le jeudi suivant. Le gestionnaire d'appli est content, il n'a pas à tout tester pour chaque version de noyau/librairies x ou y comme il devrait le faire sur un Rolling Release et il n'est pas obligé de migrer de serveur tous les 2-3 ans parce que la distro ne sera plus supporter.
Quand tu gères 10 serveurs dans ton coin, c'est pas la mer à boire de migrer tous les 2 ans. Quand tu en as 1000-2000 t'es content si tu peux étaler les différentes campagnes de migrations entre les n équipes/clients tiers.
je pense que l'incompréhension vient du terme faille. Un Dos est un problème de sécurité mais ce n'est pas une faille qui permet de faire de la pénetration.
Ce qui est moche, c'est pas de migrer vers une rolling release. Ce qui est moche, c'est d'avoir sorti en 2019 la centos-8 en parrallèle avec la centos-stream et d'avoir annoncé qu'elle serait supporté jusqu'en 2029. Pour dire 1 an et 3 mois après quand de nombreuses entités/entreprises ont déjà lancé des campagnes de migrations que en fait non, l'année prochaine on coupe le support sauf si vous migrez vers la rolling-release.
Ils auraient très bien pu annoncer ce changement avant de sortir la 8, ou de la sortir avec un support à 2 ou 5 ans mais en l'annonçant dès le début, ou décider de continuer comme défini jusqu'à 2029 mais en précisant qu'il n'y aurait pas de version 9.
Ça c'est franchement malhonnête et normalement digne d'Oracle, pas de RedHat.
D'abord il suffit de voir la quantité de Debian dans la nature pour des fonctions similaires à CentOS pour se convaincre que ce n'est pas une catastrophe même pour des systèmes importants
L'intérêt c'était le support long terme. Une debian tu dois faire une upgrade de version majeure régulière quand tu peux utiliser la même RHEL/centos pendant 10 ans sans risque de rien casser. Les seules réelles alternatives à du RHEL based quand on veut des versions figées avec autant d'années de support c'est ubuntu LTS.
Le principe est le même quelque soit le type de noyau, supprimer tout support matériel autre que les éléments virtualisés et éventuellement bypasser l'ordonnanceur typique pour ne lancer que l'executable demandé.
Il n'y a pas forcément besoin de recréer un OS ou forker un OS existant.
Je sais que tout ce qui repose sur un support communautaire n'a aucune garantie, mais quand tu annonces au monde entier que tu produit une distro dédiée aux entreprises avec un support jusqu'en 2029, il faut vraiment être une bande de ̶m̶a̶n̶a̶g̶e̶r̶s̶ ̶I̶B̶M̶ connards pour avancer la fin de support à la fin de l'année prochaine quand tu sais que des milliers d'institutions utilises ton projet en toute confiance et sont dans des gros projets de migration centos7 --> centos8.
À moins d'être une petite assoce ou pme sans le sou, tu gardes au moins le support pour la dernière release annoncée et fait le switch pour la suivante.
Si IBM/Redhat se met à adopter les techniques de ventes de Oracle on est bien mal. On avait quelques projets basés sur du RH/RHVM, je ne suis plus sûr de vouloir m'embarquer pour du support pour des produits RH maintenant…
J'imagine que pour une grande partie, l'intérêt d'un pilote libre est son intégration au noyau qui garantie en grande partie que rien ne va casser en cas de mise à jour du noyau, une installation de l'os facile car sans manipulation manuelle et mise à jour du driver graphique automatique sans manipulation particulière.
Faux. Ces "versions" ne sont que des pointeurs sur Manjaro à un moment de son histoire pour produire des isos avec des sélections de paquet mais ça reste une rolling release. Quand tu mets à jour tes paquets, elle ne reste pas figée à une version comme le sont par exemple les distros basées sur debian ou redhat pour lesquels tu fais pointer ton gestionnaire de paquet sur un arbre des paquets dédié à une version spécifique et qui nécessitent l'application d'un processus d'upgrade de version pour passer à une version supérieure.
tu installes aurorastore et tu as accès aux applis du playstore.
Accesoirement blissos fournit le playstore.
Après si tu vis sans mobile, sans fixe, sans électricité, tu vas pas non plus te plaindre si tu ne peux pas faire tes paiements en ligne via ton routeur alimenté à l'électricité par une chaudière à vapeur sans te déplacer à dos de mule jusqu'à ta banque.
Pas besoin de smartphone pour avoir android. Il peut tourner sur un PC, une VM, il est possible d'utiliser Android Virtual Device (de Android Studio), ou via anbox sur ta distrib.
Du reste on peut faire demander un virement à sa banque sur demande écrite. En général ils te rappellent pour confirmer et demander des détails personnels pour prouver ton identité mais ça peut être un numéro fixe.
Si tu peux assigner à une VM le disque d'une autre VM (pourvu que cette autre VM est éteinte).
C'est assez goret, ça sort un peu des bonnes pratiques et je dirais que ça n'a d'intérêt que temporairement pour une migration de données mais c'est possible.
longhorn a t-il gagné en maturité ? La dernière fois que j'ai regardé les perfs étaient franchement pas top et il ne supportait pas certains truc basiques comme les redimenssionnements de volumes.
EDIT: je me réponds à moi même après avoir revisité longhorn.io, à priori pour le second point c'est en tout cas réglé.
C'est pas parce qu'il n'y a pas de csi pour ton système d'hypervision que t'es obligé d'utiliser ceph. Chez nous on fait tourner kubernetes sur du vmware mais on n'a pas utilisé leur csi car au moment où on l'avait évalué il ne supportait pas les redimenssionnements online. Du coup on utilise le csi trident pour les baies netapp directement qui était bien plus mature il y a déjà deux ans.
D'ailleurs c'est pas totalement idiot de décoreller csi/stockage du système d'hypervision. On avait commencé à utiliser kubernetes sur du bare-metal pour migrer sur du vmware, essentiellement par tranquilité lors des mises à jours de cluster via les reboots de vm plus rapides et le csi lié à un stockage externe nous a permis de faire ça de façon transparente. Et si un jour on veut décider de changer de système d'hypervision (on réfléchit à RHV actuellement), on le peut de façon complète ou partielle, et en tout cas progressivement. Idem si on voulait réutiliser du bare-metal pour des workloads particuliers.
Openshift est décorellé de la gestion des vms. Quand tu demandes à un consultant Redhat de te proposer une archi openshift il va te proposer de faire tourner ça sur du RHV ou si tu as déjà du vmware sur du vmware. Au final tu dois aussi "tout configurer à la main".
VMWare Tanzu, c'est pas juste une coche que t'actives dans ton environnement vsphere. C'est tout une suite de produits que tu dois installer par dessus.
L'expérience a montré que quand un sales-ingineer te vend une "intégration" poussée entre 2 produits, il y a souvent derrière une montagnes de trucs à faire et dans de nombre cas des manques importants qui font que ce n'est pas aussi bien intégré que le whitepaper ne pourrait le faire penser.
Rancher est sympa car il peut te configurer tes VMS automatiquement mais au final le provisionning des VMs n'est pas vraiment la tâche la plus compliquée et ça peut se faire dans proxmox via ansible ou terraform.
Note: je n'ai aucun part dans proxmox et ne l'utilise pas en prod.
J'ai pris trop de temps à éditer mon commentaire plus haut. Il y a pas mal de gens qui gueulent après le support de lastpass, donc on est loin d'être en présence d'une Rolls non plus. La seule fonctionnalité que j'ai lu qui m'intéresserait, mais j´ai vu en parler dans des forums/mailing lists bitwarden donc peut-être que ça va venir, c'est la possibilité de notifier quelqu'un et donner accès au password après n mois sans activité. Par exemple pour qu'un proche puisse avoir accès à tes comptes après ton décès (oui je vieillis, je commence à y penser).
Mais sinon bitwarden est clairement le plus proche de lastpass en terme de philosophie (hébergement distant) et il y a pas mal de success stories de gens qui ont migré vers lui depuis lastpass.
Sinon keepass et la plupart des ses clients compatibles sont libre. Il n'a pas pour but de gérer la synchro, le stockage distant mais certains clients le font (nexcloud). Il y a des extensions pour les navigateurs principaux. Via keeshare on peut partager des mots de passes, et rien n'empêche d´avoir son keepass sur un hébergement dans le cloud/dropbox/webdav/sftp/stockageobjet.
Sinon avec CozyCloud il y a aussi un password manager, très basique (il stocke, il génère, il est ). Pour l'usage personnel de quelqu'un qui n'a pas besoin de fonctions de partages ou plus avancés, c'est suffisant.
Quand tu fais une mise à jour de packages, notemment sur du rolling release, on parle rarement de GB mais de MB de différences. Il n'y a que sur une dist-upgrade que tu peux compter ça en gigas.
Du reste quand tu as plusieurs snapshots tu n'as que la différence incrémentale entre les snapshots à stocker, pas à chaque fois la différence totale avec l'état actuel.
[^] # Re: NixOS
Posté par Psychofox (Mastodon) . En réponse à la dépêche CentOS se saborde‑t‑elle ?. Évalué à 8.
Indépendemment des spécificités techniques des distribs, le choix est parfois directement lié à l'achat d'une licence ou du support d'un logiciel.
[^] # Re: L'art et la manière
Posté par Psychofox (Mastodon) . En réponse au lien CentOS Project shifts focus to CentOS Stream. Évalué à 8.
Je parle du projet qui fournit la distrib. Si Centos était maintenu par une petite entreprise qui souffre en raison du covid, je serais plus compréhensif sur l'abandon subit du support. Dans le cas de Redhat qui de toute façon produit les sources pour sa distrib, maintient le tooling, ce n'est pas vraiment excusable.
Il est mis à jour d'un point de vue sécurité. Pour une entreprise qui fournit un logiciel et veut fournir du support, c'est intéressant de pouvoir supporter des distrib qui ne varie quasi pas pendant 10 ans. Et l'existence de centos permet de ne pas imposer à ses clients une distrib coûteuse, d'autant plus si le support de la distrib est plus cher que l'appli elle-même.
Du reste il existe de nombreux types de fonctionnement d'entreprise mais dans tous les cas la séparation des responsabilités est toujours un point compliqué. Les sysadmins voudraient pouvoir mettre à jour et rebooter les serveurs quand ils veulent, les gestionnaires d'applications voudraient que rien ne change sans leur accord. C'est un point en partie résolu avec l'usage des solutions de containers, de distribs types atomiques, de séparation des packages OS et applis mais tous les types d'organisations/applications ne le supportent bien et une distrib à support long terme comme ubuntu LTS, RHEL ou Centos permet aux sysadmins de dire : regardez, on vous fournit ce serveur et pendant 10 ans on garde cet accord que chaque premier jeudi du mois on peut mettre à jour vos noeuds #1 de vos cluster serveurs et le rebooter à 3h du matin et les noeuds #2 le jeudi suivant. Le gestionnaire d'appli est content, il n'a pas à tout tester pour chaque version de noyau/librairies x ou y comme il devrait le faire sur un Rolling Release et il n'est pas obligé de migrer de serveur tous les 2-3 ans parce que la distro ne sera plus supporter.
Quand tu gères 10 serveurs dans ton coin, c'est pas la mer à boire de migrer tous les 2 ans. Quand tu en as 1000-2000 t'es content si tu peux étaler les différentes campagnes de migrations entre les n équipes/clients tiers.
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par Psychofox (Mastodon) . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 2. Dernière modification le 09 décembre 2020 à 14:54.
je pense que l'incompréhension vient du terme faille. Un Dos est un problème de sécurité mais ce n'est pas une faille qui permet de faire de la pénetration.
[^] # Re: pourquoi ?
Posté par Psychofox (Mastodon) . En réponse à la dépêche CentOS se saborde‑t‑elle ?. Évalué à 10. Dernière modification le 09 décembre 2020 à 14:53.
Ce qui est moche, c'est pas de migrer vers une rolling release. Ce qui est moche, c'est d'avoir sorti en 2019 la centos-8 en parrallèle avec la centos-stream et d'avoir annoncé qu'elle serait supporté jusqu'en 2029. Pour dire 1 an et 3 mois après quand de nombreuses entités/entreprises ont déjà lancé des campagnes de migrations que en fait non, l'année prochaine on coupe le support sauf si vous migrez vers la rolling-release.
Ils auraient très bien pu annoncer ce changement avant de sortir la 8, ou de la sortir avec un support à 2 ou 5 ans mais en l'annonçant dès le début, ou décider de continuer comme défini jusqu'à 2029 mais en précisant qu'il n'y aurait pas de version 9.
Ça c'est franchement malhonnête et normalement digne d'Oracle, pas de RedHat.
[^] # Re: À voir en vrai
Posté par Psychofox (Mastodon) . En réponse à la dépêche CentOS se saborde‑t‑elle ?. Évalué à 10. Dernière modification le 09 décembre 2020 à 13:50.
L'intérêt c'était le support long terme. Une debian tu dois faire une upgrade de version majeure régulière quand tu peux utiliser la même RHEL/centos pendant 10 ans sans risque de rien casser. Les seules réelles alternatives à du RHEL based quand on veut des versions figées avec autant d'années de support c'est ubuntu LTS.
[^] # Re: Pourquoi ?
Posté par Psychofox (Mastodon) . En réponse au journal Échanges avec le support technique de Paypal concernant l'authentification à deux facteurs. Évalué à -2.
Ben tu changes de banque ou tu fais toutes tes opérations au guichet.
[^] # Re: Pas de pilotes...
Posté par Psychofox (Mastodon) . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 5.
@imil a fait une démonstration de comment le faire à partir d'une netbsd:
https://imil.net/blog/posts/2020/fakecracker-netbsd-as-a-function-based-microvm/
Le principe est le même quelque soit le type de noyau, supprimer tout support matériel autre que les éléments virtualisés et éventuellement bypasser l'ordonnanceur typique pour ne lancer que l'executable demandé.
Il n'y a pas forcément besoin de recréer un OS ou forker un OS existant.
# L'art et la manière
Posté par Psychofox (Mastodon) . En réponse au lien CentOS Project shifts focus to CentOS Stream. Évalué à 8. Dernière modification le 09 décembre 2020 à 09:44.
Je sais que tout ce qui repose sur un support communautaire n'a aucune garantie, mais quand tu annonces au monde entier que tu produit une distro dédiée aux entreprises avec un support jusqu'en 2029, il faut vraiment être une bande de ̶m̶a̶n̶a̶g̶e̶r̶s̶ ̶I̶B̶M̶ connards pour avancer la fin de support à la fin de l'année prochaine quand tu sais que des milliers d'institutions utilises ton projet en toute confiance et sont dans des gros projets de migration centos7 --> centos8.
À moins d'être une petite assoce ou pme sans le sou, tu gardes au moins le support pour la dernière release annoncée et fait le switch pour la suivante.
Si IBM/Redhat se met à adopter les techniques de ventes de Oracle on est bien mal. On avait quelques projets basés sur du RH/RHVM, je ne suis plus sûr de vouloir m'embarquer pour du support pour des produits RH maintenant…
[^] # Re: Drivers libres pour faire tourner des logiciels fermés ?
Posté par Psychofox (Mastodon) . En réponse au journal Ma vie de joueur : mes retrouvailles avec AMD après 10 ans d'absence.. Évalué à 5.
J'imagine que pour une grande partie, l'intérêt d'un pilote libre est son intégration au noyau qui garantie en grande partie que rien ne va casser en cas de mise à jour du noyau, une installation de l'os facile car sans manipulation manuelle et mise à jour du driver graphique automatique sans manipulation particulière.
[^] # Re: Les mots ont un sens
Posté par Psychofox (Mastodon) . En réponse au journal Les rollbacks avec Manjaro, Btrs et Timeshift. Évalué à 7. Dernière modification le 06 décembre 2020 à 12:29.
Faux. Ces "versions" ne sont que des pointeurs sur Manjaro à un moment de son histoire pour produire des isos avec des sélections de paquet mais ça reste une rolling release. Quand tu mets à jour tes paquets, elle ne reste pas figée à une version comme le sont par exemple les distros basées sur debian ou redhat pour lesquels tu fais pointer ton gestionnaire de paquet sur un arbre des paquets dédié à une version spécifique et qui nécessitent l'application d'un processus d'upgrade de version pour passer à une version supérieure.
[^] # Re: Pourquoi ?
Posté par Psychofox (Mastodon) . En réponse au journal Échanges avec le support technique de Paypal concernant l'authentification à deux facteurs. Évalué à -3. Dernière modification le 04 décembre 2020 à 23:30.
tu installes aurorastore et tu as accès aux applis du playstore.
Accesoirement blissos fournit le playstore.
Après si tu vis sans mobile, sans fixe, sans électricité, tu vas pas non plus te plaindre si tu ne peux pas faire tes paiements en ligne via ton routeur alimenté à l'électricité par une chaudière à vapeur sans te déplacer à dos de mule jusqu'à ta banque.
[^] # Re: Pourquoi ?
Posté par Psychofox (Mastodon) . En réponse au journal Échanges avec le support technique de Paypal concernant l'authentification à deux facteurs. Évalué à 1. Dernière modification le 04 décembre 2020 à 15:32.
Et accessoirement je crois que la plupart des opérateurs fixes ont toujours le robot qui te dicte tes sms.
[^] # Re: Pourquoi ?
Posté par Psychofox (Mastodon) . En réponse au journal Échanges avec le support technique de Paypal concernant l'authentification à deux facteurs. Évalué à 0. Dernière modification le 04 décembre 2020 à 15:26.
Pas besoin de smartphone pour avoir android. Il peut tourner sur un PC, une VM, il est possible d'utiliser Android Virtual Device (de Android Studio), ou via anbox sur ta distrib.
Du reste on peut faire demander un virement à sa banque sur demande écrite. En général ils te rappellent pour confirmer et demander des détails personnels pour prouver ton identité mais ça peut être un numéro fixe.
[^] # Re: Pourquoi ?
Posté par Psychofox (Mastodon) . En réponse au journal Échanges avec le support technique de Paypal concernant l'authentification à deux facteurs. Évalué à 1. Dernière modification le 04 décembre 2020 à 11:51.
Tu n'est pas obligé d'utiliser opencollective, donc tu as le choix ou non d'utiliser paypal.
En général on peut toujours payer via une mastercard/visa ou virement bancaire. Et ça ne coûte pas plus cher que paypal.
[^] # Re: Comparaison avec VMWARE
Posté par Psychofox (Mastodon) . En réponse à la dépêche Sortie de Proxmox VE 6.3. Évalué à 2. Dernière modification le 04 décembre 2020 à 07:39.
Si tu peux assigner à une VM le disque d'une autre VM (pourvu que cette autre VM est éteinte).
C'est assez goret, ça sort un peu des bonnes pratiques et je dirais que ça n'a d'intérêt que temporairement pour une migration de données mais c'est possible.
[^] # Re: utiliseur gnome
Posté par Psychofox (Mastodon) . En réponse au message F-Droid/LineageOS - Conversion WAV.. Évalué à 2.
J'ai totalement oublié la mention f-droid/lineageos et qu'on ne parlait pas de desktop, désolé pour la réponse hors-sujet.
# utiliseur gnome
Posté par Psychofox (Mastodon) . En réponse au message F-Droid/LineageOS - Conversion WAV.. Évalué à 1. Dernière modification le 03 décembre 2020 à 12:25.
Si tu utilises gnome comme bureau, tu peux faire profit des nautilus scripts.
Par exemple celui-ci : audio-convert
Il nécessite d'avoir les paquets mplayer, zenity, lame, vorbis-tools, id3lib et éventuellement faac/faad2 si tu veux gérer le format aac.
Tu as juste à copier le fichier dans ~/.local/share/nautilus/scripts/ et le rendre executable (chmod +x).
Il est ensuite directement utilisable depuis nautilus/files/fichiers :
J'allais oublier: ça marche aussi en sélectionnant plusieurs fichiers.
Bien entendu avant de télécharger et rendre executable n'importe quel fichier bash, il convient de lire le code et d'analyser ce qu'il fait.
[^] # Re: PVE avec kubernetes
Posté par Psychofox (Mastodon) . En réponse à la dépêche Sortie de Proxmox VE 6.3. Évalué à 2. Dernière modification le 03 décembre 2020 à 10:08.
longhorn a t-il gagné en maturité ? La dernière fois que j'ai regardé les perfs étaient franchement pas top et il ne supportait pas certains truc basiques comme les redimenssionnements de volumes.
EDIT: je me réponds à moi même après avoir revisité longhorn.io, à priori pour le second point c'est en tout cas réglé.
[^] # Re: proxmox et kubernetes
Posté par Psychofox (Mastodon) . En réponse à la dépêche Sortie de Proxmox VE 6.3. Évalué à 3.
C'est pas parce qu'il n'y a pas de csi pour ton système d'hypervision que t'es obligé d'utiliser ceph. Chez nous on fait tourner kubernetes sur du vmware mais on n'a pas utilisé leur csi car au moment où on l'avait évalué il ne supportait pas les redimenssionnements online. Du coup on utilise le csi trident pour les baies netapp directement qui était bien plus mature il y a déjà deux ans.
D'ailleurs c'est pas totalement idiot de décoreller csi/stockage du système d'hypervision. On avait commencé à utiliser kubernetes sur du bare-metal pour migrer sur du vmware, essentiellement par tranquilité lors des mises à jours de cluster via les reboots de vm plus rapides et le csi lié à un stockage externe nous a permis de faire ça de façon transparente. Et si un jour on veut décider de changer de système d'hypervision (on réfléchit à RHV actuellement), on le peut de façon complète ou partielle, et en tout cas progressivement. Idem si on voulait réutiliser du bare-metal pour des workloads particuliers.
[^] # Re: proxmox et kubernetes
Posté par Psychofox (Mastodon) . En réponse à la dépêche Sortie de Proxmox VE 6.3. Évalué à 2. Dernière modification le 02 décembre 2020 à 14:10.
Je crois que c'est un faux problème.
Openshift est décorellé de la gestion des vms. Quand tu demandes à un consultant Redhat de te proposer une archi openshift il va te proposer de faire tourner ça sur du RHV ou si tu as déjà du vmware sur du vmware. Au final tu dois aussi "tout configurer à la main".
VMWare Tanzu, c'est pas juste une coche que t'actives dans ton environnement vsphere. C'est tout une suite de produits que tu dois installer par dessus.
L'expérience a montré que quand un sales-ingineer te vend une "intégration" poussée entre 2 produits, il y a souvent derrière une montagnes de trucs à faire et dans de nombre cas des manques importants qui font que ce n'est pas aussi bien intégré que le whitepaper ne pourrait le faire penser.
Rancher est sympa car il peut te configurer tes VMS automatiquement mais au final le provisionning des VMs n'est pas vraiment la tâche la plus compliquée et ça peut se faire dans proxmox via ansible ou terraform.
Note: je n'ai aucun part dans proxmox et ne l'utilise pas en prod.
[^] # Re: Je suis d'accord pour dépoussiérer tout ça
Posté par Psychofox (Mastodon) . En réponse au lien Lennart revient, cette fois-ci il s'attaque à nos homes !!!. Évalué à 5.
Bof…il oublie un peu vite que le chiffrement de l'entièreté du disque a des intérêts réels.
# manifestement linuxfr aussi
Posté par Psychofox (Mastodon) . En réponse au lien La France a un problème de racisme au sein de ses forces de l’ordre et l'État refuse de le traiter . Évalué à -10. Dernière modification le 28 novembre 2020 à 19:45.
Manifestement linuxfr n'est pas immune et est lui aussi contaminé par la fachosphere.
[^] # Re: Ou si
Posté par Psychofox (Mastodon) . En réponse à la dépêche KeePass, ou apprendre à gérer correctement ses mots de passe. Évalué à 3. Dernière modification le 27 novembre 2020 à 16:22.
J'ai pris trop de temps à éditer mon commentaire plus haut. Il y a pas mal de gens qui gueulent après le support de lastpass, donc on est loin d'être en présence d'une Rolls non plus. La seule fonctionnalité que j'ai lu qui m'intéresserait, mais j´ai vu en parler dans des forums/mailing lists bitwarden donc peut-être que ça va venir, c'est la possibilité de notifier quelqu'un et donner accès au password après n mois sans activité. Par exemple pour qu'un proche puisse avoir accès à tes comptes après ton décès (oui je vieillis, je commence à y penser).
Mais sinon bitwarden est clairement le plus proche de lastpass en terme de philosophie (hébergement distant) et il y a pas mal de success stories de gens qui ont migré vers lui depuis lastpass.
Sinon keepass et la plupart des ses clients compatibles sont libre. Il n'a pas pour but de gérer la synchro, le stockage distant mais certains clients le font (nexcloud). Il y a des extensions pour les navigateurs principaux. Via keeshare on peut partager des mots de passes, et rien n'empêche d´avoir son keepass sur un hébergement dans le cloud/dropbox/webdav/sftp/stockageobjet.
Sinon avec CozyCloud il y a aussi un password manager, très basique (il stocke, il génère, il est ). Pour l'usage personnel de quelqu'un qui n'a pas besoin de fonctions de partages ou plus avancés, c'est suffisant.
En libre et hébergeable, il existe aussi syspass.
[^] # Re: Ou si
Posté par Psychofox (Mastodon) . En réponse à la dépêche KeePass, ou apprendre à gérer correctement ses mots de passe. Évalué à 2.
bitwarden est libre.
[^] # Re: à chacun sa vision de la simplicité
Posté par Psychofox (Mastodon) . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. Évalué à 2.
Quand tu fais une mise à jour de packages, notemment sur du rolling release, on parle rarement de GB mais de MB de différences. Il n'y a que sur une dist-upgrade que tu peux compter ça en gigas.
Du reste quand tu as plusieurs snapshots tu n'as que la différence incrémentale entre les snapshots à stocker, pas à chaque fois la différence totale avec l'état actuel.