AgileBits fournit déjà la nouvelle mouture pour Linux et Windows, tandis que celle pour macOS est encore en bêta. Plusieurs changements notables sont présents, dont certains ne feront pas plaisir.
D’abord parce qu'un abonnement est désormais imposé, à partir de 2,99 dollars par mois. Les clients ayant acheté la licence perpétuelle de la version 7 peuvent demander une ristourne de 50 % sur les trois premières années d’abonnement.
Ensuite, bien que l’application soit écrite en Rust pour l’essentiel, elle repose aussi sur Electron pour tout ce qui touche à l’interface. Et comme l’a pointé MacGeneration, les premiers retours sur sa consommation en mémoire vive et son poids ne sont guère élogieux. Miguel de Icaza l’a montré sur Twitter.
Concernant les améliorations, elles sont multiples. Le moteur de recherche est annoncé comme plus rapide, on voit désormais avec qui un mot de passe est partagé, on peut créer des collections qui s’afficheront selon le contexte (cacher par exemple les identifiants de la famille quand on est au travail), les mots de passe supprimés peuvent être restaurés, l’extension pour les navigateurs se veut plus complète, la récupération des données est étendue aux comptes Famille et Business, etc.
Commentaires (33)
#1
C’est à quelle date ce changement ?
Je viens de regarder sir IOS et l’application ne demande rien pour l’instant.
J’espère qu’il y a une communication et un ultimatum avant de changer l’offre.
#2
Eh ben… je l’aurais très très mauvaise à la place de ceux qui ont payé pour une licence “perpétuelle”….
#3
C’est dingue, plus personne ne sait faire une appli native ou bien ?
Ou alors c’est la mode des devs “full stack” qui ne savent plus développer en autre chose que du js ?
#3.1
Si, un dev iOS sait faire une appli native iOS.
Et un dev Android sait faire une appli native Android.
Et un dev Windows sait faire une appli native Windows.
Et un dev Linux sait faire une appli native Linux.
Et un dev macOS sait faire une appli native macOS.
Donc derrière, si dans l’absolu une boite peut remplacer 6 dev par 1 seul qui te fait une appli universelle, ça ne me semble pas déconnant que ce soit une solution envisagée. Surtout quand tu vois le coût que représente 1 dev.
Edit: d’autant que ça te permet d’avoir la même chose partout, tout le temps. Plutôt qu’avoir des apps qui évoluent chacun dans le coin. Je vois ici, on a beau essayer d’être iso entre toutes les apps, c’est pas évident du tout.
#3.2
Un vrai dev sait développer sur n’importe quel plateforme, avec n’importe quel langage, quitte à potasser une ou deux semaines au début, et qu’on lui fournisse le matos.
Les autres sont des faux devs, qui ne méritent pas plus que le smic.
#3.3
Oui, mais quand bien même, tu n’as pas la même masse de travail à gérer six plateformes, même avec des dev “multi-langages” (et on peut certes en maitriser plusieurs, mais maitriser chacun et son écosystème sur le bout des doigt c’est un autre délire).
#3.4
Dans le doute, je préfère considérer que ton message est un troll :)
#3.5
A chaque période sa mode de l’“application universelle”. Il y a une 20aine d’années les SSII te fourgaient du dev JAVA à toutes les sauces en recrutant des gars qui avaient suivi une formation de 5 jours.
Aujourd’hui, c’est JS.
Et ce n’est toujours pas du dev, juste assembler des bouts de trucs trouvés sur le net sans bien comprendre ce qui est fait et compter sur le système pour se débrouiller avec des appels sans la moindre optimisation.
#4
Utilisateur depuis des années d’1Password (Mac, iOS & Windows), j’attendais une version Linux, qui au final est arrivée mais uniquement via abonnement, là tout le reste y passe avec la version 8, il n’y aura plus possibilité d’avoir un coffre local, tout est obligatoirement chez eux, donc pour moi c’est niet !
Ça faisait quelques mois que je lorgnais du côté de bitwarden, dont NI avait déjà parlé ici :
https://www.nextinpact.com/article/46074/bitwarden-gestionnaire-mots-passe-qui-se-demarque-concurrence
C’est aussi de l’hébergé et de l’Electron, mais c’est opensource et auto-hébergeable !
Plutôt que le serveur bitwarden (du .net et SQL Server, postgresql à l’avenir), je suis parti sur le serveur “vaultwarden” implémentation en rust & sqlite (d’autres bdd sont possibles) :
https://github.com/dani-garcia/vaultwarden
L’installation est sur un vps que j’avais déjà, j’ai donc dégagé 1Password sans regret !
#5
Déjà les versions 6 et 7 pour les acheter en standalone c’était le cirque, j’avais acheté la v4 à l’époque, mais abandonné 1Password ensuite.
Pour ce qui est du dev, effectivement développer une webapp c’est moins cher, mais c’est aussi moins bien, quand on veut faire payer les gens tous les mois il faut que le service soit de qualité.
#6
J’étais chez 1Password avant qu’il y ai l’abonnement et je suis maintenant chez Bitwarden que j’aime bien.
Mais je préfère avoir une application en local avec synchronisation via le cloud de son choix (OneDrive, iCloud, ou autre). Dans ma tête, il y a moins de chance de tout perdre ou bien d’avoir une fuite de donnée.
Il y a aussi la double authentification sur ce type de logiciel, c’est bien mais c’est un peu risqué de tout perdre…
#6.1
Syncthing
#6.2
Pardon ? Si le fichier est sur un cloud qu’on utilise, c’est déjà synchronisé entre les appareils. pas besoin d’une autre application pour faire pareil…
#7
Je préfère continuer de donner des sioux aux développeurs de KeepassXC.
#8
Un code d’une cinquantaine de ligne et un dossier vendor de 1Go ?
#8.1
Ah, toi aussi tu as reçu un ear d’Accen^H^H^H de Voldemor?
#9
D’un autre côté, ca sert à rien de réinventer la roue, vaut mieux se reposer sur des libs qui ont fait leurs preuves.
#9.1
Le problème d’Electron c’est pas tant de capitaliser sur un truc qui marche. C’est que la moindre appli embarque désormais 500MB de runtime produisant des livrables d’une taille hallucinante.
Un peu comme la grande période des logiciels java qui installaient tous leur propre JVM…
C’est pas vraiment efficient en terme de consommation des ressources.
#9.2
Je suis très dubitatif sur ce type de critique. 1Password, c’est clairement pas une appli qui a besoin de perf, donc le langage le moins optimisé qui soit fait très bien l’affaire. 500Mo de stockage aujourd’hui ça vaut combien? 5 centimes?
C’est sur qu’intellectuellement c’est pas très satisfaisant, mais en pratique, est-ce vraiment un problème?
Perso pour un gestionnaire de mdp je préfère qu’il se concentrent sur la sécu du bouzin que sur l’optimisation des ressources consommées.
#9.3
C’est une logique à court terme de se dire que la ressource aujourd’hui est peu chère donc on l’utilise n’importe comment. (la récente pénurie de puces électroniques aurait dû sonner quelques cloches pourtant)
Je trouve ça quand même très stupide (c’est le seul mot qui me vient en tête) quand d’un côté on parle d’utilisation efficiente et mutualisée de ressources pour l’infrastructure (virtualisation, containérisation…), et qu’à côté on se dise que le client il a plein de stockage et qu’il sait pas quoi en faire donc YOLO.
Pour l’aspect sécurité, on est pas à l’abris d’applis basées sur Electron qui utilisent une version pas à jour. J’imagine (et espère) qu’ils utilisent une version récente et bien à jour niveau sécu.
#10
Un seul mot : Bitwarden !
#11
Ca fait 7 ans que certains demandent un mode runtime dans electron afin d’éviter cela…
https://github.com/electron/electron/issues/673
#11.1
On a pas le cul sorti des ronces. Et d’ici qu’ils le fassent il aura été remplacé par une énième nouvelle stack bouffant à nouveau 70% de ressources inutilement.
Sorry, hello-world-1.0 requires at least 4 TB available on disk.
#12
En même temps, c’est pas non plus de la rocket science…
#12.1
Ben si… Connaître sur le bout des doigts chaque spécificité de chaque API de chaque OS (en se mettant à jour en permanence bien sûr), c’est compliqué, même quasiment impossible.
D’autant que dans toutes vos élucubrations, vous oubliez le nerf de la guerre. Combien de budget alloué pour développer les applications en question ? Tous vos fantasmes d’optimisation, d’efficacité, de sécurité et j’en passe dépendent presque exclusivement de ce paramètre, que vous ne connaissez pas.
Cracher sur celui ou ceux qui ont pondu une appli sans connaître ni les contraintes imposées, ni le temps, ni le budget, ni le personnel alloué, c’est digne des experts en tout genre qui pullulent sur Facebook et Twitter.
Donc dire “lol c’est facile”, c’est non. C’est pas facile. Prendre les autres pour des crétins, ça c’est facile.
#13
+1
#14
Mec, j’ai assez de bouteille pour avoir une idée de ce qui est facile ou non en développement.
Et je suis désolé mais pondre une appli qui se branche sur une API système d’un coté, sur une API REST de l’autre et affiche un tableau entre les 2, non c’est pas de la rocket science.
Alors oui, peut-être que le budget est contraint mais AgileBits est une boite de 400 personnes et qui a levé plus de 300M$ ces 2 dernières années (200 en 2019, 100 en 2021). Je doute sérieusement que leur choix technique soit réellement un choix financier.
Effectivement, je ne sais pas pourquoi, ils ont fait ce choix mais je n’arrive pas à m’ôter de la tête que la mode doit avoir sa part de responsabilité…
#14.1
D’abord, ton argument d’autorité n’a aucune valeur. Des devs avec 20 ans de bouteille qui ne font pas mieux que des débutants, j’en croise régulièrement.
Ensuite, tu reconnais ne rien connaître du contexte de développement de leur logiciel mais tu te permets de les juger.
Note que je ne dis pas que tu as tort sur le fond. Qu’ils aient choisis ça par effet de mode ou à cause d’un budget limité ou autre, j’en sais rien et toi non plus. Je dis que tu as tort sur la forme (et dans la démarche).
Un peu de bienveillance, pitié.
Plutôt que de les dénigrer car ils ont fait un choix qui ne te plaît pas, essayes de comprendre pourquoi ils l’ont fait, c’est bien plus important et intéressant (et peut-être, un jour, admettre que c’était pas si bête que ça compte tenu du contexte en fin de compte).
#15
Désolé de partir du principe que les devs ne sont pas des tanches… je ne sais pas si tu essayes vraiment de les defendre là
C’est toi qui les excuse en disant qu’ils sont probablement trop nuls pour savoir ce qu’ils font…
Ben justement, ils ne disent pas pourquoi ils ont fait ce choix. Et j’ai du mal a avaler l’histoire du budget contraint ou du manque de compétences.
#16
Je n’essaie de défendre personne et je n’ai pas non plus dit que les devs étaient des tanches. Je dis que l’argument “Moi je sais mieux parce que j’ai de la bouteille” n’est pas un argument recevable, surtout sur internet.
Je n’ai rien dit de tel. Merci de t’en tenir à mes propos et de ne pas en inventer.
Et les excuser de quoi ? Pour quelle faute ? D’avoir fait des choix techniques ?
Que tu ai du mal à l’avaler ou pas, peu importe. Et je n’ai pas dit que c’était la raison qui les a poussé à faire leur choix et je ne dis pas non plus que leur choix est bon ou mauvais (car je ne sais pas pourquoi ils l’ont fait). Je dis que les jugements à l’emporte pièce sur base de rien, c’est malvenu et ça caractérise les experts en tout (mais surtout en rien).
#17
Ben à l’origine, moi je demande si y’a encore des devs d’applis natives, rien de plus, hein…
Et je sais que oui.
Après, effectivement, ils font leur choix mais ça m’oblige pas à trouver ce choix valable.
#17.1
Je suis complètement en phase avec ça et je suis le premier à critiquer (au sens noble) les choix techniques.
En relisant tout notre échange, je me rends compte que je n’ai cité que toi, (j’ai tilté sur le coup de la rocket science, que j’ai peut-être mal interprété d’ailleurs ?), et je me suis un peu emporté mais le ressenti que j’ai eu en lisant les commentaires, c’était “ils sont cons, ils font tel techno, ce ne sont pas de vrais devs”.
#18
Abonnement obligatoire… Cette sensation de raz-le-bol d’être pris pour des … systématiquement, un pur moment de bonheur.