Le 04/02/2018 à 16h 44

J’utilise les flux RSS uniquement sur mobile.

J’ai commencé à l’époque où j’avais un abonnement Free et son réseau 3G itinérant en carton.

Pas moyen d’ouvrir la moindre page web dans un navigateur, les pages s’arrêtaient de charger en plein milieu, et interfaces mal foutues infernales.



Avec un lecteur RSS, les articles se chargent bien, même sur les antennes pourries. Et il est même possible de les précharger en wifi à la maison pour les lire plus tard quand hors-ligne dans le train ou l’avion.



J’utilise Flym pour Android.

Le 21/07/2016 à 13h 23

darkbeast a écrit :



ouais mais la charge lente sur prise standard bmw par exemple la déconseille, après c’est peut être pour vendre des chargeurs





Ce n’est pas tant pour vendre des chargeurs que pour se couvrir vis-à-vis des assurances incendie sur des installations électriques vétustes.



Les prises électriques des garages sont souvent vieilles, sous dimensionnées et en mauvais état à cause des mauvaises conditions environnementales des garages (température, humidité, poussière, pollution des pots d’échappements)



En recommandant un nouvelle installation électrique dédiée et installée par un professionnel qualifiés, les constructeurs sortent les parapluies contre les zigotos qui bricolent eux mêmes leurs installations électriques.

Le 21/07/2016 à 12h 40

 L’autopilote de Tesla correspond exactement à la définition d’un autopilote.

Le problème est que les gens ne savent pas ce qu’est un autopilote et pensent qu’un autopilote peut conduire peut conduire seul alors que ce n’est pas le cas.

 

Alors il faut encore et encore rappeler qu’un autopilote n’est qu’une assistance à la conduite (c’est sa définition), que ça sert à tenir le volant à la place du conducteur dans des situations définies par son constructeur (il n’y a aucune définition minimale des capacités des autopilotes). Le conducteur humain reste responsable de la conduite, par exemple chez Tesla lautopilote ne gère pas les croisements, les décisions de dépassement, les situations inhabituelles etc…

Le 02/07/2015 à 17h 33

Quiproquo a écrit :



Un truc qui serait pas mal, puisqu’on cause de santé, serait une identification des victimes avec indication de données d’urgence extraites du DMP. Sur une base de volontariat.



 On a déjà la technologie pour le faire sans avoir recours aux puces sous la peau.

Internet, bases de données, tout ça… On a déjà l’exemple de l’Estonie qui numérise et met en ligne les dossiers médicaux afin d’être accessibles par n’importe quel médecin ou hôpital.

Le 02/07/2015 à 15h 12

As-tu vraiment besoin d’implanter cette puce sous la peau ?

 

Il est tellement plus simple d’intégrer cette puce dans n’importe quel accessoire tout ce qu’il y a de plus banal : trousseau de clés, carte format CB, bracelet, bracelet montre, bijou, anneau, pour obtenir 99% de la fonctionnalité sans avoir besoin d’une procédure et d’un suivi médical. Sans oublier le bordel lorsque tu veux améliorer la puce par un nouveau modèle plus performant.

A la rigueur si tu veux le garder en permanence sur toi, tu peux utiliser une puce imitant une boucle d’oreille ou un mini piercing, mais le coincer  à l’intérieur du corps sans aucun moyen de le retirer en le mettant sous la peau est superflu pour la plupart des utilisations.

Le 22/05/2015 à 15h 07

nirgal76 a écrit :



Et plutot que de mettre l’empreinte dans la carte, autant que le lecteur chez les commerçants soit un lecteur d’empreinte / réseau veineux ou autre directement. tu pose ta main et hop, ça pompe direct sur ton compte (ou celui de ton choix si plusieurs sont associés à ton identité)

 C'est très une mauvaise idée :  ton emprunte digitale est unique, personnelle et non modifiable. Tu ne dois jamais la donner à des inconnus. Il suffit qu'un seul commerçant soit véreux et utilise un terminal modifié qui mémorise l'emprunte digitale, et la revende sur internet et tu est foutu.      


       


Un numéro de carte, un code PIN, ça peut se changer... mais pas tes doigts.      


Tes données biométriques ne doivent être confiées qu'à des tiers de très haute confiance, et ne doit être utilisées que  rarement : tu n'as pas le droit à l'erreur.      

Avec le lecteur intégré à la carte, tu ne donnes ton emprunte qu'à ta banque lors de la création de la carte. Je ne connais pas l'implémentation utilisée mais il doit très probablement être possible de faire sans, en envoyant une carte non initialisée qui mémorise l'emprunte de référence lors de sa 1ère activation.   

 Et ce petit lecteur n’a pas besoin d’être très perfectionné.

Le but du lecteur d’emprunte sur la carte n’est pas d’avoir une clé infaillible, c’est d’améliorer significativement la sécurité par rapport à l’existant code PIN tout en restant dans des coûts et des efforts de mise en place faibles :

- 4 chiffres c'est pas sûr, mais un vrai mot de passe c'est trop complexe à mémoriser, et trop long à taper      


- pianoter sur un clavier = le code peut trop facilement être volé par quelqu'un qui regarde par dessus ton épaule      


- le clavier peut être piégé (faux distri-banque avaleur de carte avec une caméra, ou terminal espion chez un marchant véreux)      

Il ne faut pas oublier ensuite la dernière sécurité pour le consommateur qui est l'assurance de la réversibilité de la transaction en aval.      

Aucun vérrou n'est inviolable, aucune CB ne sera jamais infaillible. Le but de tout ce bouzin est surtout de résister aux attaques les plus simples qu'on peut rencontrer au quotidien.

Le 28/01/2015 à 20h 53

Il y a encore quelques fonctions du lecteur flash, qu’il reste à porter. Une de celles qui m’intéresse c’est le support pour les vidéos 3D stéréoscopiques.

Je sais que je fait partie d’une petite minorité à utiliser cette fonction, mais ça fait chier qu’à chaque fois que je veux regarder une de ces vidéos, je suis obligé d’activer un plugin qui force l’activation du lecteur flash.

Plus emmerdant : bien qu’il y ait de plus en plus de vidéos 3D sur youtube, les gens n’utilisent plus le tag spécifique 3D : ils mettent leur vidéos côte à côte simplement comme si c’était une vidéo 2D,  c’est de nouveau le bordel des formats concurrents 2D 3D côte à côte, dessus/dessous, anaglyphe où il faut une vidéo différente pour chaque format.

Le 11/07/2014 à 09h 50

ben5757 a écrit :



Et donc tu veux dire qu’il faut imposer le mot de passe à lutilisateur ?



Aurais tu connaissance de littérature sur le sujet ? Je bosse dans la sécu et les mots de passe style W4rL0rD5 ont encore le vent en poupe ( que ce soit auprès des autideurs ou de la direction). J’ai cherché de la littérature sur le sujet mais à chaque fois je tombe sur le fameux dessin XKCD ou des références à celui-ci.





Pour répondre court : oui, un mot de passe imposé.

Pour répondre plus en détail :

on sait que l’humain est le plus faible maillon de la chaîne de sécurité.

Le concept de mot de passe créé par un humain pour être facilement mémorisable par un humain, et ne pas être oublié, est totalement inadapté à la sécurité informatique moderne où on utilise des dizaines, parfois des centaines de service distincts avec chacun son système de sécurité indépendant.



Le mot de passe est une voie sans issue dont il faut sortir pour pouvoir résoudre ce problème.

Il faut remplacer le mot de passe (court, facile à mémoriser, facile à deviner car réutiliser), par une clé (longue et fortement aléatoire, donc impossible à mémoriser, et unique donc impossible à deviner).



Pour faire la transition avec le système de mot de passe actuel : un mot de passe imposé, créé par le responsable de la sécurité (avec un générateur de mot de passe long et aléatoire).

Et à côté il faudra populariser les systèmes de coffres-forts à mots de passe, comme keepass, lastpass, et consorts…



Et même si les utilisateurs ne les utilisent pas, j’aime à rappeler que le post-it collé sur le cadre de l’écran est plus sûr que de laisser les gens choisir 123456. (parce qu’on sait très bien, statistiques à l’appui que les gens réutiliseront des mots de passe débiles, encore et encore)

Le 10/07/2014 à 21h 03

agauthier51 a écrit :



Bof, rien d’illogique.



La sécurité est du ressort de l’utilisateur/client. On ne va quand même pas dépenser de l’argent pour ça, non ?



" /> Relisez bien le contrat…





Euh…. non, c’est l’inverse en fait.



Il est connu que les utilisateurs sont ignorants des principes de sécurité les plus élémentaires, et qu’ils outrepassent volontiers le peu qu’ils connaissent à chaque fois que ça les arrange.



Celui qui est responsable de la sécurité, c’est celui qui conçoit le système et le met à disposition des utilisateurs.

Il est de sa responsabilité de s’assurer que le système soit robuste, qu’il ne puisse pas être détourné, d’apprendre aux utilisateurs à l’utiliser, et de surveiller sa bonne mise en application.



La plus grosse faille, c’est quand le créateur d’un site donne à un utilisateur (quelqu’un d’inculte vis à vis de la sécurité) la tâche critique de créer le mot de passe, sensé être long, complèxe, difficile à deviner et unique… bref tout ce qu”on sait pertinemment que la très grande majorité des utilisateurs ne feront pas.



C’est comme si un serrurier, demandait à ses client de dessiner eux même la forme de sa clé. On sait dès le départ que ce ne sera pas sûr.

Le 17/04/2014 à 18h 20

Tim-timmy a écrit :



oui, tout comme le fait que les coûts de BP se sont effondrés depuis le lancement du service … si ça leur coûte peut être quelques clients, que ça squatte des ressources aux autres, que ça ne leur fait plus vraiment économiser de sous,





Si, utiliser le P2P fait toujours économiser pas mal d’argent en bande passante et en disponibilité. Mais ce coût est largement dépassé par les royalties à verser aux producteurs de musique. Fais une simple recherche d’actualités sur le bilan financier de Spotify, tu verras qu’ils sont financièrement dans le rouge, et que le coût n°1, c’est les licences.

Le 17/04/2014 à 17h 49

Tim-timmy a écrit :



je pense surtout que c’est logique à partir du moment où ils vendent des abonnements … Dire “‘on vend un service qui s’appuie sur vos ressources pour économiser sur nos coûts”, c’est compliqué à vendre .. Pour un service gratuit en lancement ça va .. après, des clients payants doivent tiquer un peu..





Non,

ils ne se sont pas gênés jusqu’à maintenant pour faire payer les gens alors qu’ils utilisaient le P2P à plein pot.



Dans le même communiqué de presse ils associent une nouvelle formule commerciale (c’est pas technique), à la suppression progressive du P2P.

On peut bien sûr en déduire que c’est une histoire d’argent.

Le 17/04/2014 à 17h 20

Le passage du P2P au modèle centralisé est plus probablement dû à des raisons de licences qu’à des raisons techniques, autrement ils auraient tout simplement laissé le mode P2P comme mode secondaire. Leur insistance à vouloir retirer le mode P2P entièrement montre que ça leur porte préjudice.



Ma petite intuition me dit que spotify est sensé payer ses royalties dans le pays où est basé le serveur qui émet les données. (le point de diffusion)

Dans le cas de transferts P2P, on a des milliers de points de diffusions dont la plupart se trouvent dans des pays où les royalties coûtent cher (usa, france, etc…), et donc une grosse partie des revenus partent en royalties aux 4 coins du monde.



Dans le cas de transferts centralisés, l’intégralité des données sont émises là où se trouve le serveur central : Spotify n’a qu’à implanter son serveur dans un paradis fiscal à royalties très faible, (regardez où s’est implanté l’iTunes store d’Apple) et c’est le jackpot.

Le 07/09/2013 à 21h 15

David_L a écrit :



On utilise des profils, le temps seul ne peux pas être la seule valeur relevée. La taille du fichier obtenu l’est aussi. Puis la promesse de HEVC est d’avoir une taille réduite à qualité identique, il fallait bien relever si la taille allait être limitée ou pas avec ce profil proposé par DivX 10.





Votre test n’ayant absolument pas été prévu pour comparer le rapport qualité/taille, je pense qu’il aurait été préférable de ne pas les mentionner et de vous contenter des informations pertinentes.



A moins que vous ne vouliez tester les profils par défaut fournis par DivX et comparer leur utilité pour les néophytes. Cela aurait pu être très intéressant comme approche. En effet, ce test a révélé que par défaut l’encodeur DiVX H265 est réglé sur une qualité inférieure à ce que propose leur encodeur DivX H264. Mais ce n’est pas ce j’ai retenu en lisant votre article.







David_L a écrit :



Je sais que je me répète sur le sujet… mais autour des images, on met du texte. Si le lecteur l’ignore, je ne suis pas responsable, le lecteur si. Après je savais bien que certains voudraient voir le résultat, d’ou la mise en place d’une capture, mais avec toutes les précautions nécessaires pour préciser que ce n’était qu’une comparaisons de profils proposés utilisés en mode “neuneu”. Maintenant je savais que des lecteurs adeptes du sujet voudraient en disserter pendant des heures, d’ou la mise a dispo des fichiers (pour leur éviter de passer 4h à convertir de leur côté)





Le titre en gras directement au dessus de l’image incite le lecteur à regarder l’image pour comparer et à juger par lui même.

Le texte en dessous de l’image confirme ce que le lecteur peut voir : l’image H265 est moins bonne que l’image H264 mais n’apporte pas la mise en garde cruciale (les débits n’ont pas été réglés, la comparaison des images n’a aucun sens !)

Vous affirmez avoir prévenu le lecteur et avoir pris toutes les précautions. Désolé mais j’ai beau lire et relire votre article je vois plus d’incitations à la comparaison qu’autre chose.

La seule phrase qui peut-être pourrait éventuellement avoir un sens de mise en garde : ‘Avant de trouver une solution totalement adéquate pour ce genre de comparaison de manière détaillée,…” donne l’impression que vous cherchez des outils de mesure de qualité pour exploiter les images plutôt qu’une mise en garde sur la pertinence de vos résultats, en particulier quand on lit la proposition suivante : “voici le résultat obtenu avec nos deux tests sous DivX :”







David_L a écrit :



Promis, dès qu’on peut, on tente de supprimer cette connerie qu’est la liberté d’expression.





Je ne souhaite pas vous interdire de vous exprimer, je suis pour la liberté d’expression. Mais la liberté d’expression est une arme à double tranchant, vous pouvez écrire ce que vous voulez, mais je peux vous répondre que je n’apprécie pas vos écrits, et à l’avenir ne plus faire confiance aux informations de PC INpact.

Je ne vous demande pas de supprimer l’article, je vous signale ce que j’estime être une grossière erreur et vous recommande de la corriger, ou tout du moins je vous demande de ne plus la commettre.

Si vous pensez n’avoir commis aucune erreur et que vous persistez à écrire vos articles de cette manière, je devrais conclure que nous avons un désaccord sur ce qui constitue une information pertinente, et ne plus vous prendre au sérieux.







David_L a écrit :



Le débat aurait eu lieu dans tous les cas.





L’image que vous avez publié est au coeur du débat, sans l’image et les incitations à comparer vos fichiers, le débat aurait pris une toute autre tournure.

(je viens de me rendre compte que l’article a été publié un Vendredi, y aurait-il un rapport ? Vous donnez à manger aux Trolls ?)

Le 07/09/2013 à 11h 18

David_L a écrit :



Je pense qu’il serait bon, au minimum, de lire l’article que l’on critique. Celui-ci n’est pas un comparatif de qualité, il n’a jamais eu la prétention de l’être et c’est assez clairement mentionné. Le but ici était simple : je suis un utilisateur qui veut encoder en HEVC 1080p une source 4K, quel temps cela me prend vis-à-vis d’une compression standard. Réponse : un rapport de 1 à 8 avec le même outil. L’utilisation de HB était surtout là pour voir le temps nécessaire pour une compression avec un outil tiers avec une procédure similaire “je prend les réglages de base de l’application”.





Vous êtes journaliste sur un site spécialisé avec une assez forte audience, vous êtes quand même au courant que tout ce dont vous parlez sera interprété comme ayant de l’importance.



Vous l’avez en effet clairement mentionné dans l’article. Vous ne vous intéressez qu’au temps d’encodage.



Le problème est qu’en parallèle vous envoyez des signes qui incitent justement vos lecteurs à faire ces comparaisons non significatives :

• vous publiez les tailles des fichiers obtenus, ce qui signifie que la taille des fichiers a une quelque sorte d’intérêt pour votre test
  
  -vous publiez un gros screenshot avec les deux images côte à côte, c’est dur de passer à côté, les lecteurs vont forcément comparer les images
  
  -vous publiez les fichiers obtenus et incitez les internautes à les télécharger pour donner leur avis
  
  
  
  Résultat : 8 pages de commentaires de lecteurs qui comparent des carottes avec des patates.
  
  
  
  Vous avez créé de la désinformation, et vous ne vous en êtes pas rendu compte.
  
  Vous n’auriez du vous en tenir à votre annonce d’un test poussé à venir.

Le 06/09/2013 à 23h 58

Ayant lu pas mal d’articles comparant des encodeurs vidéo, où les auteurs font des efforts énormes pour mettre les encodeurs sur un pied d’égalité, je suis choqué de voir l’absence totale de protocole de test.

• vous avez redimensionné la vidéo en 1080p dans deux logiciels distincts ce qui fait que vous vous retrouvez avec des images source 1080p différentes pour chaque encodeur,
  


• vous n’avez pas configuré les encodeurs ce qui fait que vous ne maîtrisez ni la complexité des algorithmes d’analyse d’image (donc le temps), ni le bitrate (donc la taille du fichier), donc forcément vous obtenez une qualité d’image qui ne correspond pas à ce qui devrait être attendu.
  
  
  
  En l’état, les résultats de ce test n’ont AUCUNE valeur : ni en vitesse, ni en qualité, ni en taille de fichier. Je recommande à PC INpact de refaire le test proprement et de supprimer les screenshots et vidéos de cet article car ils ne font qu’induire les gens en erreur.
  
  
  
  Attention également aux raccourcis trompeurs :
  
  “1h38 avec un Core i7 4770K pour 12 minutes de film… vivement la version hardware ?”
  
  Pour remettre les choses à leur place : les encodeurs hardware H264 ont, sans exception, une qualité d’image INFERIEURE à l’encodeur 100% CPU x264 dans son mode le plus rapide (la référence open source en H264), et il est fort probable qu(il en sera de même avec le H265. Je trouve donc trop hâtive l’idée de vouloir utiliser une accélération hardware pour améliorer le rendu.
  
  
  
  Le rendu logiciel peut être accéléré significativement en modifiant ou en ajoutant de nouveaux algorithmes faisant les mêmes opérations plus efficacement.
  
  Les encodeurs sortent généralement très peu optimisés pour pouvoir commencer à produire du contenu, et s’améliorent avec le temps.
  
  Quand on suit les mises à jour d’x264, c’est hallucinant le nombre de patchs qui ont accéléré l’encodage depuis ses débuts.
  
  A la place de ce titre, j’aurais préféré voir : “vivement les futures mises à jour de l’encodeur”

Le 17/12/2012 à 13h 19

qui.dominatur a écrit :



J’ai toujours gardé un très très très mauvais souvenir des adaptations de DMC sur PC…





DMC 3 était très mal porté sur PC, par contre DMC 4 tournait du feu de dieu. Il fallait juste un pad pour jouer (DMC n’est pas fait pour être joué au clavier/souris)



J’attend de voir une démo PC avant de l’acheter.