Structure interne d’ultracopier

Voila pour résumé l’ancienne structure d’ultracopier:

structure d'ultracopier 0.2
Structure d'ultracopier 0.2, les fléches sont les données passé entre les modules (signaux Qt)

Et voila la nouvelle version:

structure d'ultracopier 0.3
Structure d'ultracopier 0.3, les fléches sont les données passé entre les modules (signaux Qt)

Cela permettra notamment de garder le type de variable utilisé, ainsi le moteur de listing et de copie communique et travaille dans le format qu’ils veulent. Et les échanges se font directement. Ca déchargera l’interface d’une tache dons elle est étrangère. La liste de copie transite toujours directement sur l’interface pour:

  1. Pouvoir tager les échanges, et donc donner un id à l’entrée dans l’interface et un autre dans le moteur de copie. Pour garder le synchronisme.
  2. Car l’interface vas envoyer des fichiers au moteur de copie via les bouttons « Ajouter fichiers » et « Ajouter dossier », donc autant tout transiter de la même manière, éviter la redondance de code.

Voila aussi les changements pour les options:

Options structure ultracopier 0.2
Options structure ultracopier 0.2, les fléches sont les données passé entre les modules (signaux Qt)

Et voila pour la nouvelle version:

Options structure ultracopier 0.3
Options structure ultracopier 0.3, les fléches sont les données passé entre les modules (signaux Qt)

Cela vas permettre une plus grande abstraction, un accés au fichier seulement quand c’est vraiment utile, une détection des changements, …

Voila pour les changements majeurs d’ultracopier.

Et voila la structure compléte:

Structure ultracopier 0.3 compléte
Structure ultracopier 0.3 compléte

Restructuration du domaine

Bonjour, je viens de restructurer une partie du domain, pour préparer la prochaine version d’ultracopier et pour une meilleur organisation.

Ce qui as été fait:

  • Suppression de l’ancien site sur www.first-world.info (le tuto sur le boot pxe sera refait et mis à jour + tard)
  • Déplacement du www.first-world.info vers www.first-world.info
  • Utilisation d’un sous domaine pour first-world.info juste pour les forums, avec maj des forums, correction de multiple bug…

Voila pour les changements qui ont été fait.

Solution d’achat de videos sans drm et hadopi

J’aime pas faire de la politique, mais je vais vous expliquer pourquoi je suis contre les gugus de député du gouvernement.

Pour moi il n’ont pas le courrage de faire bouger réélement les choses, donc il ont sorti une loi à la vas vite (ça ce note sur pas mal de point).

Le minimum serai d’avoir une offre légale hors, l’offre légale sans DRM est in-hésitante. (Regarder, il demande tous windows media player avec les drm dans les requirements). Et le catalogue de certain qui ont essayé son pauvre.

Alors je vous le demande, que faut t’il pour étre dans la légalité et pouvoir avoir ces film en .avi, .mkv, …? Les pirater et contacté directement les maisons d’éditions?

En passant je suis éditeur de solution libre et payante, et j’encourage tout ces ayants des alternative légale de la faire pour payer les auteurs, comme acheter le jeux/logiciel quand je vous avez la version piraté car il n’y as pas besoin de ce prendre la tête avec un cd ou une clef.

Apache vs lighttpd vs nginx

Bonjour, j’ai fait le teste d’apache, lighttpd et nginx sur un applicatif maison car la charge du dédié utilisant cet applicatif est importante et Apache commence à donner des signes de fatigue.

J’ai essayé de rester logique et de me rapprocher de la configuration que j’avais en production.

Les informations:

Server: AMD Phenom(tm) II X4 920 Processor, 12Go de ram ddr2 800MHz, gouvenor cpu performance, raid6 avec 8hdd, kernel 2.6.31-10
Client: Laptop Dell inspirons 1555, intel core2duo P8600, 4GB
Rewrite rules activé, gzip compression pour les fichiers js et css, mod expire, php fastcgi, redirection, alias, auth, status
Via le réseau j’ai vérifié les entêtes, la compression, le cache.. via l’extension webdevelopper de firefox
Les autres réglages sont par défaut sauf:

Nginx:

worker_processes 20;
worker_connections 1200;
partial log
use epoll;
output_buffers  16 32k;
gzip_buffers    16 16k;
access log off for: jpg|jpeg|gif|css|png|ico|js

Lighttpd:

server.max-fds = 5000
server.max-open-files = 1000
server.event-handler = « linux-sysepoll »
no log
« mod_rewrite »,
« mod_redirect »,
« mod_alias »,
« mod_auth »,
« mod_status »,
« mod_setenv »,
« mod_simple_vhost »,
« mod_compress »,
« mod_expire »
For cgi:
« max-procs » => 60,
« PHP_FCGI_CHILDREN » => « 10 »
« PHP_FCGI_MAX_REQUESTS » => « 10 »

Apache:

Worker

Pour nginx j’ai du utiliser php-fpm pour le background fast-cgi de php.

Voilà l’environnement gentoo utilisé:

Gentoo use flags:

www-servers/nginx-0.8.33  USE= »aio fastcgi ipv6 pcre ssl status zlib -addition -debug -flv -imap -perl -pop -random-index -realip -securelink -smtp -static-gzip -sub -webdav »
www-servers/lighttpd-1.4.26  USE= »fastcgi gdbm ipv6 pcre php ssl -bzip2 -doc -fam -ldap -lua -memcache -minimal -mysql -rrdtool -test -webdav -xattr »
www-servers/apache-2.2.14-r1  USE= »ssl static threads -debug -doc -ldap (-selinux) -suexec » APACHE2_MODULES= »actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias -asis -auth_digest -authn_dbd -cern_meta -charset_lite -dbd -dumpio -ident -imagemap -log_forensic -proxy -proxy_ajp -proxy_balancer -proxy_connect -proxy_ftp -proxy_http -substitute -version » APACHE2_MPMS= »-event -itk -peruser -prefork worker »

Et voilà les résultats:

Un fichier js avec plusieurs variante d’options, pour voir les fichiers compresser et statique, sauf dans le cas d’un proxy (quoi que ces serveurs n’ont pas été testé comme ça) il faut plus tenir compte de la partie réseau, surtout que le teste est fait via en réseau gigabyte, la bande passante de l’internaute et de votre serveur sera en général inférieure:

En requetes/secondes

Ensuite différente taille de fichier statique non compresser tel que des images:

En requêtes secondes

Et très important le php, interpréter via des rewrites rules ou en 404 not found, les temps de requêtes (les meilleurs sont les plus petits):

temps moyens des requêtes en ms

Le nombre de requêtes qui n’ont pas fonctionné (ayant affiché une page d’erreur au lieu de la page normale):

nombre de requêtes totales n’ayant pas fonctionné

Puis enfin le nombre que requêtes secondes, incluant celle n’ayant pas fonctionné (voir + haut):

nombre de requêtes secondes

Vu que nginx ayant dans ce cas énormément de requêtes n’ayant pas fonctionné, la vitesse ne lui sert à rien.

Conclusion

Apache est à la traîne sur tous les terrains.

Lighttpd: Il est très bon pour la compression de fichiers statiques, car il les met en cache. Le fam permet de ne pas aller voir la date de modification à chaque accès, mais il ne semble pas y avoir de gain. Pour les fichiers normaux il est un peu moins bon de nginx mais largement meilleur qu’apache. Il intègre tout ce qu’il faut pour la gestion et l’intégration de php via fast-cgi.

NginX: Il est très bon pour les fichiers statiques, semble avoir des problèmes à dé-servir les fichiers php avec php-fpm pour fast-cgi server (ou php-fpm qui ne suit pas), il ne profite pas d’un cache pour les fichiers statiques envoyés en compressé ce qui le rend un peu plus lent, par contre lors des benchmarks il a été le seul à tirer partie à 100% de mon cpu multi-coeur, et cela ce ressent dans les fichiers traditionnels et non compresser, tout est prévu en natif, donc pour les serveurs utilisant plein de fonctionnalité c’est très performant.

Attention, dans un cas optimale tout les images sont mis en cache côté navigateur via le mod expire, idem pour les css et php, donc si vos visiteurs reste longtemps et charge plein de pages d’un site, ou si vous avez plein de visites à une page la partie statique ou dynamique sera plus ou moins utilisé en fonction des cas.

Qt 4.6 compilé avec MinGW64 avec wine sous linux

Bonjour,

Vous devez sans doute en avoir mare de devoir lancé un machine virtuelle pour compiler vos application Qt sous windows, avec visual studio et ces dépendances? J’ai la solution, cela permet en autre d’automatiser la création, et donc de tout faire via un .sh:

  • Créer votre futur dossier wine
  • Lancer toujours wine et Qt avec le préfix WINEPREFIX= »/votre/chemin/ »
  • Installé TDM MinGW, et ajouter le à votre variable d’environnement PATH dans regedit en recherche la clef ayant pour nom PATH
  • Compilé le début de Qt en 32Bits avec TDM MinGW pour avoir notamment qmake.exe,uic.exe,moc.exe,rcc.exe en 32Bits
  • Garder ces exe dans un dossier à part, lancer une commande watch pour les recopier à intervalle régulier dans dans le dossier bin/ de Qt car avec la version MinGW64 c’est des exe 64Bits qui vont être généré, donc incompatible avec un wine 32Bits
  • renommer votre dossier MinGW
  • Installez MinWG64 la version snapshot la plus récente en MinGW-w64-mingw-i686.zip ou un truc comme ça
  • Copier tout les binaires dans bin/ de votre dossier MinGW qui est en 32Bits pour cible 64Bits et renommer les copies sans le mingw……- devant
  • Faite un mingw32-make distclean
  • lancer le configure puis le make comme pour une installation traditionnelle
  • Quand tout est compilé arréte le script qui ecrase vos binaires dans le dossier bin/ de Qt

J’ai rencontrer les erreurs suivantes:

  • Avec Qt 4.6.1 j’ai du désactivé le mmx, sse, sse2

Pour pouvoir avoir un maximum de compression du binaire final j’ai fait en static, pour notamment pouvoir le compresser avec upx en lzma quand upx supportera les binaires windows 64Bits.

Cette article vous permet aussi avec quelque adaptation de compiler Qt en 64Bits sous windows sans avoir besoin de visual studio en 64Bits, donc potentiellement d’utiliser Qt Creator ou tout autre IDE Qt portable basé sur MinGW.

Crash de ultracopier sous windows

Bonjour, hélas je repousse la sortie d’ultracopier, car sous windows il y as des crash sur les version récente.

Sous windows il y a utilisation de Qt 4.6.0, alors que pour développer j’utilise Qt 4.5.3 sous linux. J’espère que les problèmes vienne juste de Qt.

Au menu de la prochaine version:

  • Réglage de la taille de bloque par défaut à 1024Ko pour moins d’utilisation de cpu
  • Ajout de nombreuse langue (celle tirer des statistiques du site)
  • Résolution de nombreux bug lié à l’application d’une langue
  • Mise en cache des traductions au endroit clef pour optimisé les performances
  • Et de nombreuse autre corrections

J’essaye de fini le plus rapidement possible tout ces bugs pour sortir la version finale.

Version 0.2.0.11 d’ultracopier

Bonjour, normalement c’est enfin la dernière version avant la final.

Et je vais pourvoir enfin me concentrer sur la réalisation des plugins.

Les nouveautés dans cette version sont:

  • Peu enchaîné 2 copie dans la même fenêtre à la suite
  • Meilleur prévention du bug de blocage
  • Plus de commentaire de la source du thread de copie
  • Le packet debian ne dépend plus du CFLAGS et CXXFLAGS de l’hôte de compilation
  • Pour windows 32Bits, utilisation de la version statique de Qt aussi
  • Réparation de la mise à jour de l’image du bouton play/pause