Vlobulle a écrit 253 commentaires

Question de quelqu'un qui n'utilise pas vraiment le son sous Linux: la dernière fois que j'avais essayé PA, j'avais de gros problème de rétro-compatibilité avec les applications pas faites pour. Y'a du mieux là ? Mis à part recompiler, évidemment.

Réponse probable :
"Bonjour, nous n'en avons malheureusement aucun sous la main."

Tu confonds support et données.

Parler de support numérique tel que tu l'entends n'a pas de sens : un livre papier est un support, un ebook reader est un support, un parchemin est un support, un disque dur est un support.

Un fichier n'est par contre pas un support : ce sont des données. Un livre (ou une musique, ou un film) est toujours une suite d'octets, même s'il est sur un parchemin. La suite d'octets n'est qu'une représentation de l'oeuvre (une suite de caractères en est une autre, plus agréable à l'oeil), mais pas son support.

Lors que l'on part de support numérique, on ne parle pas du fichier, mais du lecteur électronique. Le fichier existe tout autant si ton livre est sur un Kindle que si ton livre est en papier, c'est simplement qu'il est plus complexe à lire dans le second cas.

Qu'un support puisse rester en état 500 ans ou doive être renouvelé tous les 5 ans, ça ne changera rien à l'oeuvre, son existence étant indépendante de celle de ses supports. Pour détruire une oeuvre, il faut détruire la totalité de ses supports, et ça c'était effectivement possible à l'époque de la bibliothèque d'Alexandrie mais plus maintenant pour la majorité des oeuvres (pas toutes certes, un travail de numérisation est encore à faire pour plein d'archives).

"Tes" livres, quels que soient les supports sur lesquels tu les possèdes, te survivront. Que tu le veuilles ou non. :)

J'ai trouvé très amusant que tu sembles t'accorder avec l'opinion publique concernant la justesse de la taxe sur les supports vierges, alors que lorsqu'il s'agit de la question d'employer le terme web pour désigner internet, tu es intrangisant.

Ah, mais peu importe ! Le droit n'a aucune espèce d'importance face à quelque chose de beaucoup plus puissant : l'opinion publique.

L'opinion publique pense que les termes "web" et "internet" sont interchangeables.

Lis mon commentaire juste en dessous. Mais oui, c'est un cas qui se produit.

Et d'ailleurs en France, un très grand nombre de banques tarifient de la sorte les paiements en devise (mais pas toutes).

L'idée même de déclencher deux transactions pour un même paiement sans prévenir le client (ou sans lui faire entrer deux fois son numéro) est particulièrement dérangeante. C'est peut-être même interdit par la réglementation bancaire, mais je ne saurai dire. Tu devrais vérifier.

De manière plus pratique, imagine que le client paye des frais fixe à chaque paiement (ça peut être le cas pour des paiements provenant de l'étranger, ou effectués à découvert, par exemple). Avec ton bricolage, il va se retrouver avec des frais fixes multipliés par deux, et ce sans être prévenu. Personnellement, je n'apprécierai pas.

Alors si l'eCB permet de se protéger des boutiques qui font ce genre de bricolage, et bien c'est une très bonne chose pour le client.

Ah, ça non. La carte est gratuite dès lors que l'ont peut justifier les revenus. Ce n'était peut-être pas le cas auparavant.

Pour ING j'ai effectivement parlé trop vite, il faut faire le virement demandé tous les mois en théorie (mais rien n'empèche de le faire immédiatement dans l'autre sens). En pratique ils ne ferment pas le compte si on ne le fait pas.

Fortuneo. Mon compte ne me sert qu'aux paiements CB, je dois juste avoir 200 euros dessus, pas bien plus. L'interface d'eCB en flash est la même que celle des Credits Mutuels (c'est le même groupe) pour ceux qui voient. Ayant l'habitude de faire des paiement par CB à l'étranger, souvent sur des sites un peu louches, j'apprécie fortement la réduction des risques.

Il y a par contre des conditions de revenus (ou d'encours, ça marche aussi je crois) pour ouvrir le compte, mais rien n'impose de verser ses revenus dessus.

Pour info les deux autres banques gratuites (Boursorama et ING) ont grosso-modo les même conditions pour ouvrir un compte (revenu qu'il n'est pas nécessaire de domicilier ou encours), mais ne proposent pas d'eCB. Elles peuvent par contre toujours être utilisées comme fyah le fait, en tant qu'eCB "grandeur nature".

C'est rigolo, j'ai ouvert un compte dans une banque en ligne gratuite... juste parce qu'elle proposait une eCB.

Leur interface d'eCB n'est pas très pratique par contre (une appli à part entière en flash qui nécessite de retaper ses identifiants une seconde fois).

Oui, voilà. Qu'il y ait une bulle ou non, c'est difficile à déterminer, mais ce qui est certain c'est que la phase spéculative va s'arrêter en même temps que la création de la monnaie. C'est le but.

Après, en supposant qu'il y ait actuellement une bulle, et qu'elle explose, il est possible que l'usage des bitcoins en soit définitivement abandonné. Mais il est tout autant possible que ça continue à fonctionner, le facteur principal va être la confiance des utilisateurs (et non des spéculateurs) en la monnaie.

Sachant que la majorité (en terme de volume) des utilisateurs le font dans un but illégal (blanchissement, drogue, etc.), c'est assez délicat d'estimer leur confiance.

La mobilité des données en général va imposer le cloud.

Avant on était coincé avec des connexion à des débits ridicules comparées à la taille de nos données. Aujourd'hui on peut streamer une vidéo.

Avoir ses données (et ses applications !) disponibles partout est quelque chose qui parait naturel maintenant.

Skype:
- "just works",
- est utilisé par énormément de monde.

Je pensais que rsync était un logiciel conçu pour la synchronisation asymétrique. Le protocole utilisé permet-il de faire des synchronisations entre deux (ou plus) clients, dans les deux sens et en même temps (à compter que ça ne soit pas le même fichier qui soit envoyé des deux cotés à la fois, évidemment) ?

Les seules utilisations que j'ai pu faire de rsync se résumaient à donner l'ordre de backup et d'attendre un bon moment le moindre début d'envoi de la diff, donc j'ai un peu de mal à voir ce que le protocole permet.

Mais si c'est effectivement possible d'utiliser le protocole pour faire la synchro en background et bidirectionnellement, alors pourquoi pas, effectivement...

Entre SparkleShare, UbuntuOne, WUALA, Box.net, et les dizaines d'autres projets, open source ou non, vapoware ou non qui sont apparus durant ces dernières années, tous tentant de surfer sur le succès de DropBox, j'en viens à me demander si ça ne serait pas une meilleure idée de définir des protocoles une bonne fois pour toute.

Un des gros attraits de DropBox est justement qu'il y a des clients disponibles (et fonctionnels, et assez léchés) sur la majorité des architectures utilisées, y compris le web et les smartphones. A chaque fois qu'un nouveau projet veut réinventer tout ce que DropBox fait, il se retrouve toujours devant ce boulot monstrueux à accomplir, comme si mettre en place le système de synchro n'était pas déjà assez délicat.

Standardiser une bonne fois pour toute les protocoles utilisés lors des synchro, même si cela demanderait un travail non-négligeable (vu la quantité d'applications imaginables au principe de base) et de bien travailler sur l'extensibilité du protocole, permettrait à n'importe qui d'aller utiliser un nouveau client ou serveur de synchro, sans avoir à se demander si oui ou non il y aura un moyen d'accéder à ses fichier en passant par son Android. Et a priori, il n'y a pas de raison que Dropbox s'oppose à l'idée, leur business model me semble tout à fait compatible avec un protocole standard (vu que ce qu'ils vendent c'est vraiment l'accès à un serveur de synchro de qualité).

En principe, si tu sais que tu perds 10% de ton capital par an, tu vas seulement épargner une somme "de sécurité", mais ça ne rime à rien de laisser de l'argent fondre pendant 20 ans.

Attention, l'inflation d'une devise n'implique pas que l'argent de l'épargne fonde. Ca implique simplement qu'il faut le convertir en quelque chose de moins touché : soit une autre devise, soit des titres, soit des biens.

Même en forçant une inflation de 15% sur toutes les monnaies du monde, on empêchera personne d'épargner. Par contre on verra tout de suite surgir des montages financiers promettant au moins 15% de rentabilité.

Même si l'on utilise un live-CD pour copier la clef, elle sera inutilisable sans le mot de passe connu uniquement de la personne à qui appartient la clef.

Sauf erreur, pouvoir utiliser un live CD permet de se logger en root sur la machine et donc de pieger le compte de l'utilisateur pour récupérer sa clef.

Dans tous les cas on en revient au même problème : il faut que l'utilisateur soit le seul administrateur potentiel de sa machine (et donc que personne d'autre n'y ait accès).

Sauf qu'en pratique l'utilisateur lambda, il a déjà du mal à être administrateur tout court et plein de gens ont accès à sa machine (toute la famille, le technicien qui lui a configuré -c'est probablement lui le véritable administrateur-, sans parler des différents virus et autres rootkits qui peuvent avoir été installés). Bref, de toute façon, dès que l'on parle de Mme Michu, la sécurité est compromise.

Le but n'est donc pas de protéger l'utilisateur dans l'absolu, mais simplement de le protéger relativement à son environnement (d'autres Mme Michu). A partir de là, où est le problème à avoir quelques options de sécurité supplémentaires (comme du PGP dans le webmail en l'occurrence) ?

Il faut laisser le choix à l'utilisateur d'où stocker ses clefs. Que ce soit sur sa machine, sur une machine distance, ou dans un cloud ne lui appartenant pas. C'est sa décision.

Comment vous, libristes, protégeriez-vous une telle invention ?

Pourquoi réfléchir sur la notion de licence ? Le problème n'est pas là.

Une telle invention étant par construction incontrôlable, il faut mieux, à mon avis, se concentrer sur comment limiter les dégâts (matériels, sociaux, humains) qu'elle peut causer.

Une analogie avec l'ère numérique et ses conséquences sur la création en général peut être faite assez facilement. La question des licences n'y est qu'une étape, le problème de fond reste là : on ne peut matériellement empêcher les utilisateurs de copier une oeuvre numérique si on veut conserver la liberté de communication. Comment alors essayer de mitiger les dégâts sur la création ?

Même question, même si un peu plus ancienne, à une autre échelle avec le nucléaire. Si tous les pays du monde commencent à maitriser l'énergie nucléaire, que cela soit sous forme de production d'énergie ou d'armes. Jouer sur les législations n'est venu que des décennies après les premiers dégâts...

Les camping cars utilisés en résidences principales sont sujets à une taxe d'habitation (réduite) depuis peu. Je trouve logique d'appliquer la même chose pour les tentes.

Je n'ai que moins d'un Go de données que je juge importantes, donc j'ai tout mis dans un volume TrueCrypt, le tout sur DropBox. Elle est dupliquée sur 3 ordinateurs, dont un qui n'est pas chez moi (au boulot). Je change la pass-key de temps en temps.

Le reste de mes disques durs, tout est récupérable d'une manière ou d'une autre sur internet, je n'ai donc pas particulièrement envie de me casser la tête à le sauvegarder...

Comme j'ai dis, le client, le protocole et le serveur travaillent par blocs. Je n'en connais pas la taille, mais ils sont petits je suppose (quelques Ko sans doute).

Je n'ai pas les détails techniques, mais avec un volume TrueCrypt de plus d'un Go, c'est complètement transparent à utiliser.

à moins bien sûr de synchroniser avec Dropbox un fichier image de périphérique bloc TrueCrypt

Ben oui.

DropBox synchronise les fichiers par blocs, TrueCrypt ne modifie les blocs qu'on a utilisé dans le volume, donc tout marche de manière transparente. Y compris sur des fichiers très volumineux.

Non le client n'est pas libre. Même le protocole n'est pas ouvert.

Les devs de DropBox recommandent eux-mêmes d'utiliser TrueCrypt ou équivalent pour y mettre des données sensibles. Et ça marche très bien.

La dernière fois que j'avais regardé Ubuntu One n'avait pas de client Windows. Ca semble avoir changé. Je re-regarderai où ça en est.