BFG a écrit 901 commentaires

Ces "achievements" ("hauts-faits") sont un phénomène récent des jeux vidéos et ont été ajoutés à outrance depuis.
Ils consistent en un titre vaguement humoristique/"cool" avec éventuellement une référence à la culture supposée de l'audience, et sont déclenchés quand on fait quelque chose de plus ou moins banal (les plus ridicules étant les hauts-faits qu'il est de toute façon obligatoire de faire (par exemple "vous êtes arrivé au niveau 2 !", vraiment très intéressant)).
Ils servent à combler le manque d'imagination et d'intérêt que pourraient avoir les joueurs en leur suggérant de nouvelles choses à essayer. À cela, il faut ajouter le côté "réseau social" (si votre logiciel ou votre site web n'a pas une fonctionnalité de réseau social, votre logiciel/site n'est pas "cool"), car avec les plateformes obligatoires de jeu comme Steam ou GFWL, il est possible de faire savoir au monde entier qu'on a nous aussi réussi à passer au niveau 2.

Personnellement, je trouve ça pathétique.

Il me semble que Steam est pas mal à ce niveau là (réinstallation autant de fois que l'on veut par exemple).

Non, réinstallation autant de fois que Steam le veut. Pour beaucoup d'utilisateurs, aujourd'hui, ça semble "illimité", mais Steam peut très bien vous révoquer ce droit (et il l'a déjà fait).

J'avais pourtant précisé

(et sans convertir le texte en tableau de points de code)

car même si cela n'est pas fait par l'algorithme de Boyer-Moore, et que ce n'est donc pas inclus dans son coût propre, il faudra quand même décoder tous les octets pour "mettre un caractère par mot".

Bien, et maintenant comment fait-on pour sauter au N-ème caractère sans sauter N fois d'1 caractère ? (et sans convertir le texte en tableau de points de code)

Surtout qu'utf-8, précisément, a été conçu pour qu'un algorithme de recherche sur des données binaires garde sa pertinence en utf-8.

Il doit me manquer quelque chose, parce que je n'arrive pas à la bonne conclusion. En UTF-8, il est possible de sauter au caractère suivant sans passer sur tous les octets. L'algorithme décrit dans le fil demande de sauter plusieurs caractères, ce qui est particulièrement efficace si l'on est certain qu'un caractère fera un octet. Avec UTF-8, il faudra donc tout de même passer sur chaque caractère, et dans le cas précis où le texte ne contient que des caractères n'utilisant qu'un octet, il faudra passer sur chaque octet, ce que l'on voulait éviter.
On peut aussi sauter quand même N octets, mais on ne saura pas combien de caractères on a sauté.

En cherchant très rapidement la constante mentionnée dans le journal (0x1008FE21), on peut lire ceci dans le code du serveur X :

 #define XF86XK_ClearGrab	0x1008FE21   /* kill application with grab */

"Grab" est une fonctionnalité qui permet à une application de monopoliser le clavier ou la souris afin qu'aucune autre application ne s'en serve. Cela sert pour les applications plein écran, et également par le verrouillage de l'écran. Le "ClearGrab" me semble totalement incompatible avec le verrouillage d'écran.

Et je pourrais même leur réclamer des rapports de bug en disant : "bug report or it didn't happen".

C'est un très bon moyen pour se glorifier et prétendre que notre logiciel n'a aucun problème, parce que beaucoup de situations à problèmes sont difficiles à reproduire (surtout quand le problème implique de nombreux logiciels agissant en même temps, ainsi que de très nombreux autres paramètres), ou qu'il y a une part de subjectif ("le son est souvent de mauvaise qualité"), ou que l'on peut rejeter les rapports de bugs facilement ("pas assez d'informations, affaire classée").

Je ne crois pas qu'il faille dessiner le motif pour verrouiller le téléphone. Par contre, le motif est certainement l'une des actions qu'on fait le plus souvent, et il arrive de déverrouiller le téléphone mais ne faire aucune action après ça. (Aussi, ne faire que cliquer sur des icones laisse peu de traces sur l'écran)

Enfin j'ai tendance à dire que c'est pire pour un ordinateur portable

Peut-être avez-vous des éléments pour prouver cette affirmation ?

• Un mot de passe fort pour dévérouiler le téléphone quand il est allumé.
• Chiffrer les partitions, notament SD. Il me semble que LUKS fonctionne sous android, même si après, il faut pas vouloir lire sa carte SD sous Windows.

https://linuxfr.org/users/yusei/journaux/vol-de-smartphone-et-donn%C3%A9es-personnelles#comment-1309305

Quand bien même, je ne parlais pas de passer à Ext2/3/4 mais juste à LUKS. Celle-ci peut ensuite contenir du FAT32 ou mieux du NTFS aujourd'hui utilisable partout.

Vous avez raison, j'ai répondu ça par réflexe mais ça n'avait aucun rapport.

Pour le problème 64bits, c'est uniquement parce que Microsoft demande de signer les pilotes 64bits par certains fournisseurs de certificats seulement (parmi les plus chers). C'est un frein au libre, et FreeOTFE ne fournit pas de binaires signés uniquement pour des raisons financières. Google pourrait très bien payer ce prix.

En effet, en cas de vol, la moindre faille permet d'accéder au données personnelles, et ce même si il y a un code de verrouillage téléphone (j'utilise le "signe à neuf points", ça vaut ce que ça vaut)

Il y avait un bug qui rendait le téléphone indéverouillable quand on se trompait 5 fois en faisant ce signe (le téléphone demandait alors le mot de passe du compte Google, sauf que cette vérification ne marchait pas), mais il était possible de passer outre (grâce à un autre bug, en se faisant appeler, ce qui donnait accès au menu)

Donc avec un téléphone à jour [...]

Cette précondition est impossible à remplir avec certains téléphones, dont les mises à jour se sont arrêtées à la version 1.6.

Dernier point noir: la carte SD. Sur les derniers Nexus il n'y en a pas(c’est interne), donc tu es protégé.

Pas de carte SD ? Bientôt la batterie sera impossible à retirer, puis on ajoutera quelques DRM, la protection contre les utilisateurs sera parfaite. Ah, il fallait protéger contre les voleurs uniquement ? Il y a une différence entre les deux ?

C'est quand même très bête, c'est pas comme si Linux et par extension Android ne disposaient de rien pour chiffrer des partitions.

Avec des performances diminuées. Je ne sais pas l'impact que cela aurait sur un téléphone. (Sur un ordinateur, c'est tout à fait supportable)

Il suffirait de formatter la SD en LUKS, ça n'empêcherait même pas de la lire sur un PC (même sous Windows grâce à FreeOTFE).

Ce n'est pas aussi simple sur Windows. D'abord, FreeOTFE ne marche pas sur Windows 64bits à moins de le bidouiller. Ensuite, il me semble (à vérifier) que certains outils comme ext2read ne lisent que les partitions physiques, donc pas celles que FreeOTFE crée.

On passe de 70⁶⁴ à 10⁴ + 10³, c'est bien plus qu'une division par 1 000, c'est une division par, approximativement, 7×10⁶⁰.

Très approximativement alors, parce qu'une meilleure approximation serait plutôt 7⁶⁴×10⁶⁰.

Édition : excusez-moi pour ce message, je n'avais pas vu la date, j'ai parcouru les dépêches, et l'une listait ce journal.

Oui, il suffit de lire les commentaires YouTube d'à peu près n'importe quelle vidéo pour voir des horreurs, mais ça n'excuse rien du tout.

"It cost 3$." n'est pas une phrase au présent. Au présent, la phrase est "it costs 3$.". Donc, il faut se demander pourquoi il y a cost. Et bien, le verbe to cost est irrégulier et devient cost au prétérit et cost au participe passé. La phrase était donc au prétérit, et la question est "how much did it cost?".

Édition : voir la liste des verbes irréguliers anglais.

Vis-à-vis du PNG, une fois de plus, c'est la numérisation qui cause souci: les blancs ne sont pas si blancs, beaucoup de documents ont des fonds bariolés, et au final un PNG prenait une place folle.

Je ne l'ai jamais essayé, mais j'étais tombé par hasard sur le projet unpaper qui m'avait semblé intéressant.

Ou encore DjVu.

Pourtant, Google se restreint dans ce qu'il indexe, et accepte qu'on le restreigne (à la discrétion des administrateurs de sites), puisqu'il existe robots.txt. Et je ne pense pas que robots.txt a été créé uniquement pour des raisons techniques (par exemple empêcher un robot de parcourir une liste sans fin de pages, ce qui augmenterait la charge serveur), car il est possible de spécifier des règles différentes selon les robots.

Je disais juste que netcat savait utiliser les sockets UNIX, contrairement à tes allégations.

Il n'y a pas qu'un "netcat", on ne peut donc pas dire "netcat supporte les sockets UNIX" ni "netcat ne supporte pas les sockets UNIX".

Ce genre de choses n'a rien à faire dans un navigateur. Au contraire, je trouve que c'est une bonne chose que Google ne propose pas au W3C ce genre d'horreurs. Que seul leur navigateur devienne un tas d'immondices ne me gêne pas puisque je ne l'utilise pas, mais qu'ils ne cherchent surtout pas à déverser leurs ordures chez leurs voisins !

quelqu'un a déjà dû y penser …

Depuis 1999, ce domaine de premier niveau est réservé, ainsi que quelques autres.

Je n'en ai aucune idée. Mais dans tous les cas, n'est-il pas mieux d'en parler aux développeurs de KDE, avant de refaire quelque chose de son côté "parce qu'on le fait mieux qu'eux" ?

FreeDesktop permet de définir des standards de formats, d'opérations, etc. Il n'est nul besoin de réutiliser l'implémentation de KDE, il suffit d'écrire une nouvelle implémentation avec les bibliothèques que vous voulez, du moment que votre implémentation est compatible et interopérable. Considérez par exemple le standard de gestion de la corbeille, ou le standard de gestion des vignettes de fichiers.

Monter les 2 volumes TrueCrypt N-1 et N, puis faire un rsync entre les 2 points de montage ? Vous avez raison, c'est une meilleure idée, car dans le meilleur des cas (où aucune donnée n'a changé), seuls les parties contenant les métadonnées seront relues, et non pas les volumes entiers.

Existe-t-il une solution efficace pour faire des sauvegarde différentielle d'1 machine locale qu'on contrôle et en laquelle on a confiance (fichiers ou volumes chiffrés, local protégé, etc...), vers une machine hébergée chez un prestataire externe (internet) auquel on ne veut pas confier de secrets ?

Une solution que j'imagine (si il n'y a pas de postes sous Haiku/Windaube) :
Utiliser localement EncFS sur son serveur de fichier (GNU/Linux/BSD,OSX) et envoyer sur le serveur distant uniquement les fichiers modifiés depuis la dernière sauvegarde.

Tout à fait. Il existe même un mode inversé de encfs (--reverse) permettant, non pas de stocker les fichiers chiffrés, et avoir des fichiers en clairs "virtuels", mais de stocker les fichiers en clair, et d'avoir les fichiers chiffrés "virtuels" (pour ne payer le coût d'encfs qu'au moment de faire une sauvegarde distante, si l'on a confiance en la machine locale, par exemple si l'on chiffre déjà l'ensemble du disque).

Pour référence, ajoutons rdiff-backup comme alternative à rsync (car il ajoute la conservation des versions précédentes des fichiers, avec la possibilité de jeter ce qui est ancien (contrairement aux sauvegardes basées sur git))

Si il y a des postes ne gérant pas EncFS, il faut travailler sur des fichiers en clair (ou stockés en truecrypt), puis avant de faire la sauvegarde chiffrer chaque fichier individuellement...

Si l'on travaille avec des fichiers en clair (ou avec les fichiers en clair "virtuels"), on peut utiliser duplicity qui ne nécessite pas FUSE, mais je n'ai aucune idée de sa portabilité. Je ne l'ai jamais utilisé, mais voici comment il se décrit :

Duplicity backs directories by producing encrypted tar-format volumes and uploading them to a remote or local file server. Because duplicity uses librsync, the incremental archives are space efficient and only record the parts of files that have changed since the last backup. Because duplicity uses GnuPG to encrypt and/or sign these archives, they will be safe from spying and/or modification by the server.

---

Une autre solution (peut-être) : calculer localement les différences entre les sauvegardes N et N-1, puis ne transmettre que le patch (qui sera, éventuellement, appliqué sur la sauvegarde N-1 distante) ?

(Si vous parlez d'un seul fichier comme avec LUKS/TrueCrypt) Comme le fait rsync ? Pour référence, l'outil rdiff permet de faire manuellement les mêmes étapes que rsync (générer une signature du fichier N-1, générer un delta à partir du fichier N et de la signature N-1, puis appliquer le patch au fichier N-1, ce qui est dommage est qu'il n'a pas le --inplace de rsync).