[Suggestion] Remplacer Java par Flash ?

[NY152]

Coucou tout le monde ^^

DSM est vraiment excellent MAIS il est tributaire de Java de moins en moins supporté par les navigateurs (pour des raisons de sécurité)

Etant un utilisateur de Chrome, utiliser File Station pour mes transferts de PC à NAS est impossible depuis longtemps maintenant.

Je pensais que Synology aurait réagit et aurait changé la partie Java par du Flash par exemple (ou tout autre langage permettant de remplacer ce que la partie Java fait)

J'aimerais donc voir arriver un support des unités de la machine sur File Station arriver quelque soit le navigateur.

Qui est pour ? :-P 

[PiwiLAbruti]

Contre :

1. J'ai banni Java et Flash de toutes mes machines,
2. Ça restera du bricolage quelque soit l'implémentation choisie,
3. J'ai de très gros doutes concernant la sécurité de ce type de solution (accès complet au disque qui remonte dans une page web du navigateur),
4. Pour ma part, le glisser-déposer (drag'n drop) pour envoyer des fichiers sur le NAS me suffit amplement (pour les rares fois où je l'utilise),
5. Si l'option "client lourd" est envisageable, Cloud Station Drive fait parfaitement l'affaire.

[antdid]

Flash n'est pas une solution. Il y a beaucoup de faille de sécurité et les navigateurs comme Chrome, Firefox ou même Edge vont bloquer leurs contenus progressivement. 

[Fenrir]

• Flash : mort (en partie) dixit Adobe
• SilverLight : mort dixit Microsoft
• ActiveX : mort dixit Microsoft
• Java : ça reste le plus portable et ce n'est pas si risqué que ça à condition de le maintenir à jour, de bien le régler et de bien faire attention aux avertissement
• HTML5 (filesystem api) : ce n'est pas pris en charge par la plupart des navigateurs car c'est encore plus dangereux que les plugins ci-dessus

Maintenant le fond du problème : un navigateur Web c'est fait pour afficher des pages Web, pas pour se balader dans le système de fichiers

=>je suis aussi d'avis que le drag&drop est suffisant pour le mode nomade, pour le reste tu as encore CIFS/NFS/SCP/FTP/WebDAV/AFP

[NY152]

Pour le cliqué/glissé c'est pratique oui mais unidirectionnel PC>NAS, pas l'inverse.

Java reste la meilleure méthode ? Bof, y a plus que Firefox qui ne le bloque pas et ça ne serait tarder.

Pour ce qui est du CIFS/NFS/SCP/FTP/WebDAV/AFP, oui c'est la meilleure solution ... quand on a pas plusieurs centaine de To à transférer ...

Y a aucune solution finalement ...

[PiwiLAbruti]

C'est si compliqué que ça de télécharger des fichiers depuis File Station sans glisser-déposer ?

Je ne vois pas bien dans quel cas d'utilisation précis ça pose problème, tu pourrais nous en dire plus ?

[NY152]

C'est pas compliqué, c'est lent !

Quand tu utilise File Station en CIFS/NFS/SCP/FTP/WebDAV/AFP tu es tributaire de la vitesse du réseau. Et quand tu as d'énormes volumes de données à transférer, par l'explorateur Windows c'est beaucoup long

[PiwiLAbruti]

Je n'ai rien compris.

il y a 24 minutes, NY152 a dit :

Quand tu utilise File Station en CIFS/NFS/SCP/FTP/WebDAV/AFP [...]

File Station ne fonctionne qu'en HTTP et n'a rien à voir avec les autres protocoles.

Est-ce que tu peux décrire précisément ton cas d'utilisation ?

[Fenrir]

Il y a 5 heures, NY152 a dit :

Pour ce qui est du CIFS/NFS/SCP/FTP/WebDAV/AFP, oui c'est la meilleure solution ... quand on a pas plusieurs centaine de To à transférer ...

Au contraire, dès que tu dépasses quelques giga, le couple [navigateur web]-[serveur web] est certainement ce qu'il y a de pire (après xmodem).

Sans parler des problèmes de conservation des droits, des dates et des autres attributs.

Pour avoir déjà travaillé sur des fermes de plusieurs centaines de To, je peux t'assurer que PERSONNE n'utilise un navigateur Web pour faire des transferts de fichiers volumineux.

Il y a 5 heures, NY152 a dit :

Quand tu utilise File Station en CIFS/NFS/SCP/FTP/WebDAV/AFP tu es tributaire de la vitesse du réseau. Et quand tu as d'énormes volumes de données à transférer, par l'explorateur Windows c'est beaucoup long

Parce que quand tu transferts en HTTP tu n'es pas tributaire de la vitesse du réseau ? Si tu a trouvé comment faire, dépose vite un brevet, tu vas devenir très, très, très riche.

[NY152]

Ca fait pas un peu donneur de leçon là ? Hautain en tout cas ...

On a pas tous le même niveau, il est inutile de nous le renvoyer en pleine face ; Etaler ce que l'on sait de la sorte n'est pas une preuve d'intelligence !

J'ai trouvé comment faire pour ma part !

Merci à ceux qui ont prit le temps de m'aider/m'aiguiller ^^

[PiwiLAbruti]

il y a 56 minutes, NY152 a dit :

J'ai trouvé comment faire pour ma part !

C'est bien. Mais partager ta solution avec la communauté, c'est mieux.

[Fenrir]

il y a 57 minutes, NY152 a dit :

Ca fait pas un peu donneur de leçon là ? Hautain en tout cas ...

Ni plus ni moins que tes réponses selon moi.

il y a 57 minutes, NY152 a dit :

On a pas tous le même niveau

Tu as parfaitement raison, c'est pour ça que certains viennent poser des questions et que d'autres aident (ou essayent d'aider) en fonctions de leurs connaissances.

il y a 57 minutes, NY152 a dit :

Etaler ce que l'on sait de la sorte n'est pas une preuve d'intelligence

Je ne pense pas avoir étalé quoi que ce soit, j'ai juste donné un contre exemple à ton affirmation qui était fausse.

Mais à la relecture de tes posts, je m’aperçois que je suis passé à coté d'un truc, tu parlais de SMB/NFS... via filestation alors que je parlais de SMB/NFS/... en direct (sans passer par le navigateur). Dans ce cas, c'est effectivement assez lent. Via l'explorateur Windows ou Gnome, avec un nas pas trop vieux et un bon pc, on peut facilement faire 100mo/s voir un peu plus (dans la limite du 1Gbits).

il y a 57 minutes, NY152 a dit :

J'ai trouvé comment faire pour ma part !

Ça reste le plus important, ça serait encore mieux si tu pouvais indiquer ta solution, ça aidera peut être d'autres utilisateurs (ça sert à ça un forum d'entre aide).

edit :grillé par @PiwiLAbruti

Modifié le 23 septembre 2016 par Fenrir

[NY152]

Autant pour moi si j'ai mal interprété ton post, toutes mes excuses.

La limite du 1 Gbits n'est plus en cas de link agrégation. Je me demande si ça fonctionnerait chez tous les FAI (en 2 lignes évidement)

Ma solution est très brut de décoffrage mais au chrono, j'ai pas mieux. Je fais mes transferts en SSH. On a pas d'état d'avancement (depuis toutes ces années, Linux pourrait proposer un semblant de progression avec les commande cp/scp/mv etc), mais ça semble être le plus rapide. Que ce soit d'un volume interne à l'autre, que via une machine distante.

Modifié le 23 septembre 2016 par NY152

[Fenrir]

Il y a 1 heure, NY152 a dit :

La limite du 1 Gbits n'est plus en cas de link agrégation.

Contrairement à ce que pense beaucoup d'utilisateurs, l'agrégation de liens ne permet pas de doubler/tripler/... le trafic d'un client. Il faut au moins 2 clients pour voir la vitesse globale passer au dessus de celle d'une carte.

Il y a 2 heures, NY152 a dit :

Je me demande si ça fonctionnerait chez tous les FAI (en 2 lignes évidement)

C'est techniquement possible via des tunnels (par exemple gre) mais loin d'être à la portée de la plupart des utilisateurs.

Il y a 2 heures, NY152 a dit :

Ma solution est très brut de décoffrage mais au chrono, j'ai pas mieux. Je fais mes transferts en SSH. [...]

Le ssh peut sembler être rapide si le débit est faible, mais plus ça va vite, plus le cpu doit chiffrer vite, au bout d'un moment c'est ce dernier qui limite le débit (sans oublier les 20 à 30% de surcharge sur chaque paquet ssh). En passant, tu as l'option -C pour compresser, mais encore une fois, plus le débit est élevé, moins c'est intéressant.

Il y a 2 heures, NY152 a dit :

Linux pourrait proposer un semblant de progression avec les commande cp/scp/mv etc

C'est justement pour ne pas perdre de cycles cpu en affichage que ces commandes n'affichent pas de progression.

Il y a 2 heures, NY152 a dit :

ça semble être le plus rapide. Que ce soit d'un volume interne à l'autre, que via une machine distante.

Tu devrais tester rsync (en direct, pas via ssh).

[NY152]

Oui évidement, il faut que le serveur ET le client soit en link agregation sinon, point de gain ^^

Pour le SSH, j'ai pas trouvé mieux. Peu importe la surcharge système, cela reste du ponctuel (même si c'est régulier (1 à 2 fois par trimestre)

Pour la progression des commandes, elles pourrait par exemple être optionnelle pour laisser le choix à l'utilisateur. N'être basée que sur x/x fichiers (ça n'indiquerait en rien le temps mais juste un peu où on en est, cela coûterait presque rien en cycle au lieu de calculer la taille de toute la copie/déplacement ^^)

Pour rsync, c'est valable pour un clonage, personnellement c'est bien souvent des déplacements de gros volumes de données.

[Fenrir]

Il y a 23 heures, NY152 a dit :

Oui évidement, il faut que le serveur ET le client soit en link agregation sinon, point de gain ^^

Faux.

L’agrégation de lien ne s'amuse pas à couper 1 paquet sur 2 pour les faire passer par l'une ou l'autre des cartes réseau, sinon imagine la charge CPU (ou des ASICS) sur les différents équipements (ton pc, le switch, le nas) pour couper/réassembler les morceaux de paquets. Déjà qu'on perd pas mal de temps à réassembler les fragments de 1500o (d'où l’intérêt du jumbo frame), alors qu'ils sont numérotés et qu'ils arrivent dans l'ordre, si on devait le faire sur 2, 3 -> 8 fois plus de morceaux, dans le désordre et sans avoir les n° de séquence, il faudrait des monstres de puissances.

Donc je répète, il faut au moins 2 clients (comprendre 2 machines clientes) pour en profiter.

1 client avec 8 cartes 1gbits utilisera toujours la même carte dans un dialogue avec un serveur lui aussi en 802.3ad.

Après, avec un peu de tuning, on peut faire passer certains protocoles (comprendre n° de port) par telle ou telle carte, mais jamais par plus d'une à la fois. Donc avec un super tunning, tu peux faire du FTP à 1gbits + du SMB à 1gbits, mais pas du FTP ou du SMB à 2Gbits.

Il y a 23 heures, NY152 a dit :

Pour le SSH, j'ai pas trouvé mieux. Peu importe la surcharge système, cela reste du ponctuel (même si c'est régulier (1 à 2 fois par trimestre)

Perso je fais aussi souvent ça en ssh, c'est tellement plus simple que les autres manières de faire (sauf quand j'ai des gros volumes à balader).

Il y a 23 heures, NY152 a dit :

Pour la progression des commandes, elles pourrait par exemple être optionnelle

Elles pourraient, mais dans ce cas ça ne serait plus les mêmes binaires (pour info, cp n'est pas un programme au sens où tu l'entends, il faut plus voir ça comme une fonction de coreutils (sous GNU Linux), qui doit répondre à certains impératifs très bas niveau et des contraintes POSIX fortes). Changer cp (ou quelques autre outils du même genre), ne serait ce que pour ajouter une option, peut avoir d'énormes répercutions sur le reste du système.

Enfin, KISS (Keep it simple, stupid) reste un des principes fondamentaux pour avoir un système stable.

Il y a 23 heures, NY152 a dit :

cela coûterait presque rien en cycle

Le calcul de l'avancement dépend fortement du système de fichiers, du type de stockage et du cache des disques. Pour chaque "morceau" (bits/bytes/inode/bloc/... ?) il faudrait enregistrer en ram (donc prendre des ressources) sa taille, faire la somme de ce qui est déjà passé (encore un bout de ram qui s'envole), faire le ratio de la taille totale (ram), créer l'affichage (ram), le transmettre au terminal (ram), que le terminal le dessine (tu as combien de caractère de large dans ta console ? il se passe quoi en cas de redimensionnement ? ...), puis tout recommencer pour mettre à jour la barre ...

C'est con ce qu'une bête commande copie de fichier doit faire pour afficher des choses et encore, je n'en ai pas listé le quart.

Par contre rien ne t’empêches d'utiliser l'un des X programmes de copies qui peuvent prendre le temps d'afficher une estimation de la progression (mc, bar, advanced-copy, gcp, curl (oui il peut copier des fichiers) ...) perso j’utilise rsync quand j'ai besoin de suivre l'avancement d'une copie locale.

A titre d'illustration sur le cout de l'affichage :

tar cf /tmp/etc.tar /etc
cd /tmp
########### je n'affiche rien
time tar xf etc.tar

real    0m0.088s
user    0m0.015s
sys     0m0.070s
########### j'affiche la progression
time tar xfv etc.tar

real    0m0.292s
user    0m0.054s
sys     0m0.198s
########### j'enregistre la progression dans un fichier , sans l'afficher
time tar xfv etc.tar > 1

real    0m0.129s
user    0m0.034s
sys     0m0.092s

Dans le même genre, dès qu'on a beaucoup de fichiers à déplacer via le réseau, il est très vite plus rapide de faire une archive, de la copier (ou de la streamer) puis de l'extraire que de copier les fichiers directement, surtout en ssh

=> tar zcf - toto | ssh login@destination "cd /titi && tar zxf -"

Le 25/09/2016 à 22:13, NY152 a dit :

Pour rsync, c'est valable pour un clonage, personnellement c'est bien souvent des déplacements de gros volumes de données.

Rsync sert principalement pour de la copie de gros volumes de fichiers, en particulier car il est capable de reprendre là où il s'est arrêté (crash, coupure réseau, interruption utilisateur, ...).

 

ps : au cas où ... j'ai pris le temps de répondre avec pas mal de détails à ta question car elle cache plein de choses super intéressantes (avis très subjectif) si on s’intéresse au fonctionnement d'un système d'exploitation et aux perfs.

[Lelolo]

Merci des détails, car même pour les autres c'est super intéressant comme "point de vue"

[NY152]

Je m'incline, ce que tu avance est très informatif ^^

Pour le link agregation, je te fais confiance ^^

Pour cp, c'est vrai ça se tient, le minimum syndical mais un cp 2.0 pourrait être proposé qui n'aurait pas d'incidence sur coreutils ^^

Cela dit quand je parlais d'une progression, je ne parlais pas forcement d'une barre de progression mais un compteur par exemple (fichier, taille transférée etc)

mais il est vrai que cela coute en cycle. J'essaie de creuser la chose en bash pour avoir un truc propre

L'idée de créer une archive en vue de la transférer et la décompresser est une bonne idée sauf quand on s'attaque à de la vidéo (projets de montage, vidéo surveillance etc ... qui la principale partie de mes fichiers), là on aurait une archive qui se créerait en une éternité, idem pour le transfert et on prendrait un coup de vieux à la décompression quand on voit les super processeurs de nos NAS ^^

Quant à rsync, je ne l'ai jamais utilisé (à tord sans doute), je regarderais ce que ça donne mais est-ce exploitable avec des clients sous Windows ?

[Fenrir]

Il y a 5 heures, NY152 a dit :

Pour cp, c'est vrai ça se tient, le minimum syndical mais un cp 2.0 pourrait être proposé qui n'aurait pas d'incidence sur coreutils ^^

ça existe déjà (cf mon précédent post), ça ne s’appelle juste pas cp pour ne pas entrer en conflit avec la commande de base

Il y a 5 heures, NY152 a dit :

L'idée de créer une archive en vue de la transférer et la décompresser est une bonne idée sauf quand on s'attaque à de la vidéo

Le 26/09/2016 à 23:02, Fenrir a dit :

dès qu'on a beaucoup de fichiers à déplacer via le réseau,

et rien ne t'obliges à compresser (ce qui n'a pas d’intérêt pour de la video, de la zik, des png, ...)

Il y a 5 heures, NY152 a dit :

là on aurait une archive qui se créerait en une éternité,

en pratique c'est "streamé", donc à aucun moment tu n'as un gros fichiers (même en ram) qui se créé

nb : ça ne marche qu'avec tar ou équivalent (par exemple dar), il ne faut pas essayer avec zip, rar, 7z, bz, gz, ...

Il y a 5 heures, NY152 a dit :

Quant à rsync, je ne l'ai jamais utilisé (à tord sans doute), je regarderais ce que ça donne mais est-ce exploitable avec des clients sous Windows ?

sous windows on peut utiliser cygwin, ça marche, mais bof ...

[NY152]

Pour tar, je ne comprends trop ton explication de stream, tu peux 'en dire plus (si ça t'embête pas évidement ^^) ; Un exemple concret ?

[Fenrir]

Il y a 3 heures, NY152 a dit :

Pour tar, je ne comprends trop ton explication de stream

C'est comme quand tu regardes une vidéo (un mkv sur ton pc, une vidéo sur le net, une vhs dans le magneto de mamie), l'écran t'affiche les images une par une (au rythme de 25 par seconde en général), pas toutes d'un coup.

En pratique ce qu'il se passe c'est que les "blocs de données" créés par le tar de gauche sont envoyés au fur et à mesure (stream) dans le tunnel ssh et réassemblés à la volée par le tar de droite.

Pour faire une analogie, imagine que tu as plein d'objets à passer d'une pièce à l'autre. Tu peux le faire de plusieurs manières :

1. tu ramasses un objet, tu vas le placer dans l'autre pièce, tu reviens et tu recommences => ça c'est ta méthode (scp -r /toto/* login@destination:/titi/.)
2. tu mets tous les objets dans un carton que tu emportes de l'autre coté avant de le vider => c'est déjà plus rapide mais il faut de la place pour le carton
3. tu mets tous les objets sur un tapis roulant qui débouche de l'autre coté => on peut difficilement être plus efficace et pas besoin de carton

Pour le détail de la commande et sa syntaxe regarde ici

[NY152]

Merci pour les infos ^^