Archives du mot-clé dropbox

Heureusement, il y a Dropbox

Je me rends à l’hôpital pour régler une facture. Finalement, ce n’est pas moi qui leur doit de l’argent, c’est eux qui m’en doivent.

Seulement, pour me le donner, il leur faut mon RIB et ma quittance. Que bien sûr je n’ai pas avec moi.

Heureusement, il y a Dropbox.

Voyez-vous, quand je reçois un document administratif, je le scanne et le dépose sur Dropbox.

Donc, je demande à l’employée son e-mail. Je dégaine mon smartphone, je vais sur Dropbox, je crée un lien de partage que je colle dans le mail que j’envois ; je fait de même pour le RIB.

Quelques minutes plus tard, je voir revenir l’employée, toute admirative de la technologie moderne. Et moi, ca me confirme que le cloud, c’est bien !

flattr this!

Comparison of iPad text editors for Dropbox, Markdown and TextExpander

Editor Dropbox Choose path in DB Markdown TextExpander Free Tested Notes
Elements X ? X X
Nocs X X X X X X Markdown support unstable, can’t change the display font (Courier), can’t zoom in edit mode, font too small. I can’t use create a new doc on Dropbox when I am offline (I can still create it locally then move it later, but this is a burden).
Plaintext X X X nice font (Georgia), bu you can’t change itb(for ASCII art, for instance).
Notes X X Just works. For quick notes and when offline
Droptext X ? ? ? X

flattr this!

Choisir une sauvegarde en ligne – Dropbox vs Wuala vs Symform

Plusieurs contraintes à considérer pour le choix d’une telle solution :

  • popularité bientôt en berne
  • occupation disque
  • protection des données
  • bande passante nécessaire
  • coût
Je ne m’intéresserai ici qu’aux trois premiers.

La déception arrive

Petit avertissement : le cloud computing est arrivé sur la pente de la déception, (voir le Cycle de la survente de Gartner). Donc, bientôt les gens seront déçus par le cloud, mais ça n’aura qu’un temps. Tout ceci est très normal, donc ne pas s’inquiéter – attendez juste avant d’investir.

Sauvegarde en ligne contre stockage en ligne

La sauvegarde en ligne est la conservation d’une copie hors-site. Ça veut dire qu’il y a toujours une version dans l’ordinateur et que donc, vous ne gagnerez pas de place en sauvegardant en ligne. Pire, vous en prendrez même davantage, puisque vous aurez une copie sur chaque ordinateur. C’est encore plus flagrant avec les solutions décentralisées (ou P2P), où il n’y a pas de serveur central (Wuala et Symform), puisque non seulement il faudra de la place pour vos données, mais en plus il en faudra pour celle des autres ! Ainsi :

  • Google Docs (stockage en ligne) : 0 % d’espace disque (sauf le cache navigateur)
  • Dropbox (sauvegarde en ligne) : 100 % d’espace disque (c’est pour ça que l’on dit que Dropbox n’est pas vraiment sur cloud computing)
  • Wuala/Symform (sauvegarde en ligne P2P) : 200 % d’espace disque (idem)

Dans un contexte d’entreprise, faut y réfléchir. Surtout quand les données que doivent pouvoir lire les utilisateurs sont dans leur ensemble plus grosses que leur disque dur !

Bien sûr, il y a des raisons à ça. Le stockage en ligne (contrairement à la sauvegarde en ligne) nécessite soit de le réserver à de petits fichiers (textes), soit à avoir une très grosse bande passante, soit à ne pas accéder souvent aux fichiers. Et les solutions décentralisées ont bien besoin de stocker les fichiers quelque part ; si ce n’est pas sur un serveur central, ça doit être sur la machine des clients.

L’intégrité des données dans les nuages

Trois aspects à considérer : légal, technique et humain.

  • risques légaux. Si une loi (comme le Patriot Act) dit que vos données doivent être accessibles au gouvernement, l’entreprise qui héberge les données n’a que trois choix : obéir (et alors, le gouvernement peut avoir accès aux données et l’entreprise aussi), refuser (mieux vaut alors être dans un lieu où une telle loi ne s’applique pas ; ce furent les choix d’HavenCo et The Pirate Bay, qui tous deux essayèrent de s’établir à Sealand) ou bien plier boutique. Parades : prendre une société très importante, qui ne peut se permettre la perte de confiance (on pense à Google), crypter les données de votre côté (c’est la fameuse solution Dropbox + TrueCrypt, mais qui vient au prix d’une perte de performance (versionnage peu probant, même si des réflexions sont en cours avec iKrypt, une solution basées sur encfs et github) et une complexité accrue (installation d’une couche de cryptage).
  • risques techniques. Des disques durs, ça tombe en panne, donc sauvegardes externes et RAID sont nécessaires. Je classe aussi les risques liés à l’environnement (panne de courant, catastrophes naturelles et cambriolage) dans cette catégorie. Bonne nouvelle, prévenir tout ceci fait partie de la routine des datacenters, donc ce n’est pas un problème pour les serveurs centralisés (pour les serveurs décentralisés, on compte sur la réplication des données pour compenser le manque de fiabilité des nœud et le résultat est, on l’espère, similaire). En revanche, un problème bien plus grand est celui de la corruption silencieuse des données (réalignement magnétique, rayons cosmiques…). Une étude du CERN à montré que ce n’est pas du tout anecdotique. Les solutions existent (ZFS), mais si elles ne sont pas implémentés sur le client, ça ne sert à rien. Or, autant on peut espérer qu’un serveur (centralisé) est à l’abri de ceci, autant on ne peut pas l’espérer avant… longtemps sur les clients. Le problème est pire encore pour les serveurs décentralisés (GIGO)..
  • risques humains. L’erreur humaine (suppression accidentelle) peut être prévenue par le versionnage (conservation de toute différence, même un changement de virgule ou une suppression, l’historique de Wikipedia est l’exemple le plus connu). Certes, un individu malintentionné pourra toujours détruire les données, mais là, c’est du sabotage et de la gestion d’équipe ; on rentre dans la défense en profondeur et on quitte le champ de l’erreur humaine. Cependant, un problème important demeure : celui de ne se rendre compte qu’après moult modifications que quelque chose à été supprimé accidentellement ; mais avec un versionnage illimité, c’est juste long à réparer…

Il y a bien d’autres critères, comme le prix, l’intégration, la vitesse, l’administration (pour les entreprises)… Mais j’arrête là. Personnellement, j’utilise Dropbox et j’évalue Symform. Ce dernier a pour lui la transparence et la gratuité de Dropbox et surtout dix fois plus d’espace. En revanche, il faut aussi avoir plus d’espace disque (cloud P2P), il n’y a pas de versionnage (donc, pas de protection contre l’erreur humaine) ou de synchronisation sélective (pour éviter de tout synchroniser ou de client mobile et il n’y a pas de synchronisation en LAN. Enfin, Symform n’a pas encore fait ses preuves.

flattr this!

Dropbox feature request: no filename in shareable links

  1. I have a file on my DropBox called SharedFile.docx.
  2. I share it; the links ends in foobar/SharedFile.docx.
  3. For various reasons (e.g. change of corporate policy on naming convention), the file is later renamed Main-file.docx
  4. Then the shareable link gets broken

Two solutions:

  • wrong semantics: shareable links are created once and for all. If the document name change, then the semantics are wrong, but at least the URL still resolves
  • no semantics: the trend of using an alphanumeric string also applies to the filename and file extension

Since no semantics is better than wrong semantics, I suggest the latter.

if you agree, vote in the Votebox for a more robust shareable links scheme


That reminds me of protracted discussions some years ago about how semantics in URL are a sort of abnormality. According to the opponents of semantic URL (mostly W3C people), URL should not be meaningful (like a database ID; it is not supposed to be meaningful; it is supposed to be permanent).

Semantic URL may be good in situations where user retrieval is expected (like Wikipedia or debugging broken internal links in a blog after moving it), but is definitely bad when user may easily change the URL. Which is especially the case for interaction is exes are good… until you decide to change your scheme or your post title). Now, we all know how it matters in SEO (and also adds some welcomed syntactic sugar in case of debugging or wiki surfing), but still…

flattr this!

Accélérez gratuitement votre site web avec Dropbox CDN

(via websourcing.fr)

Un CDN est un outil pour que vos pages se chargent plus vite chez l’utilisateur (je simplifie, hein). C’est généralement payant, mais avec le plugin Dropbox CDN, c’est gratuit.

WordPress                   gratuit
Dropbox 2 Go                gratuit
CDN Amazon dans Dropbox     gratuit
Dropbox CDN                 gratuit

Il y a cependant quelques limitations importantes :

  • Beaucoup d’entreprises bloquent Dropbox (ce qui signifie que votre site apparaitra bizarrement chez ces entreprises). Le développeur en est conscient et a déclaré vouloir s’y atteler, mais 14 mois plus tard, toujours rien :(
  • Le plugin ne fonctionne qu’avec les thèmes utilisant
    stylesheet_directory dans headers.php
    . Vous savez quoi ? Même le thème de référence, TwentyTen, ne le fait pas. Résultat : un plugin très prometteur mais inutilisable. Si vous connaissez une liste des thèmes utilisant stylesheet_directory (les options de filtres de http://wordpress.org/extend/themes/ sont largement insuffisantes) ou bien un guide pour convertir un thème à stylesheet_directory, je suis preneur !

Par ailleurs, vous êtes « limité » à 10 Gbits de transfert par jour (250 si vous êtes sur Dropbox Pro), mais c’est très, très largement suffisant, même pour plusieurs blogs, donc je ne l’inclus pas dans les limitations importantes :)

Je terminerai par une pensée : tout comme l’iPod à ses débuts, on se rend que, désormais, Dropbox est bien plus qu’un produit : c’est une plateforme.

Qu’en dites-vous ?

flattr this!