Benoît Monin a écrit 75 commentaires

Et désolé d'avoir répondu à coté. Apparemment il n'y a pas de trace du spice de qumranet chez openSUSE pour le moment car j'ai cherché spice et les seules réponses sont ng-spice et gspiceui.

Encore une collision de nom...

Le code source est ici : [https://forgesvn1.novell.com/svn/opensuse/trunk/infrastructu(...)].

Et la liaison avec la base de donnée est là ; [https://forgesvn1.novell.com/svn/sxkeeper/trunk/sxkeeper/].

D'ailleurs sur ce serveur SVN, il y a réellement toute l'infrastructure d'openSUSE, du code source du wiki à la police utilisée pour le logo.

Si par spice tu entends Simulation Program with Integrated Circuit Emphasis, il n'est pas disponible dans la version de base d'openSUSE. Par contre ngspice est dans le dépôt science du build service : [http://software.opensuse.org/search?baseproject=openSUSE%3A1(...)]

C'est donc facilement installable avec le lien 1-click install.

20ms pour une lecture ou une écriture !? Il y a comme un bug là ! Tu peux peut-être essayer tes tests en lecture sur /dev/zero et en écriture sur /dev/null.

Si tu as les mêmes temps alors c'est ta plateforme qui a des problèmes. Il faut vérifier la configuration du noyau, la gestion des caches d'instructions et de données, les tlb...

Si c'est plus rapide, alors le défaut est dans le pilote.

J'y pense maintenant : tu peux éviter les appels à read et write si tu implémentes mmap dans ton pilote et que tu t'en sers dans ton application.

... ce n'est pas une bonne idée (*).

Ce qu'il faut c'est essayer de savoir d'où vient la lenteur : de la mémoire ou du pilote.
- Si c'est le pilote alors c'est lui qu'il faut corriger, ça profitera à toutes les applications qui l'utilisent.
- Si c'est la mémoire, il faut essayer de minimiser le nombre d'accès. Une bon moyen est de créer un "shadow buffer", c'est à dire une image de ta ram lente en mémoire standard et de l'utiliser pour les lectures. Évidemment, si un périphérique peut modifier la RAM, il faut gérer l'invalidation du shadow buffer. Ce genre de choses a plus sa place dans le pilote que dans ton application.

Dans tout les cas, tu as intérêt à créer des applications de tests qui te permettent de mesurer les vitesses de lectures et d'écritures séquentielles et aléatoires. Ça permet de savoir si les modifications que tu fais vont dans le bon sens ou non.

Un dernier truc : Si ta RAM a un signal READY/BUSY, vérifie son câblage. Je me suis fait avoir une fois avec de la flash.

(* : Si tu tiens vraiment à le faire, regarde du coté de /dev/mem)

On va commencer par une bonne nouvelle : Ton graveur est reconnu en tant que périphérique Mass Storage, donc tu n'aura pas besoin de pilote pour t'en servir.

Par contre il y a toujours les problèmes de surintensité dés qu'il y a un accès au graveur. Une première chose à faire est de vérifier qu'il fonctionne correctement sur un autre PC (quel que soit l'OS) pour écarter un éventuel court-circuit.

Ensuite, il faudra impérativement que tu trouves de quoi l'alimenter car ton portable ne fournit pas assez de courant : soit avec une alimentation externe branchée sur le graveur, soit avec un hub usb alimenté.

over-current, ce n'est pas bon signe. De plus, je suppose que tu ne t'es pas amusé à brancher et débrancher ton lecteur une centaine de fois.

Tout ces éléments sont généralement du à une mauvaise connexion physique. Essaye de brancher ton lecteur sur un port usb de ta carte mère : pas de cordon de rallonge ni de hub auto-alimenté.

Posons les hypothèses suivantes :
* Tes 2 disques durs peuvent tenir 100Mo/s en lecture séquentielle et 50 Mo/s en écriture séquentiel.
* Reste de ton système n'est pas limitant (ram et cpu infiniment rapide).
* Les disques font 100Go. (on va dire 1Go = 1000Mo pour simplifier les calculs)

Lors de la première sauvegarde, la vitesse sera limitée par le débit en écriture du deuxième disque. Ça prendra 100*1000 / 50 soit 2000 secondes, une bonne demi heure.

Lors des passes suivantes, imaginons qu'il n'y ai aucune différence à sauvegarder, la limite sera le débit en lecture. Ça prendra 100*1000/100 soit 1000 secondes, un bon quart d'heure.

Dans un cas plus réaliste, je pense que l'écart entre les deux sera moins élevé et il faudra probablement plusieurs heures dans tout les cas...

Si on regarde ce que te dit cpufreq-info, ça a l'air de marcher : ton cpu était à 1.6GHz au moment ou tu as exécuté la commande.

Le pilote utilisé est acpi-cpufreq mais ça n'a pas l'air de poser de problème concernant le réglage de la fréquence du cpu (entre 1.6 et 2.4GHz).

Concernant la configuration du noyau, tu ne pourras pas charger p4-clockmod car acpi-cpufreq est inclus directement dans le noyau (CONFIG_X86_ACPI_CPUFREQ=y).

Les choix de configuration de Linux sont :
y : dans le noyau.
m : en module
n : non compilé.

Si tu tiens vraiment à utiliser p4-clockmod, il faudra recompiler ton noyau.

Même Linus en fait la pub : [http://picasaweb.google.com/cschlaeger/JapanLinuxSymposium#5(...)].

Cet esprit potache de la part du créateur de Linux me fait toujours autant marrer.

Grâce aux GM (gentils modérateurs), la css est maintenant disponible directement sur linuxfr.org. Sur la page [ http://linuxfr.org/css.html], elle est accessible sous le nom opensuse.css.

Merci à NoNo.

Apparemment non (Je suis allé voir ta page perso).

Ca veut peut-être dire que les logiciels mal conçus et les codes plat de nouilles sont plutôt la norme que l'exception.

Oui, les uuid sont des champs stockés dans chaque système de fichiers, par exemple dans le superblock pour l'ext[2,3,4]. La commande sauvegarde tout le disque dur, du premier au dernier octet.

Rassure-toi (ou pas), ce n'était ni un éditeur ni une ssii. Simplement une boite avec un logiciel métier qui avait beaucoup vécu au gré des passages de prestataires, des vagues de licenciement et des demandes délirantes du marketing.

Bref c'était plutôt de l'ironie de la part de ceux qui devait essayer de faire tomber en marche le soft un jour de plus.

Du temps lointain ou je développais sous Windows, j'ai le souvenir que les fichiers d'aide pouvait être des pages web empaquetés...

Ah voila : html help workshop [http://msdn.microsoft.com/en-us/library/ms669985%28VS.85%29.(...)]. Ça permet de fabriquer des fichiers chm qui contiennent des pages html.
Par contre je ai aucune idée si ça fonctionne sur les windows modernes ou si ça peut lire des video en flash.

Le premier secteur de ton disque dur contient le MBR, c'est à dire un premier morceau du chargeur de démarrage ainsi que la table des partitions. Donc si tu sauvegardes ton disque complet avec dd if=/dev/sda ..., l'image contiendra ton bootloader et ta table de démarrage.

Aussi, ajoute un bs=4M pour que dd copie par bloc de 4Mo au lieu de 512 octets, ca ira plus vite.

How To Write Unmaintainable Code : [http://freeworld.thc.org/root/phun/unmaintain.html].

Comme ils disaient dans une boite ou j'ai passé quelques temps : Nos bugs d'aujourd'hui sont nos emplois de demain.

Je viens de mettre à jour la css, elle est toujours disponible au même endroit [http://pagesperso-orange.fr/bmo-perso/opensuse.css].

J'ai rajouté -webkit-border-radius et border-radius comme suggéré par Octabrain et Cyrille Pontvieux. Il y a pas mal d'informations à ce sujet sur [http://www.bloggingcss.com/en/tutorials/the-css3-border-radi(...)].

Il y a aussi les corrections pour les input text et la mise en page des commentaires indiquées par eggman. Les détails des changements sont dans le fichier.

Merci pour tes remarques,

Je viens de voir le bug du champ input en répondant aux commentaires, je vais corriger ça. Je vais tester aussi les modifications que tu suggères pour voir ce que ça donne.

C'est pas idiot ça. Je vais ajouter cette propriété en plus du -webkit-border-radius comme ça la css sera prête pour CSS3.

Ah mince, j'avais oublié l'indispensable capture d'écran pour les décideurs pressés !
Merci à toi.

L'option -soname c'est pour forcer le champ SONAME quand tu compiles une bibliothèque et c'est ce champ que tu retrouves en faisant un ldd sur un exécutable.

Pour forcer l'utilisation d'une version particulière de bibliothèque, il suffit de la lier directement avec le chemin complet.

Par exemple avec sizeof.c disponible ici [http://www.pccl.demon.co.uk/C/sizeof.c], si je compile comme ca :

gcc sizeof.c -o sizeof -lncurses

sizeof dépend de libncurses.so.5

Alors que si je compile comme ça :

gcc sizeof.c -o sizeof -Wl,/lib64/libncurses.so.6

sizeof dépend libncurses.so.6

Le schéma de partitions que tu envisages n'est pas possible car la table de partitions DOS ne peut contenir que 4 partitions primaires et seules celles-ci sont bootables.
Comme tu veux utiliser Mint comme distribution principale, tu peux faire quelque chose comme ça :

/dev/sda1 partition primaire de restauration windows
/dev/sda2 partition primaire vista
/dev/sda3 partition primaire linuxmint (avec l'attribut bootable)
/dev/sda4 partition étendue
/dev/sda5 disque logique data
/dev/sda6 disque logique debian
/dev/sda7 disque logique slitaz
/dev/sda8 disque logique swap

Pour booter debian et slitaz, il faudra éditer la configuration du grub de linuxmint.
10 à 15 Go pour chaque Linux suffise largement surtout si tu mets tes données dans data.
Et si tu veux faire de l'hibernation sous Linux, il vaut mieux avoir un swap de la taille de ta ram.
Enfin tu peux formater la partition data en ntfs au lieu de fat32, c'est accessible en lecture-écriture depuis Linux alors que la fat32 est limitée à des fichiers de 4Go.

Pour chiffrer un seul fichier, il y a aussi ccrypt [http://ccrypt.sourceforge.net/].
C'est bien pratique pour mettre quelques informations sensibles sur sa clef usb. Il existe même des binaires windows et mac osx, ce qui permet d'accéder à ces données à peu près partout.

Ce genre d'erreur peut aussi être du à un problème de câble SATA. C'est toujours prudent d'avoir des sauvegardes mais avant de jeter ton disque aux orties, tu peux peut-être essayer avec un autre câble.

Dans les PC industrielles, les câbles sata sont souvent collés au pistolet à colle car ils se débranchent très facilement (quoi qu'on commence à en trouver avec des ergots de rétention).