sur Gentoo, mencoder (distribué avec mplayer) bénéficie de plusieurs optimisation liées au CPU (MMX, SSE2 notamment) ou au GPU qu'Ubuntu ne propose probablement pas pour rester compatible avec la famille i386.
Il me semblait que mplayer détectait justement le processeur à l'exécution et d'activer les opérations MMC SSE & Co à l'exécution ?
Par exemple, tu ne peux pas faire ce que fait MapOSMatic (cf http://www.maposmatic.org/about/): imprimer des cartes dans un format classique papier.
Merci beaucoup pour le lien, je suis très impressioné par la puissance du service !!
Par contre si on compare 2^-256 au nombre de blocks de tous les fs en zfs dans le monde, alors le risque qu'une personne dans le monde ait des collisions n'est pas négligeable.
Si. Et heureusement pour tous les utilisateurs de cryptographie dans le monde (256 bits, la taille de clef recommandée... ). Les cryptologues estiment qu'une quantité de données de 2^64 bits est difficilement atteignable par quiconque actuellement, ça laisse du temps !
Une autre raison est la suivante : il y a environ 10^77 atomes dans l'univers, soit 2^255. Comme la Terre représente une partie infime de l'univers (il y a environ 10^50 atomes dans la Terre, 10^27 fois moins ! ), on a encore de la marge !
(notons toutefois qu'une fonction de hachage sur 256 bits aura des collisions sitôt 2^128 blocs utilisés et non pas 2^256, à cause du paradoxe des anniversaires)
le mieux c'est en effet de repartir du fichier de configuration de ta distribution, et de ne modifier que ce dont tu as besoin.
Ensuite, pour la compilation proprement dite, vu que tu es sous Ubuntu make-kpkg devrait faire l'affaire (il doit bien y avoir des tutoriels quelque part), l'intérêt c'est qu'il gère tout proprement (ajout dans grub, désinstallation si tu as fait une bêtise) en générant un paquet.
En gros, à la place de make, make install etc. tu fait make-kpkg --initrd --rootcmd fakeroot --append-to-version version_personnalisee kernel-image ; puis dpkg -i linux-image-2.6.**-version_personnalisee******.deb
Ensuite, ce n'est pas uniquement du vent que je fais. Oui, j'ai parlé d'un concept abstrait sur Setup, mais actuellement, Setup est capable d'installer des paquets, il résout les dépendances, il affiche tout un tas d'informations, il est même intégré à la future version 4 du site de Logram (http://v4dev.logram-project.org/packages-4-1.html , oui, c'est comme packages.debian.org, sauf qu'ici c'est encore en développement , et qu'au menu, on a des commentaires, une notation, des screenshots, etc).
Jayce sors de cet homme !!
---------> []
Pas pu me retenir, désolé, mais bon courage pour tes projets qui m'ont l'air bien plus prometteurs que MultiDeskOS, et merci pour ton journal j'ai appris une foultitude de trucs sur Koffice que j'ignorais totalement, ça me donne envie de m'y remettre sérieusement.
Merci beaucoup de ton avis, je ne savais en effet pas que les flottants n'étaient pas parallélisés. J'avais également entendu dire que les problèmes de concurrence dans l'accès au cache n'étaient pas bien gérés, ça doit dépendre en effet des applications.
Merci pour ton analyse et tes recommandations en tous cas !
Pour un (les ?) béotien(s) du PHP, pourrait-on avoir quelques explications ?
Même si leur apparence prête à réfléchir pour quiconque a une petite expérience de programmation, en quoi ces bouts de code sont-ils à éviter ?
En gros, que font-ils (pas facile à savoir quand on n'en a jamais fait), comment le font-ils mal et comment peut-on y remédier ?
Le mieux sans tutoriel c'est sans doutes de repartir du fichier de configuration du noyau fourni par ta distribution (/boot/config-2.6.trucmuche en général).
Les points importants dans une première approche sont précisés plus haut, à savoir sélectionner le bon processeur, choisir un noyau préemptible, à fréquence élevée, tout ceci se trouve dans les options "Processor type and features". Penser aussi à désactiver toute option de débuggage évidemment.
Ensuite, chaque option de configuration comporte quelques lignes de documentation, avec un petit coup de google c'est là qu'est le vrai tutoriel :-)
Enfin, en général une large majorité des options du noyau pour les distributions sont fournies sous formes de modules (et une large partie concerne les pilotes), ça n'impacte pas les performances, mais uniquement le temps de compilation.
Si tu veux enlever toutes les choses inutiles, la commande lshw liste le matériel présent sur ta machine et les modules nécessaires pour la faire fonctionner. Il est alors possible de compiler ces modules en dur dans le noyau et de désactiver l'initrd et même l'utilisation de modules tout court (mais c'est un peu hardcore et ça ne gagne quasiment qu'en temps de compilation).
Pour finir, là où on gagne encore plus selon l'utilisation qu'on veut faire de son noyau, c'est en utilisant par exemple des patches externes pour la réactivité (c'est ce que fait liquorix par exemple). À savoir qu'on risque de perdre en stabilité, et que la méthode à suivre est à trouver dans la documentation du patch en question.
make bzImage && make modules && make modules_install && cp arch/x86/boot/bzImage /boot/linux-image-2.6.31.2
euh pourquoi tu n'utilises pas make-kpkg plutôt ? C'est prévu pour prendre les sources vanilla, et en deux commandes (make-kpkg clean && make-kpkg --initrd kernel_image ) tu obtiens un paquet debian qui s'installe tout seul, en faisant attention aux entrées de grub et à la génération de l'initrd, et on peut le désinstaller facilement sans se poser de question.
dans la même veine que le journal, je viens de tester le dépôt liquorix ( liquorix.net ) qui propose un noyau à la pointe, orienté desktop, avec un certain nombre de patches pour améliorer la réactivité (par exemple ils ont intégré le BFS de Kon Kolivas :-), etc.
J'ai eu exactement les mêmes impressions, sur un PC un peu chargé (peu de RAM) la joie de retrouver la réactivité, par exemple rien que changer de fenêtre sous KDE ne prend plus 2 secondes mais c'est instantané... Bref c'est un bon compromis je pense pour qui ne veut pas se casser les pieds avec une recompilation (quoiqu'avec make-kpkg c'est un jeu d'enfant).
De nombreux artistes affiliés ne sont pas au courant de leurs devoirs, et diffusent des œuvres sous licence libre. La licence libre est alors caduque.
Alors celle-là par contre je ne vois pas trop d'où elle sort ? Si l'artiste signe deux contrats privés qui se contredisent l'un l'autre c'est son problème, pas celui de l'auditeur qui l'écoute sous une licence libre (qui est de bonne foi qui plus est).
La Sacem peut demander des dommages et intérêts à l'artiste (quoique est-ce vraiment son intérêt ? une société qui attaquerait ses membres ? restons dans le juridique) pour rupture abusive de contrat, mais je ne vois pas en quoi l'autre contrat (la licence libre) serait automatiquement invalidé. Ça me rappelle Amazon qui a retiré les bouquins d'Orwell pour de sombres raisons, similaires, mais qui a dû indemniser ses clients (et pour certains l'épouvantail juridique les a fait payer beaucoup, c'est donc qu'ils ne se sentaient pas très droits).
Euh quand même, ces images sont issues d'un dessin animé/film d'animation. Alors le résultat n'est pas forcément étonnant : personne ne dirait que le jpeg est pourri uniquement parce qu'il est complètement naze face à png quand il s'agit de manipuler des images contenant des graphiques ou des traits précis, la transformation ajoutant des artefacts dans tous les sens. Par contre, pour ce qui est des photos il est bien plus intéressant.
Ici espérons que ce cas soit pathologique pour theora, il est possible que ce codec ne soit pas intéressant pour les dessins animés mais révèle tout son potentiel pour les films.
Mais OneSwarm est-il réellement anonyme dans le sens où Freenet est conçu pour que même les amis ne puissent pas savoir ce que tu télécharges ? Par exemple sous Freenet, les échanges avec les amis sont chiffrés (c'est la base), mais les morceaux de fichiers qu'on leur demande le sont également, et seul l'émetteur et le destinataire ont la clef (donc les amis sur le chemin ne font que router des paquets chiffrés qu'ils ne peuvent déchiffer, et les surchiffrent pour l'échange avec leur ami).
J'ai l'impression que sur Oneswarm, les requêtes ne sont pas anonymes vis-à-vis des amis, on leur demande un bout de tel fichier (bien précis) au lieu de lui demander un chunk de données chiffrées qu'il trouve quelconque. Auquel cas la différence de performances s'explique largement, le but de Freenet étant de toutes façons l'anonymat et la résistance à la censure (si la source du contenu disparaît, est-il toujours disponible ?). Toutefois ses performances se sont apparemment largement améliorées (téléchargement à quelques centaines de ko/s une fois qu'on est bien inséré dans le réseau d'après ce qu'on m'a dit).
Euh mis à part la consommation (largement à l'avantage du chipset NVidia), l'essentiel des améliorations de performances est lié à des applications graphiques (jeux et vidéo HD), ce qui est peu étonnant vu la très bonne qualité des puces graphiques NVidia par rapport à un vieillissant chipset Intel.
Pour ce qui est du calcul brut en revanche, des entrées/sorties, et en bref de tout ce qui touche spécifiquement le processeur, la différence est nulle.
d'autant qu'on ne sait pas d'après ton journal de quelle carte mère il s'agit.
Tiens tant qu'on parle de hardware, l'influence de la carte mère est si importante que ça pour tirer les performances vers le haut ?
autant j'arrive à peu près à me faire une idée sur les processeurs (fréquence, cache, divers benchmarks représentatifs des calculs qui m'intéressent) ou les cartes graphiques, autant sur les cartes mères c'est plus difficile. Aussi merci à qui éclairera un peu ma lanterne !
Rien ne t'empêche de réserver en plusieurs fois en faisant tes correspondance "à la main".
Sauf que prendre un trajet d'un seul coup plutôt que de prendre 3 trajets revient bien moins cher (c'est déjà de l'ordre de plusieurs euros avec une seule correspondance)
Dans le temps (il n'y a pas si longtemps que ça !) la SNCF avait dans tous les grands dépôts (genre Paris, Lyon, Bordeaux) en France un train prêt à partir, avec un conducteur d'astreinte, au cas où un train en circulation tomberait en panne. Comme ça, ce genre de problème se limitait à un retard maximal égal au temps qu'un train mettait à venir du dépôt le plus proche.
Hélas l'obligation de résultat de la SNCF ne concerne pas les délais, mais seulement l'arrivée à bon port, et l'idée de ce genre de service a complètement disparu...
Dans l'exemple de ce journal, vous allez voir qu'en plus elle ne remboursera rien au prétexte que ce n'est pas de sa faute si le train à déraillé, c'était une cause externe !
Le seul test que dit avoir fait Con Kolivas, c'est un make -j4 avec BFS vs un make -j* sur un processeur à quatre cœurs et il affirme que c'est plus rapide (on peut le croire, mais dans quelle proportion, ça il ne dit pas).
Après pour trancher, il faudrait savoir quels tests sont représentatifs d'une utilisation desktop (pour moi, si le son ne saute pas quand je joue à wesnoth, sur une vieille config certes, ce serait un gros plus :-), mais la latence du pipe d'un ordonnanceur, ça me parle moins, et à l'inverse même si je développe un peu un gain de 0.3% dans make m'importe peu), enfin bref trouver un benchmark qui représente convenablement 'l'expérience utilisateur' est un troll extrêmement velu :-)
eh bien inkscape, c'est pour les SVG, qui sont du xml non ? on les édite donc avec un éditeur de texte, c'est tout simple !
-------------> []
[] ------>
Sans rire, il s'agit amha d'insertion de texte sur une image, et en effet inkscape est sans doutes mieux adapté que gimp pour tous les effets possibles sur du texte.
[^] # Re: Le noyau fausse tout
Posté par khivapia . En réponse au journal Linux, Gentoo, et gcc dans un bateau.... Évalué à 3.
Il me semblait que mplayer détectait justement le processeur à l'exécution et d'activer les opérations MMC SSE & Co à l'exécution ?
[^] # Re: Petite reflexion
Posté par khivapia . En réponse au journal OpenStreetMap dans le Monde. Évalué à 2.
Merci beaucoup pour le lien, je suis très impressioné par la puissance du service !!
[^] # Re: Collisions
Posté par khivapia . En réponse au journal Enlarge your ZFS pool. Évalué à 6.
Si. Et heureusement pour tous les utilisateurs de cryptographie dans le monde (256 bits, la taille de clef recommandée... ). Les cryptologues estiment qu'une quantité de données de 2^64 bits est difficilement atteignable par quiconque actuellement, ça laisse du temps !
Une autre raison est la suivante : il y a environ 10^77 atomes dans l'univers, soit 2^255. Comme la Terre représente une partie infime de l'univers (il y a environ 10^50 atomes dans la Terre, 10^27 fois moins ! ), on a encore de la marge !
(notons toutefois qu'une fonction de hachage sur 256 bits aura des collisions sitôt 2^128 blocs utilisés et non pas 2^256, à cause du paradoxe des anniversaires)
[^] # Re: D'après cpufreq-info
Posté par khivapia . En réponse au message Comment charger des driver cpu : p4-clockmod et acpi-cpufreq. Évalué à 2.
Ensuite, pour la compilation proprement dite, vu que tu es sous Ubuntu make-kpkg devrait faire l'affaire (il doit bien y avoir des tutoriels quelque part), l'intérêt c'est qu'il gère tout proprement (ajout dans grub, désinstallation si tu as fait une bêtise) en générant un paquet.
En gros, à la place de make, make install etc. tu fait make-kpkg --initrd --rootcmd fakeroot --append-to-version version_personnalisee kernel-image ; puis dpkg -i linux-image-2.6.**-version_personnalisee******.deb
# Pour un site qui traite d'Hadopi
Posté par khivapia . En réponse au journal Quid de la (dés)information concernant les TIC au Lycée.. Évalué à 5.
Et tu auras toutes les infos que tu voudras (un peu biaisées, mais bien analysées).
[^] # Re: ?
Posté par khivapia . En réponse au message quézako ???. Évalué à 2.
[^] # Re: Fais un blog.
Posté par khivapia . En réponse au journal Pourquoi j'utilise et utiliserai KDE et KOffice 2. Évalué à 2.
Jayce sors de cet homme !!
---------> []
Pas pu me retenir, désolé, mais bon courage pour tes projets qui m'ont l'air bien plus prometteurs que MultiDeskOS, et merci pour ton journal j'ai appris une foultitude de trucs sur Koffice que j'ignorais totalement, ça me donne envie de m'y remettre sérieusement.
[^] # Re: Dimensionnement
Posté par khivapia . En réponse au message "load average" et dimensionnement d'un serveur. Évalué à 2.
Merci pour ton analyse et tes recommandations en tous cas !
[^] # Re: Dimensionnement
Posté par khivapia . En réponse au message "load average" et dimensionnement d'un serveur. Évalué à 2.
Merci
# Explications ?
Posté par khivapia . En réponse au journal ha le php et ses élites. Évalué à 10.
Même si leur apparence prête à réfléchir pour quiconque a une petite expérience de programmation, en quoi ces bouts de code sont-ils à éviter ?
En gros, que font-ils (pas facile à savoir quand on n'en a jamais fait), comment le font-ils mal et comment peut-on y remédier ?
Merci
[^] # Re: Un tutoriel ??
Posté par khivapia . En réponse au journal Passage du noyau Debian 2.6.30-2 au noyau Vanilla 2.6.31-2. Évalué à 5.
Les points importants dans une première approche sont précisés plus haut, à savoir sélectionner le bon processeur, choisir un noyau préemptible, à fréquence élevée, tout ceci se trouve dans les options "Processor type and features". Penser aussi à désactiver toute option de débuggage évidemment.
Ensuite, chaque option de configuration comporte quelques lignes de documentation, avec un petit coup de google c'est là qu'est le vrai tutoriel :-)
Enfin, en général une large majorité des options du noyau pour les distributions sont fournies sous formes de modules (et une large partie concerne les pilotes), ça n'impacte pas les performances, mais uniquement le temps de compilation.
Si tu veux enlever toutes les choses inutiles, la commande lshw liste le matériel présent sur ta machine et les modules nécessaires pour la faire fonctionner. Il est alors possible de compiler ces modules en dur dans le noyau et de désactiver l'initrd et même l'utilisation de modules tout court (mais c'est un peu hardcore et ça ne gagne quasiment qu'en temps de compilation).
Pour finir, là où on gagne encore plus selon l'utilisation qu'on veut faire de son noyau, c'est en utilisant par exemple des patches externes pour la réactivité (c'est ce que fait liquorix par exemple). À savoir qu'on risque de perdre en stabilité, et que la méthode à suivre est à trouver dans la documentation du patch en question.
[^] # Re: Ras le bol.
Posté par khivapia . En réponse au journal Le scandale. Évalué à 2.
[^] # Re: séparation
Posté par khivapia . En réponse au journal Passage du noyau Debian 2.6.30-2 au noyau Vanilla 2.6.31-2. Évalué à 10.
euh pourquoi tu n'utilises pas make-kpkg plutôt ? C'est prévu pour prendre les sources vanilla, et en deux commandes (make-kpkg clean && make-kpkg --initrd kernel_image ) tu obtiens un paquet debian qui s'installe tout seul, en faisant attention aux entrées de grub et à la génération de l'initrd, et on peut le désinstaller facilement sans se poser de question.
[^] # Re: séparation
Posté par khivapia . En réponse au journal Passage du noyau Debian 2.6.30-2 au noyau Vanilla 2.6.31-2. Évalué à 4.
J'ai eu exactement les mêmes impressions, sur un PC un peu chargé (peu de RAM) la joie de retrouver la réactivité, par exemple rien que changer de fenêtre sous KDE ne prend plus 2 secondes mais c'est instantané... Bref c'est un bon compromis je pense pour qui ne veut pas se casser les pieds avec une recompilation (quoiqu'avec make-kpkg c'est un jeu d'enfant).
[^] # Re: Ras le bol.
Posté par khivapia . En réponse au journal Le scandale. Évalué à 2.
Alors celle-là par contre je ne vois pas trop d'où elle sort ? Si l'artiste signe deux contrats privés qui se contredisent l'un l'autre c'est son problème, pas celui de l'auditeur qui l'écoute sous une licence libre (qui est de bonne foi qui plus est).
La Sacem peut demander des dommages et intérêts à l'artiste (quoique est-ce vraiment son intérêt ? une société qui attaquerait ses membres ? restons dans le juridique) pour rupture abusive de contrat, mais je ne vois pas en quoi l'autre contrat (la licence libre) serait automatiquement invalidé. Ça me rappelle Amazon qui a retiré les bouquins d'Orwell pour de sombres raisons, similaires, mais qui a dû indemniser ses clients (et pour certains l'épouvantail juridique les a fait payer beaucoup, c'est donc qu'ils ne se sentaient pas très droits).
[^] # Re: No comment
Posté par khivapia . En réponse au journal Tests concrets de Theora 1.1. Évalué à 0.
Ici espérons que ce cas soit pathologique pour theora, il est possible que ce codec ne soit pas intéressant pour les dessins animés mais révèle tout son potentiel pour les films.
[^] # Re: Freenet
Posté par khivapia . En réponse au journal La technologie permettant à Madame Michu de contourner Hadopi déjà disponible!. Évalué à 2.
J'ai l'impression que sur Oneswarm, les requêtes ne sont pas anonymes vis-à-vis des amis, on leur demande un bout de tel fichier (bien précis) au lieu de lui demander un chunk de données chiffrées qu'il trouve quelconque. Auquel cas la différence de performances s'explique largement, le but de Freenet étant de toutes façons l'anonymat et la résistance à la censure (si la source du contenu disparaît, est-il toujours disponible ?). Toutefois ses performances se sont apparemment largement améliorées (téléchargement à quelques centaines de ko/s une fois qu'on est bien inséré dans le réseau d'après ce qu'on m'a dit).
[^] # Re: Bien plus efficace
Posté par khivapia . En réponse au journal La technologie permettant à Madame Michu de contourner Hadopi déjà disponible!. Évalué à 1.
[^] # Re: low cost, low noise, low consumption
Posté par khivapia . En réponse au journal Nouveau pc et remise à niveau. Évalué à 2.
Pour ce qui est du calcul brut en revanche, des entrées/sorties, et en bref de tout ce qui touche spécifiquement le processeur, la différence est nulle.
[^] # Re: C'est trop cher....
Posté par khivapia . En réponse au journal Nouveau pc et remise à niveau. Évalué à 2.
Tiens tant qu'on parle de hardware, l'influence de la carte mère est si importante que ça pour tirer les performances vers le haut ?
autant j'arrive à peu près à me faire une idée sur les processeurs (fréquence, cache, divers benchmarks représentatifs des calculs qui m'intéressent) ou les cartes graphiques, autant sur les cartes mères c'est plus difficile. Aussi merci à qui éclairera un peu ma lanterne !
[^] # Re: ...
Posté par khivapia . En réponse au journal SNCF : Antibes-Grenoble en 16h, c'est possible.. Évalué à 3.
Sauf que prendre un trajet d'un seul coup plutôt que de prendre 3 trajets revient bien moins cher (c'est déjà de l'ordre de plusieurs euros avec une seule correspondance)
[^] # Re: ...
Posté par khivapia . En réponse au journal SNCF : Antibes-Grenoble en 16h, c'est possible.. Évalué à 1.
Elles sont d'ailleurs valables exactement 3 (trois) minutes si on la pose le matin pour le soir.
[^] # Re: helas
Posté par khivapia . En réponse au journal SNCF : Antibes-Grenoble en 16h, c'est possible.. Évalué à 2.
Hélas l'obligation de résultat de la SNCF ne concerne pas les délais, mais seulement l'arrivée à bon port, et l'idée de ce genre de service a complètement disparu...
Dans l'exemple de ce journal, vous allez voir qu'en plus elle ne remboursera rien au prétexte que ce n'est pas de sa faute si le train à déraillé, c'était une cause externe !
# Ce ne sont tout de même pas les mêmes benchs
Posté par khivapia . En réponse au journal BFS : La revanche. Évalué à 6.
Après pour trancher, il faudrait savoir quels tests sont représentatifs d'une utilisation desktop (pour moi, si le son ne saute pas quand je joue à wesnoth, sur une vieille config certes, ce serait un gros plus :-), mais la latence du pipe d'un ordonnanceur, ça me parle moins, et à l'inverse même si je développe un peu un gain de 0.3% dans make m'importe peu), enfin bref trouver un benchmark qui représente convenablement 'l'expérience utilisateur' est un troll extrêmement velu :-)
[^] # Re: Si tu as enregistré l'XCF...
Posté par khivapia . En réponse au journal Un coup de gueule contre Gimp 2.6. Évalué à 3.
-------------> []
[] ------>
Sans rire, il s'agit amha d'insertion de texte sur une image, et en effet inkscape est sans doutes mieux adapté que gimp pour tous les effets possibles sur du texte.