Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#51 Le 17/11/2010, à 15:55

Revan26914

Re : LinCopier - Gestionnaire de copies pour Linux

On dirait bien smile

Dernière modification par Revan26914 (Le 17/11/2010, à 15:55)

Hors ligne

#52 Le 25/11/2010, à 22:38

Brunod

Re : LinCopier - Gestionnaire de copies pour Linux

Quoi d'neuf, Doc ?


Windows est un système d'exploitation de l'homme par l'ordinateur. Linux, c'est le contraire...
39 pc linux convertis

Hors ligne

#53 Le 29/11/2010, à 15:06

Brunod

Re : LinCopier - Gestionnaire de copies pour Linux

up ... ?


Windows est un système d'exploitation de l'homme par l'ordinateur. Linux, c'est le contraire...
39 pc linux convertis

Hors ligne

#54 Le 01/12/2010, à 17:14

Rolinh

Re : LinCopier - Gestionnaire de copies pour Linux

Salut,

on manque cruellement de temps en ce moment (études universitaires + boulot) hmm
J'espère que l'on trouvera le temps de bien avancer pendant ces vacances de noël.

Pour donner une info quand même, Revan a comparé le moteur de copie de LC et celui de cp. Résultat: soit a égalité soit plus performant.
L'idée (piquée à NetBSD) de maper en mémoire les fichiers de moins de 8mb se révèle diablement efficace sur les petits fichiers smile

Hors ligne

#55 Le 01/12/2010, à 21:55

Brunod

Re : LinCopier - Gestionnaire de copies pour Linux

De tout cœur avec vous smile
Mais impatient quand même ! tongue
BD


Windows est un système d'exploitation de l'homme par l'ordinateur. Linux, c'est le contraire...
39 pc linux convertis

Hors ligne

#56 Le 01/12/2010, à 23:08

Rolinh

Re : LinCopier - Gestionnaire de copies pour Linux

smile
ça fait sacrément plaisir des encouragements pareils wink

d'ailleurs, je passe le message: on aurait besoin de quelqu'un pour faire le GUI en GTK. Enfin besoin... c'est juste que cela nous permettrait d'avancer un peu plus vite. J'ai commencé à faire quelque chose mais depuis je me concentre sur l'interface de la version console tandis que Revan s'occupe du moteur de copie. Sinon je m'y remettrais mais... GTK c'est pas mon fort.

Car en fait, on a décidé de faire une version console et une version GTK. D'abord, la console c'était pour tester le moteur de copie puis on s'est dit que ça serait quand même vachement pratique si, par exemple, on veut faire des copies massives sur son serveur en étant connecté en SSH. Ou bien tout simplement si on est allergique aux interfaces graphiques... tongue

Hors ligne

#57 Le 01/12/2010, à 23:13

Zakhar

Re : LinCopier - Gestionnaire de copies pour Linux

@Brunod, @Revan... discussion intéressante sur les "performances" maximales !

Mais en réalité il n'y a pas de "meilleur" truc, tout dépend du "use case" (cas d'utilisation), notamment son matériel et ce qui est le "maillon faible".

J'avais réalisé un moteur de copie optimisé sur CTOS (un O.S. hélas disparu)... il y a une vingtaine d'années !.. Et pour le "use case" à l'époque c'était fort intéressant par rapport à la copie basique du système.

Que se passe-t-il dans un programme de copie "naïf" (comme celui de Windows... et d'où l'intérêt de SC sur Windows), lorsqu'on copie un fichier :

Début :
- Lecture bloc fichier source
- Ecriture bloc fichier destination
=> tant qu'il reste des octets à écrire, retourner à début.

... et voila ! Ça s'appelle de la copie en série. Et c'est raisonnablement efficace dans 90% des cas où on copie un fichier d'un disque sur lui-même.
Simplement ce même algorithme s'avère largement sous-optimisé lorsqu'on copie entre plusieurs périphériques différents : disque à disque, disque à clé USB, disque à disque via réseau, etc...

Pour comprendre pourquoi il faut descendre au niveau physique de la chose.

Commençons par le cas simple :

- Copie d'un fichier d'un disque physique sur lui-même :
On suppose qu'il s'agit là d'un disque physique magnétique avec des plateaux et des têtes de lecture.
L'opération de copie va donc nécessiter de déplacer la tête à l'endroit à lire, lire un bloc, déplacer la tête à l'endroit à écrire, écrire un bloc, etc... jusqu'à ce qu'on ait fini la copie.
Le temps CPU est négligeable (une boucle simple, et des DMA pour lire/écrire) et donc le "maillon faible" en l'occurrence est le disque physique qui va devoir lire/écrire et déplacer les têtes.
Les optimisations que l'on peut faire dépendent de la taille des fichiers.
Sur les gros fichiers, il n'y a pas grand chose à faire en réalité.
Le temps de copie peut se calculer assez simplement à partir du temps d'accès moyen de déplacement des têtes et des vitesses moyennes de lecture/écriture des données.
Comme la taille des données à lire et à écrire est constante pour une copie donnée, le seul facteur de gain est donc de diminuer le nombre de déplacement de têtes, c'est à dire d'augmenter la taille du buffer de copie.
La seule optimisation plus "fine" serait d'essayer de "placer" le fichier destination au plus près du fichier source sur le disque pour limiter le déplacement des têtes. Mais là on est plutôt dans une optimisation de filesystem que dans une optimisation du niveau d'un "copieur".
On aura aussi des résultat assez différents selon la "fragmentation" qui génère inévitablement des déplacements de tête même si le fichier est tout lu/écrit en mémoire.

Sur les petits fichiers, il y a probablement une taille optimale de buffer et de regroupement, mais elle dépend probablement du type de formatage. En effet la lecture et l'écriture de plusieurs petits fichiers va générer des I/O supplémentaires pour aller lire les structures de contrôles du disque.

Notons que dans ce cas la parallélisation est contre-productive ! En effet, supposons que je coupe mon gros fichier en deux et fasse la copie des deux parties en parallèle, eh bien je vais générer tout un tas de déplacement de têtes qui sont préjudiciable à la rapidité de la copie.
Pour vous en convaincre c'est très simple.
- Ouvrez un terminal
- Lancez une copie d'un gros fichier (3 ou 4Go par exemple) et chronométrez.
- Une fois la première copie finie, lancez une copie d'un autre gros fichier et chronométrez.
- Ajoutez les deux temps.
- Supprimez vos deux copies.
- Refaites maintenant la même chose avec deux fenêtres de terminal ouvertes en même temps et en faisant les deux copies au même moment, chronométrez.
- Vous devriez observer un temps notablement supérieur au premier chrono (je suppose bien sûr que les copies sont toutes sur le même disque physique, et que votre disque dispose de suffisamment d'espace pour qu'une fragmentation excessive ne casse pas tout !)

Conclusion de ce use-case : un "SuperCopieur" ne fait quasiment rien gagner par rapport à la copie système classique (éventuel gain sur une copie de multiple de petits fichiers... mais pas sûr que du rsync ou des utilitaires standards ne fassent pas jeu égal voire mieux dans ce cas là !)

Cas plus intéressant
- Copie d'un fichier d'un disque physique sur un autre support physique :
Là c'est nettement plus amusant.
On a maintenant 3 facteurs :
- Vitesse de lecture
- Vitesse de transfert des données
- Vitesse d'écriture
Et là, les programmes de copie optimisés ont un avantage... à condition qu'ils parallélisent (comme vous l'avez observé).
La vitesse que l'on peut obtenir va dépendre du "maillon faible".
Supposons que mes deux supports physiques soient sur deux machines séparées par un réseau local.
Dans ce cas, le "maillon faible" pourra être le réseau local.
Un disque dur moyen sait lire/écrire entre 50 et 150MB/sec.
Si vous êtes sur un réseau local en 100Mbps, la vitesse maximale théorique est de 12,5MB/s et en pratique on plafonne autour de 11,5MB/s en NFS (le plus efficace) une fois retiré les overhead protocolaires.

Par conséquent, dans ce cas : copie d'un disque 1 à un disque 2 au travers d'un réseau à 100Mbps, votre vitesse maxi est la vitesse du réseau.

Or un programme de copie classique "série" perd du temps.
En effet, dans ma "boucle" naïve ci-dessus,
- je lis un bloc (et j'attends qu'il soit lu)
- ensuite je l'écris (ce qui nécessite au préalable de le transférer).
... puis je boucle.

J'ai donc :
- Temps lecture d'un bloc
- Temps de transfert
- Temps d'écriture d'un bloc
multiplié par le nombre de blocs.

Donc très exactement, on ajoute les 3 temps : lecture, écriture, transfert.

Finalement tout ceci est assez nigaud lorsqu'on considère que dans ce cas là les périphériques sont indépendants et pourraient lire et écrire en parallèle. Le réseau étant aussi indépendant du disque, il est possible de transférer le bloc N pendant que je lis le bloc N+1.

Un programme de copie optimisé devra donc dans ce cas :
- Allouer "un certain nombre" de blocs (mais pas trop gros... c'est contre-productif)
- Lire de façon "asynchrone" le fichier source dans les blocs
- Dès qu'un bloc de lecture est totalement rempli, on l'envoie à l'écriture.
- Lorsqu'une écriture est finie, on libère le bloc pour le rendre au process de lecture.

Pourquoi pas des "gros blocs". A l'extrême si j'ai suffisamment de mémoire pour lire tout mon fichier source en RAM et que je fais ainsi, je vais retomber dans le cas précédent de cumul des temps et on ne va pas paralléliser du tout !..

Alors ceci est la théorie, et c'était très utile sur CTOS (le gain de temps était manifeste) et toujours utile sur Windows.

Sur Linux c'est beaucoup moins utile... Pourquoi ?.. Eh bien parce que Linux est bien mieux que Windows et dispose de "buffers" considérables pour les copies.
C'est potentiellement différent d'un système à l'autre, mais sur mes PC à 4G de RAM (assez standard maintenant) j'observe un buffer de 256MB.

Pour l'observer c'est assez simple : faites une copie d'un gros fichier (par ex. 1GB) d'un disque à une clé USB. Vous allez voir les premiers 256MB se copier à toute vitesse -en réalité à la vitesse de lecture de votre disque qui est en général bien plus rapide que votre clé USB-, et ensuite le machin ralentit considérablement.
Pourquoi : tout simplement quand le système vous dit que les premiers 256MB sont copiés en réalité ils ne le sont pas réellement, ils sont juste dans le buffer de copie !.. D'ailleurs à la fin de la copie vous verrez le système "coincé" plusieurs secondes autour de 100%, c'est le temps de vidage du buffer.
Donc en réalité ce gros "buffer" joue tout à fait son rôle de parallélisation et on gagne assez marginalement à en rajouter.


Conclusion finale... "hélas" pour votre projet, Linux est tellement bien fait qu'il y a bien moins à grapiller en performances que sur des systèmes Windows avec un "SuperCopier" !..


... et c'est sûr aussi il n'y a pas que les performances, on peut certainement apporter des améliorations ergonomiques à la copie, notamment la possibilité de la mettre en pause si on a un truc urgent à faire, une grosse copie ayant tendance à sérieusement ralentir un système qui chercherait à faire des I/O sur le même disque.

Dernière modification par Zakhar (Le 01/12/2010, à 23:20)


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#58 Le 02/12/2010, à 12:55

Brunod

Re : LinCopier - Gestionnaire de copies pour Linux

Sherwood51 a écrit :

smile
...
Car en fait, on a décidé de faire une version console et une version GTK. D'abord, la console c'était pour tester le moteur de copie puis on s'est dit que ça serait quand même vachement pratique si, par exemple, on veut faire des copies massives sur son serveur en étant connecté en SSH. Ou bien tout simplement si on est allergique aux interfaces graphiques... tongue

YES ! C'est Noël avant Saint Nicolas ! :')
Avec scp ?
Linux (grâce à sa communauté) est grand !


Windows est un système d'exploitation de l'homme par l'ordinateur. Linux, c'est le contraire...
39 pc linux convertis

Hors ligne

#59 Le 02/12/2010, à 13:03

Brunod

Re : LinCopier - Gestionnaire de copies pour Linux

@Zakhar :
Rien que l'aspect ergonomique de ne plus devoir attendre stupidement une réponse après le troisième fichier lorsqu'il en reste 50000 à copier est déjà un gain extra ordinaire wink
Et ça, à ma connaissance, sur Linux non plus ça n'existait pas.


Windows est un système d'exploitation de l'homme par l'ordinateur. Linux, c'est le contraire...
39 pc linux convertis

Hors ligne

#60 Le 02/12/2010, à 18:48

Kookaburra

Re : LinCopier - Gestionnaire de copies pour Linux

Zakhar a écrit :

Conclusion finale... "hélas" pour votre projet, Linux est tellement bien fait qu'il y a bien moins à grapiller en performances que sur des systèmes Windows avec un "SuperCopier" !..
... et c'est sûr aussi il n'y a pas que les performances, on peut certainement apporter des améliorations ergonomiques à la copie, notamment la possibilité de la mettre en pause si on a un truc urgent à faire, une grosse copie ayant tendance à sérieusement ralentir un système qui chercherait à faire des I/O sur le même disque.

Merci pour ta superbe "explication de texte", vraiment bien détaillée tout en restant compréhensible, respect ! smile

Même si le gain en perf sera mini (ce que j'ai appris graçe à toi), il y a gros à gagner en terme d'ergonomie et de convivialité dans le cas de copies multiples de fichiers, LinCopier n'est donc pas un projet à abandonner pour autant.

wink


Portable17p : CrunchBangLinux // EeePC : ArchLinux
Openbox Addict : http://kookadimi.deviantart.com
Mes photos : http://www.fluidr.com/photos/kookadimi/sets
Votre téléphone mobile dispose de plus de puissance que l'ensemble des ordinateurs de la NASA en 1969. La NASA a lancé un homme sur la Lune. Vous lancez un oiseau sur des cochons...

Hors ligne

#61 Le 02/12/2010, à 20:09

Zakhar

Re : LinCopier - Gestionnaire de copies pour Linux

Loin de moi cette idée d'abandonner tout projet !

Effectivement, les côtés ergonomiques demeurent fort intéressant car la copie Nautilus standard est assez basique... elle copie quoi ! wink

Je discutais juste sur le côté performances, et soulignais que nous avons déjà un O.S. très performant qui rendait les add-ons du genre SC moins indispensables de ce seul point de vue performances ! big_smile

Dernière modification par Zakhar (Le 02/12/2010, à 20:10)


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#62 Le 02/12/2010, à 20:54

Brunod

Re : LinCopier - Gestionnaire de copies pour Linux

Bon, je replonge un peu plus de 20 ans en arrière. Le système qui était efficace pour les copies de petits fichiers était d'utiliser un ram disque en tampon pour lire d'un coup pleins de fichiers, puis les réécrire d'un coup. Ca dépassait la simple mémoire tampon du logiciel de copie et ça optimisait les écritures en diminuant les accès disques. Avoir un module lecture qui remplit le tampon, un module écriture qui le vide, avec le multitache et les pipes de unix, ça devrait le faire...
Maintenant, il faut peut-être un module "chef d'orchestre" qui règle le temps passé par chacune de ces deux tâches pour garder l'équilibre en fonction des vitesses d'accès en lecture/écriture de chacun des périphériques concernés. Je ne parlerai pas d'IA, mais un simple ajustement par approximation peut-être.
Ça vous inspire ?
BD


Windows est un système d'exploitation de l'homme par l'ordinateur. Linux, c'est le contraire...
39 pc linux convertis

Hors ligne

#63 Le 02/12/2010, à 23:54

l e . n o x

Re : LinCopier - Gestionnaire de copies pour Linux

@Zakhar : Tres instructif, merci pour toutes ces infos ;O)

@LinCopier_Team : bonne continuation, en espèrent que le papa noel nous apporte une version Beta ;O)


Zik Fan : " Vous seul savez mieux que quiconque comment organiser votre bibliothèque musicale ! "

Linux, y a moins bien.
Mais c'est plus cher. ;O)

Hors ligne

#64 Le 10/12/2010, à 16:18

Revan26914

Re : LinCopier - Gestionnaire de copies pour Linux

@Zakhar :

Tout d'abord, merci pour l'explication. :-)

Mais j'ai envie de  répondre oui et non. D'accord, il y aura toujours une limitation au niveau du hardware, mais ça ne n'empêche pas que l'implémentation joue son rôle sur les performances. Il y a la façon de gérer les erreurs, de parcourir les répertoires, etc. De plus, il y a quelques hacks qui peuvent aussi améliorer légèrement les performances ( ex. : mmap(3) ). Et justement, ce gain léger se ressent tout particulièrement sur les copies de très nombreux fichiers.

Comme on l'a dit, le but du projet n'est pas de refaire cp(1), mais de faire un gestionnaire de copie ergonomique et efficace (ex. : la copie continue en attendant une réponse de l'utilisateur). Mais je ne veux pas pour autant négliger la fonction de copie. S'il y a des améliorations au niveau de l'algorithme, je prends, bien qu'il y ait la limitation que tu as fort bien mentionnée. Je ne veux pas une fonction de copie qui soit à la traîne sur cp(1). Et d'après ce que j'ai constaté, il y a un gain d'une 20aine de secondes sur des copies plus ou moins grosses (bien sûr, il faudrait que je teste plus en détails, mais pas le temps de m'amuser à ça en ce moment).

Dernière modification par Revan26914 (Le 10/12/2010, à 16:23)

Hors ligne

#65 Le 11/12/2010, à 16:07

Brunod

Re : LinCopier - Gestionnaire de copies pour Linux

Grrr : Je vais tapisser un plafond chez mes parents (75 ans wink ) et j'en profite pour installer sur leur Ubuntu les derniers pdf techniques qui les intéressent car ils n'ont pas internet. Durée de la copie : 1/2 H. Ok, je tapisse et reviens 1H après... Mais le copieur s'est arrêté et me pose une question idiote... Reste alors 20 min à copier alors que je dois repartir.
(Censuré) de (Censuré) de copieur système !
Tout ça pour dire que chaque jour qui passe je pense à vous smile
BD


Windows est un système d'exploitation de l'homme par l'ordinateur. Linux, c'est le contraire...
39 pc linux convertis

Hors ligne

#66 Le 10/01/2011, à 11:37

Brunod

Re : LinCopier - Gestionnaire de copies pour Linux

Allo ? Père Nowel ? Rien de neuf de ce côté ? Sniff hmm


Windows est un système d'exploitation de l'homme par l'ordinateur. Linux, c'est le contraire...
39 pc linux convertis

Hors ligne

#67 Le 11/01/2011, à 14:20

Rolinh

Re : LinCopier - Gestionnaire de copies pour Linux

On travaille dessus en ce moment même. Cependant, on a des soucis avec la progress bar et on ne veut quand même pas lâcher la première alpha dans ces conditions.
Mais de toute façon, même si l'application fonctionne, étant bientôt en 0.1 alpha1, elle n'est pas encore très user-friendly niveau interface et surtout déconseillée d'être utilisée à d'autres fin que pour du test (c'est le principe d'une alpha quoi).

Hors ligne

#68 Le 11/01/2011, à 18:44

Rolinh

Re : LinCopier - Gestionnaire de copies pour Linux

Bon, alors on s'est décidé à mettre en tarball la première alpha.

On ne le répètera jamais assez mais, il s'agit d'une version de test et par conséquent, il ne faut pas l'utiliser pour copier des fichiers autrement qu'à des fins de test. Sur ce, vous êtes prévenu.
Bien entendu, l'interface n'est pas encore top, loin de là, mais s'agissant d'une alpha, celle-ci est donc amenée à fortement évoluer.

Instruction pour tester LinCopier:

  • Téléchargez l'archive de LinCopier 0.1 alpha-1 à cette adresse

  • extrayez l'archive dans votre dossier de test

  • rendez-vous dans le dossier src

    cd src
  • compilez le code à l'aide de make

    make
  • l'exécutable est créé dans le dossier src. Il est possible de lancer la version gui en tapant

    ./lincopier

    ou en double-cliquant sur l'exécutable depuis votre navigateur de fichiers

Ceux qui veulent compiler la version current, qui est en constant changement, peuvent bien entendu récupérer les sources à l'aide du dépôt mercurial.

Bien entendu, tout test est inutile pour nous si vous ne nous donnez aucun retour wink

EDIT: la gestion des erreurs a besoin d'être vraiment améliorée donc ne vous attendez pas à une gestion extraordinaire des erreurs tongue

EDIT2: je vous mets quand même deux screenshots wink

fenêtre principale
fenêtre à propos

Dernière modification par Rolinh (Le 11/01/2011, à 19:49)

Hors ligne

#69 Le 12/01/2011, à 13:46

Brunod

Re : LinCopier - Gestionnaire de copies pour Linux

Ça m'intéresse, mais l'alpha me fait peur... Qu'est ce que je risque ? Simplement que les fichiers ne soient pas copiés ? Ou altération de mes fichiers originaux ? Dans ce dernier cas, je préfère ne pas tester même si je trépigne wink
BD


Windows est un système d'exploitation de l'homme par l'ordinateur. Linux, c'est le contraire...
39 pc linux convertis

Hors ligne

#70 Le 12/01/2011, à 14:08

Rolinh

Re : LinCopier - Gestionnaire de copies pour Linux

Brunod a écrit :

Ça m'intéresse, mais l'alpha me fait peur... Qu'est ce que je risque ? Simplement que les fichiers ne soient pas copiés ? Ou altération de mes fichiers originaux ? Dans ce dernier cas, je préfère ne pas tester même si je trépigne wink
BD

On risque potentiellement un peu près n'importe quoi avec une alpha. Néanmoins, avec tous les essais que l'on a fait jusqu'à maintenant, jamais les fichiers originaux n'ont été altérés. De même, les fichiers copiés n'ont jamais été corrompus. Cependant, cela ne veut pas dire qu'il n'existe aucune possibilité que cela arrive car, comme dit plus haut, la gestion des erreurs au sein même du moteur de copie mérite encore beaucoup d'attention. Par ailleurs, LinCopier n'apporte pour l'instant rien par rapport à la copie de Nautilus ou autre pour le moment.

La copie se fait via une file et il est possible d'ajouter autant de fichiers/dossiers que l'on veut dans cette file que l'on veut copier mais... ça n'est pas vraiment visible pour l'utilisateur. De plus, l'interface mérite VRAIMENT encore BEAUCOUP d'amélioration.
Cette alpha est plus là comme preuve que le développement suit son cours et que LinCopier n'est pas un projet en l'air.

Par conséquent, elle n'est utile qu'à des fins de test, comme je l'ai dit plus haut et je te déconseille de l'utiliser pour copier des fichiers que tu n'as pas en double quelque part. C'est vraiment une première build comme on dit.

Ne l'utilise donc pas, tu risquerais d'être déçu.

Les principaux buts de la prochaine alpha sont l'amélioration de l'interface ainsi que la gestion des erreurs. Ainsi, elle devrait un peu plus se rapprocher de quelque chose d'utilisable. Lorsque le minimum des fonctionnalités que l'on souhaite sera intégré, alors on publiera une première beta et à partir de ce moment là, aucune nouvelle fonctionnalité ne sera intégrée: la phase beta sert juste à corriger les bugs.

En espérant t'avoir apporté quelques réponses wink

Hors ligne

#71 Le 12/01/2011, à 16:07

Brunod

Re : LinCopier - Gestionnaire de copies pour Linux

Merci !
Et de tout cœur avec vous wink
BD


Windows est un système d'exploitation de l'homme par l'ordinateur. Linux, c'est le contraire...
39 pc linux convertis

Hors ligne

#72 Le 02/03/2011, à 20:43

JeanNono

Re : LinCopier - Gestionnaire de copies pour Linux

Bonjour Tous,

Je viens de tomber sur ce topic et c'est super bien, c'est exactement ce que je cherche pour mes copies, une liste des copies en cours, la pause, la gestion d'erreur sans poser de question (avec log si possible) et le remplacement des fichiers identiques si nouveau (plus récent) ou ne rien faire si égale.  Et ajout dans le liste si nouvelle copie sur le même disque sans lancer une nouvelle instance.

Vous semblez sur le bon chemin, super, je suis un programmeur Pascal et Mumps (la je suis sur que vous ne connaissez pas !), mais pas encore sur Linux sauf Php. Donc je peux tester sans pb !

A bientôt et bon courage pour la suite, a très binetôt j'espère, Jean-Nono


1981 : Atom Acorn 1Mhz 12 Kio Ram - 1986 : PC 8086 4,77 Mhz - 1990 ; PCAT 386 - 2000 ; Pc 586 de compète...
2008 : Ubuntu puis Debian 6.0 et Gnome 2 sur Aspire One 150 à 1.6 Ghz 32 bits qui fonctionne toujours.
2013 - Linux MINT 13 Maya sur Aspire V5 à 1,0 Ghz 64 btis plus rapide !
L'important c'est le partage et l'échange...

Hors ligne

#73 Le 02/03/2011, à 21:07

Rolinh

Re : LinCopier - Gestionnaire de copies pour Linux

Salut JeanNono,

merci smile

Oui, il y a aura les logs pour les copies qui échouent. En fait, les copies qui échouent seront ajoutées au fur et à mesure dans une liste "à traiter" afin de pouvoir décider quoi faire après coup sans que cela n'affecte le reste des copies (traitement des cas à problèmes après coup quoi) mais cela n'est pas encore complétement implémenté au niveau du code.

J'ai programmé en Pascal par contre Mumps effectivement je ne connais pas.

En revanche, je n'ai pas eu le temps d'avancer le projet depuis l'alpha 1 (et R3v4n, l'autre contributeur non plus d'ailleurs) mais volontiers pour les tests smile
Bon, tu verras bien que l'interface est étrange pour le moment mais en gros elle sert simplement à tester notre moteur de copies, etc. tongue

Merci pour les encouragements et à bientôt.

PS: si tu connais le C et  le maitrise, rien ne t'empêche de contribuer wink
Sinon, on accueillerait encore plus volontiers un contributeur pour l'interface (en GTK+ donc).

Hors ligne

#74 Le 01/04/2011, à 08:43

Brunod

Re : LinCopier - Gestionnaire de copies pour Linux

Allo ? Quoi d'neuf Doc ?


Windows est un système d'exploitation de l'homme par l'ordinateur. Linux, c'est le contraire...
39 pc linux convertis

Hors ligne

#75 Le 13/04/2011, à 08:09

Revan26914

Re : LinCopier - Gestionnaire de copies pour Linux

Salut Brunod smile

Malheureusement rien pour l'instant sad Rolinh et moi avons trop de travail en ce moment.

Mais j'espère que bientot, sans doute à Pâques, nous pourrons poursuivre le développement et finir de poser l'interface graphique.

Dernière modification par Revan26914 (Le 13/04/2011, à 08:09)

Hors ligne