Franchement le message d'avertissement de ne pas exécuter les trucs téléchargés sans être sûr de leur provenance arrive beaucoup trop tard : c'est pas une fois téléchargé qu'on va vérifier, ça devrait être avant. Donc du coup, ce genre de message ne fait qu'agacer l'utilisateur, qui répond "**tain oui, c'est pour ça que je l'ai téléchargé, arrête de me casser les pieds" à la questions 'êtes vous sûr ..."
Tu ferais alors bien de les former à java, qui a l'avantage (pour vous) de ressembler à C# et pour la communauté d'être un langage libre et librement implémenté.
D'ailleurs à ce sujet il existe bon nombre de technologies P2P écrites en java (similaire à C# pour ce qui est de performances de leurs implémentations me semble-t-il), donc si la performance était un problème ce serait plutôt au niveau du protocole (d'ailleurs en règle générale les problèmes de performances des applications peer-to-peer sont liées à la limitation de la bande passante).
Enfin pour répondre à la question de ton journal, nombre de logiciels peer-to-peer regorgent de fonctionnalités à implémenter. Par exemple Freenet (écrit en Java) www.freenetproject.org qui semble à peu près convenir à toutes tes exigences.
Cela dit tout bon dépôt devrait fournir à ses utilisateurs la commande magique à taper pour intégrer la clef. C'est d'ailleurs ce qu'ils font en général. Ouvrir une console, taper une commande par copier coller, ce n'est pas la mort non plus ! (qui n'a jamais fait démarrer/exécuter sous windows ?)
Merci pour ce post très informatif, si chromium ne permet pas de filtrage a priori du téléchargement des données, ça va fort peu m'intéresser (eh oui certaines connexion partagées sont lentes... et certains scripts et autres flasheries ont un rapport lourdeur/utilité tendant vers l'infini, sans parler des publicités).
Je nuancerais toutefois la phrase du pdg de Google : il n'a pas dit
Seuls les criminels se soucient de protéger leur données personnelles. Mais plutôt "Si vous avez fait quelque chose et que vous voulez que personne ne le sache, peut être devriez vous commencer par ne pas le faire", ce qui peut s'interpréter (légèrement) différemment. Rappelons qu'il s'agit du même patron de la même boîte qui avait déréférencé CNet suite à un article de ses journalistes montrant tout ce qu'on pouvait retrouver sur lui en utilisant le même moteur...
Et méditons ces deux phrases : If privacy is outlawed, only outlaws will have privacy. (Phil Zimmermann, créateur de PGP) (qu'on peut traduire par "Si la vie privée devient hors la loi, seuls les hors-la-loi auront une vie privée")
et plus prosaïquement, "Attention à cette tendance de croire que ce que l'on souhaite cacher est forcément suspect. Si on accroche des rideaux aux fenêtres de son salon, ce n'est pas pour assassiner sa femme en toute impunité. " (Maître Eolas en chat sur le site du Nouvel Observateur)
Je plussoie ! La limitation de vitesse devrait être adaptée aux conditions de circulation :
faire du 130 en colonne par 3 (ie sans que personne ne respecte les distances de sécurité parce que dès qu'un trou se fait quelqu'un s'y met, tel l'électron dans le transistor) c'est clairement que tout le monde roule trop vite (pourtant c'est autorisé). Faire du 180 la nuit par beau temps sur une autoroute où il n'y a personne est interdit et pourtant beaucoup moins dangereux. Enfin le détecteur automatique de feux rouges brûlés ne constatera pas le camion qui arrive à toute blende derrière et qui oblige à le brûler (cas vécu à l'auto-école !)...
De même, pourquoi limiter à 30 les abords des écoles le dimanche et en plein mois d'août ?!?
On voit déjà des limitations variables selon la période (par exemple la route Hyères Toulon en arrivant sur Toulon, limitation à 70 en dehors des périodes de pointe, à 50 sinon), ce qui est à généraliser.
Enfin une petite statistique : http://villemin.gerard.free.fr/CultureG/Accident.htm rechercher le mot Allemagne. Les allemands roulent plus vite qu'en France (limitation à 100 au lieu de 90, autoroutes illimitées en grande partie à 120 sinon, limitation à 60 en ville, pas d'indication de limitation de vitesse en sortie d'autoroute là où parfois en France les bretelles sont limitées à 30) Pourtant, le nombre de morts sur la route chez eux est deux fois moins important qu'en France, cherchez l'erreur... Ou sur Wikipedia http://fr.wikipedia.org/wiki/Pr%C3%A9vention_et_s%C3%A9curit(...) pour des statistiques plus récentes, qui montrent qu'il y a sensiblement autant de morts en Allemagne qu'en France, pour une population 25 à 30% supérieure...
Normalement les algorithmes cryptographiques sont dimensionnés pour des capacités de calcul inatteignables avant plusieurs dizaines d'années selon la loi de Moore.
Il est relativement facile de dimensionner les algorithmes face à des attaques par force brute : par exemple dans le cas des algorithmes symétriques, augmenter la taille de la clef d'un bit nécessite de doubler la puissance de calcul pour la trouver. Quand on sait que la puissance de calcul pour un même prix double tous les 18 mois environ, qu'un PC actuel quadricœur tourne à 4*2GHz = 2^35 opérations par seconde (en majorant un chiffrement par un cycle ce qui est un ordre de grandeur cohérent même face à certaines implémentations spécialisées type bitslice & co), soit "35 bits".
Une puce telle que celle qui est présentée ici ne permet de réaliser finalement que 48/4 = 12 fois plus de calcul par seconde, soit moins de "39 bits". On ne gagne en fait pas un facteur si grand que ça : remplacer tous les processeurs quadri-cœurs par des processeurs 48 cœurs revient à diminuer la sécurité des clefs actuelles de 4 bits, ce qui est peu finalement (les recommandations minimales sont à 128 bits actuellement, et les plus gros calculs réalisés par le monde académique font au maximum 2^60 opérations). Sans compter que ces processeurs sont loin d'être sortis, il y a des chances que leur sortie soit prévisible par la loi de Moore...
Le gros intérêt d'augmenter la puissance de calcul est plutôt pour les attaques dictionnaires de mot de passe : par rapport à une clef cryptographique dimensionnée pour tenir longtemps, un mot de passe est généralement choisi pour être le plus simple possible modulo les exigences de ce casse-pieds d'administrateur... qui ne peut pas non plus imposer à chacun de retenir des mots de passe aléatoires...
Je n'ai pas lu tes liens, mais est-ce que le Tile64 possède des cœurs capables de se couper s'ils ne sont pas utilisés ?
Eh bien lis les et tu verras que à 700MHz, la puce Tile64 ne consomme que 22 W tous cœurs actifs, et que chaque cœur peut plonger dans un mode endormi.
Encore une réponse pour te signaler qu'en fait le noyau 2.6.32-rc8 est dans unstable.
Un simple aptitude install linux-image-2.6.32-rc8-amd64 te donnera le noyau le plus récent qui soit, si tu as activé les dépôts unstable évidemment.
Attention, risque de freeze (mais le pilote marche un peu. J'ai réussi à scanner les réseaux sans fil avec ce pilote avant que la machine se mette à tourner dans le vide)
J'ai le même problème avec le chipset 4312 (4315 en vrai), mais j'arrive à le faire fonctionner avec ndiswrapper en suivant un des nombreux tutos sur le web, et il paraît qu'il devrait marcher avec le noyau 2.6.32. Debian compte fournir un noyau 2.6.32 dans la prochaine stable, donc il y a des chances qu'il arrive dans unstable assez vite (il devrait sortir sous peu)
(après, il y a des boulots un peu particulier ou c'est autorisé il me semble, genre pour devenir ingénieur au CEA, pour s'assurer qu'on n'embauche pas des méchants terroristes voleurs d'uranium et de PI).
Il s'agit des enquêtes d'habilitations, menées dans le cadre prévu par la loi. Elles concernent également toute personne qui est amenée à travailler sur des données sensibles pour l'état (par exemple des fournisseurs de l'état), et plus généralement un nombre incroyable de métiers sont soumis à enquête (par exemple tous les métiers de la sécurité physique, avec port d'arme, ou bien le travail sur un aéroport, etc.)
D'un autre côté, en France, les banques voient bien que le type qui est capable de mettre x% de son salaire sur des comptes épargne chaque mois sans avoir lapression de rembourser quoi que ce soit sera capable de bien gérer le prêt qu'elle va lui faire. Elles ne sont pas stupides non plus.
En revanche, les banques préfèrent largement les cigales que les fourmis, c'est-à-dire que quelqu'un qui prend beaucoup de prêts et dépense son argent à tout va sera moins âpre au gain et un pigeon client plus intéressant.
Les régions les plus développées représentent 18,3 % de la population en 2007 contre 81,7 % pour les régions les moins développées.
Alors sans préciser ce qu'on appelle les régions les plus développées (quel est le critère ?), cette phrase veut juste dire que les 18,3% les plus développés de la population mondiale représentent très exactement 18,3% de la population, c'est-à-dire que ça apporte une quantité d'information nulle. On pourrait dire aussi que les régions les plus développées représentent 99% de la population, ce sera toujours aussi vrai tant que je me cantonne à un "plus développées" aussi fumeux (ben oui, les 99% les plus développés sont toujours plus développés que les 1% restant...)
Faudrait aller voir le rapport de l'ONU (ça apparaît d'ailleurs pas clairement dedans mais j'ai pas le temps de creuser) pour voir ce que la notion recouvre, mais un manque de précision pareil sur wikipedia est navrant.
Et techniquement, je n'ai toujours pas compris pourquoi il avait reinventer une roue voilee
Techniquement ça ne se justifie pas, maintenant commercialement ils ne pouvaient tout de même pas espérer que les vendeurs de téléphones mobiles (aka les fournisseurs de téléphonie mobile et de tous les services qui vont avec) allaient tirer une balle dans le pied de l'apport que représente pour eux des téléphones verrouillés (donc sur lesquels il reste difficile de bidouiller), comme par exemple la difficulté d'ajouter des sonneries sans les payer cher, le blocage de la redirection de la connexion à internet (vous vous rappelez de l'iphone dernière version, qui permet ça, joie, pour 30€ par mois supplémentaires (gasp)), la mise en avant de tous les services inutiles et payants, ainsi que l'inévitable page de pub à l'allumage (qui n'a pas son logo Orange/SFR/Bouygues/Itineris/... (TGM)) ? Sans oublier la possibilité de développer un "Market" qui ne sera pas pollué par les inévitables applications gratuites qu'une plate-forme ouverte permettrait de télécharger et d'installer librement, dans le cas de google il faut déjà les porter...
Une question simple : est-ce que le téléphone me laisse l'accès à un compte root sans hacking (profiter d'une faille dans un logiciel, type dépassement de tampon, qui sera comblée un jour) ?
Techniquement sinon, je ne comprends pas non plus les innombrables restrictions sur l'ersatz de connexion, dite 'connexion à internet' qui est actuellement délivrée par les opérateurs 3G. Et je ne parle même pas des facturations...
(tiens tant qu'on est dans les bizarreries, il y a en Allemagne des forfaits qui ne comprennent pas l'envoi de sms, et où en envoyer sms coûte 19ct. Le truc marrant, c'est que quand on passe une frontière avec, la réglementation européenne sur les coûts des sms transfrontaliers les bride à 13ct maximum... je la refais, envoyer un sms de l'étranger avec un téléphone national coûte 35% moins cher que de l'envoyer du national au national.)
Je plussoie. N'ayant pas les moyens de déposer un brevet, un inventeur à tout intérêt à présenter son produit à une exposition publique, et à prendre quelques photos et témoignages pour être sûr qu'à défaut de lui profiter exclusivement à lui, elle profite au plus grand nombre sans appropriation par un autre.
Perl, Python et Ruby sont des gros bousins que personne de sensé ne veut compiler, car la sémantique de ces langages est une horreur pour tout écrivain de compilateurs (attention, je ne dis pas que les langages sont des horreurs, juste leur sémantique).
D'un autre côté une fois qu'on a un interpréteur correct, c'est qu'on a réussi à appréhender la sémantique justement... Et de là à en écrire un compilateur (au moins vers une machine virtuelle), la marche est moins haute.
D'ailleurs comme tu le dis il existe des compilateurs pour langages de script vers du byte code (une référence se trouve ici, pour python 2.5.2 http://www.python.org/doc/2.5.2/lib/bytecodes.html ). Les opérations d'icelui sont naturelles pour un langage de bas niveau, et ne sont pas "beaucoup" plus haut niveau que de l'assembleur pur. Mis à part un linker il ne manque pas grand-chose au niveau analyse sémantique pour compiler finalement complètement le langage vers du code machine.
Go doit pouvoir être utilisé pour de la programmation système donc c'est un langage compilé et pas interprété.
La gestion de la mémoire doit être automatique (garbage collector)
http://fr.wikipedia.org/wiki/Programmation_syst%C3%A8me
S'il faut un langage compilé pour obtenir de meilleures performances, pourquoi en faire un langage à gestion automatique de mémoire ? plutôt que d'utiliser de simples aides à la gestion comme les pointeurs intelligents, qui n'impactent pas les performances mais gardent la souplesse et la puissance d'une gestion manuelle ?
Linus Torvalds disait qu'il ne voulait pas de C++ dans le noyau Linux car il a tendance à cacher la gestion de la mémoire, qui est un élément trop important pour être laissé à de simples algorithmes. En programmation système c'est la même chose en général (gestion fine des ressources, la mémoire en particulier en fait partie).
En plus avec un garbage collector, le côté "temps réel" est beaucoup plus délicat à assurer (typiquement on a beaucoup de mal à régler le moment où il doit se déclencher et les mauvais cas sont fréquents).
Ça me paraît donc un peu aninomique, surtout qu'en compilant vite (ce qui est un objectif prioritaire du langage) on ne pourra pas profiter de beaucoup d'optimisations de la part du compilateur.
Ça s'apparente donc plutôt une sorte de langage de script compilé, avec une syntaxe proche du C. Mais alors les langages de scripts les plus utilisés sont vraiment si lents que ça par rapport à du code compilé en natif mais avec peu d'optimisation ? (la Faq sur le langage parle de python en disant que ce n'est pas efficace, les développeurs Python devraient apprécier ; il devrait être possible de développer un compilateur python rapide non ? ) http://golang.org/doc/go_lang_faq.html
Bref je ne comprends pas trop la position du langage par rapport à ses concurrents, au niveau des performances voulues/atteintes. En revanche les idées derrière l'implémentation de la concurrence sont intéressantes.
Il est vrai que le monopole constitué au USA ne concernera pas les grands fournisseurs de base de données européens comparables.
On me souffle dans l'oreillette qu'Oracle est leader sur les solutions de bases de données en Europe également, marché sur lequel la Commission Européenne veille à garder une concurrence saine.
La Commission peut tout simplement interdire à une société d'agir sur le marché européen, laissant toute la place à une nouvelle concurrence, ou bien infliger des amendes dissuasives.
Pour illustrer ça, voici deux codes qui calculent exactement la même chose (un crible d'Eratosthene, un des plus anciens algorithmes s'il en est :-) D'un point de vue algorithmique tout se passe de la même façon, d'un point de vue calculs ils sont très différents.
Sur un intel atom N270 (1.6GHz), la différence est flagrante pour les tailles les plus grosses : (tous deux sont compilés avec gcc 4.3.4 -O3 ; avec gcc-4.4.2 on gagne à peu près 5 à 8 % dans les deux cas)
time ./cache_sieve > result
1234567890
real 0m53.146s
user 0m48.663s
sys 0m0.164
time ././basic_sieve > result
1234567890
real 2m43.930s
user 2m29.473s
sys 0m3.760s
(je vous recommande de rediriger la sortie vers un fichier pour bien mesurer le temps de calcul, sinon tout sera pollué par le temps d'affichage dans la console).
Notons que les accès mémoire du crible d'Eratosthene basique sont relativement simples, et sans doutes faciles à prédire et donc à optimiser par le compilateur et les mécanismes de prefetch du processeur. Dans des applications plus complexes, le gain d'une implémentation optimisée serait certainement encore plus important.
Peu : vu tout le marketing qu'on fait les fabricants de CPU pour expliquer que maintenant, les cores pouvaient être désactivés indépendamment s'ils n'étaient pas utilisés (id est un calcul monothread ne fera pas activer l'ensemble des 4 cœurs si 4 cœurs il y a), à mon avis s'ils réussissaient à désactiver carrément certaines unités à l'intérieur de chaque core ils en feraient une publicité monstre.
En plus ça doit être extrèmement difficile de désactiver certaines unités pendant un calcul, car les transitions entre activité et inactivité donc réduction d'énergie possible sont très très courtes ! Quand on voit qu'un CPU met selon powertop quelques centaines de µs à changer d'état, on se dit que ce n'est pas gagné : en 100 µs un CPU a calculé 100 000 instructions, ce qui est énorme.
Le mieux c'est en fait d'utiliser les outils de profilage de code à la gcov.
Selon le manuel de gcc lui-même (si jamais vous l'avez installé à partir des sources), ils annoncent tout de go une augmentation de la vitesse de compilation de 7% rien qu'en activant ce switch.
Par contre ça a l"inconvénient de nécessiter une passe de compilation supplémentaire dans le cas de gcc, et des tests représentatifs dans les autres cas.
Quand on développe un code on réalise toujours quelques tests pour s'assurer des gains de performance quand on optimise une partie critique, il ne doit pas falloir beaucoup de travail pour les fournir proprement et ainsi être en mesure d'optimiser à fond grâce à gcov les parties du code les plus sensibles.
Graphic Magic, je ne sais pas si ça a un rapport avec ImageMagik que j'utilise mais je suis sur que madame michou ne l'utilisera jamais.
Pas sûr qu'elle ne l'utilisera pas sans s'en rendre compte : les logiciels de gestion de photos à la Gwenview sous Kde permettent des traitements par lot d'opérations simples (comme le redimensionement justement) avec une interface clickodrome sympa et tout. Ça n'utilise sans doutes pas graphic magic ni imagemagik, mais des programmes similaires. On peut donc s'attendre à ce qu'elle bénéficie du même genre d'amélioration des performances.
[^] # Re: j'espère...
Posté par khivapia . En réponse au journal Conditions de ventes et autres débilités. Évalué à 3.
D'un autre côté si tu ne vois rien à 200 m tu ne vas pas non plus rouler à 180, faut pas exagérer non plus...
[^] # Re: Mais oui ...
Posté par khivapia . En réponse au journal MALWARE LINUX. Évalué à 3.
[^] # Re: Pas un problème
Posté par khivapia . En réponse au journal MALWARE LINUX. Évalué à 4.
[^] # Re: Brevet
Posté par khivapia . En réponse au journal Application de P2P moderne. Évalué à 4.
D'ailleurs à ce sujet il existe bon nombre de technologies P2P écrites en java (similaire à C# pour ce qui est de performances de leurs implémentations me semble-t-il), donc si la performance était un problème ce serait plutôt au niveau du protocole (d'ailleurs en règle générale les problèmes de performances des applications peer-to-peer sont liées à la limitation de la bande passante).
Enfin pour répondre à la question de ton journal, nombre de logiciels peer-to-peer regorgent de fonctionnalités à implémenter. Par exemple Freenet (écrit en Java) www.freenetproject.org qui semble à peu près convenir à toutes tes exigences.
[^] # Re: Au contraire
Posté par khivapia . En réponse au journal MALWARE LINUX. Évalué à 3.
[^] # Re: Extensions Firefox et Chromium/Chrome et vie privée
Posté par khivapia . En réponse au journal Chrome disponible sous linux. Évalué à 5.
Je nuancerais toutefois la phrase du pdg de Google : il n'a pas dit
Seuls les criminels se soucient de protéger leur données personnelles.
Mais plutôt "Si vous avez fait quelque chose et que vous voulez que personne ne le sache, peut être devriez vous commencer par ne pas le faire", ce qui peut s'interpréter (légèrement) différemment. Rappelons qu'il s'agit du même patron de la même boîte qui avait déréférencé CNet suite à un article de ses journalistes montrant tout ce qu'on pouvait retrouver sur lui en utilisant le même moteur...
Et méditons ces deux phrases :
If privacy is outlawed, only outlaws will have privacy. (Phil Zimmermann, créateur de PGP) (qu'on peut traduire par "Si la vie privée devient hors la loi, seuls les hors-la-loi auront une vie privée")
et plus prosaïquement,
"Attention à cette tendance de croire que ce que l'on souhaite cacher est forcément suspect. Si on accroche des rideaux aux fenêtres de son salon, ce n'est pas pour assassiner sa femme en toute impunité. " (Maître Eolas en chat sur le site du Nouvel Observateur)
[^] # Re: j'espère...
Posté par khivapia . En réponse au journal Conditions de ventes et autres débilités. Évalué à 3.
faire du 130 en colonne par 3 (ie sans que personne ne respecte les distances de sécurité parce que dès qu'un trou se fait quelqu'un s'y met, tel l'électron dans le transistor) c'est clairement que tout le monde roule trop vite (pourtant c'est autorisé). Faire du 180 la nuit par beau temps sur une autoroute où il n'y a personne est interdit et pourtant beaucoup moins dangereux. Enfin le détecteur automatique de feux rouges brûlés ne constatera pas le camion qui arrive à toute blende derrière et qui oblige à le brûler (cas vécu à l'auto-école !)...
De même, pourquoi limiter à 30 les abords des écoles le dimanche et en plein mois d'août ?!?
On voit déjà des limitations variables selon la période (par exemple la route Hyères Toulon en arrivant sur Toulon, limitation à 70 en dehors des périodes de pointe, à 50 sinon), ce qui est à généraliser.
Enfin une petite statistique :
http://villemin.gerard.free.fr/CultureG/Accident.htm rechercher le mot Allemagne. Les allemands roulent plus vite qu'en France (limitation à 100 au lieu de 90, autoroutes illimitées en grande partie à 120 sinon, limitation à 60 en ville, pas d'indication de limitation de vitesse en sortie d'autoroute là où parfois en France les bretelles sont limitées à 30) Pourtant, le nombre de morts sur la route chez eux est deux fois moins important qu'en France, cherchez l'erreur... Ou sur Wikipedia http://fr.wikipedia.org/wiki/Pr%C3%A9vention_et_s%C3%A9curit(...) pour des statistiques plus récentes, qui montrent qu'il y a sensiblement autant de morts en Allemagne qu'en France, pour une population 25 à 30% supérieure...
[^] # Re: Conséquences en crypto ?
Posté par khivapia . En réponse à la dépêche Intel présente un prototype de processeur x86 octatétracontacœur. Évalué à 9.
Il est relativement facile de dimensionner les algorithmes face à des attaques par force brute : par exemple dans le cas des algorithmes symétriques, augmenter la taille de la clef d'un bit nécessite de doubler la puissance de calcul pour la trouver. Quand on sait que la puissance de calcul pour un même prix double tous les 18 mois environ, qu'un PC actuel quadricœur tourne à 4*2GHz = 2^35 opérations par seconde (en majorant un chiffrement par un cycle ce qui est un ordre de grandeur cohérent même face à certaines implémentations spécialisées type bitslice & co), soit "35 bits".
Une puce telle que celle qui est présentée ici ne permet de réaliser finalement que 48/4 = 12 fois plus de calcul par seconde, soit moins de "39 bits". On ne gagne en fait pas un facteur si grand que ça : remplacer tous les processeurs quadri-cœurs par des processeurs 48 cœurs revient à diminuer la sécurité des clefs actuelles de 4 bits, ce qui est peu finalement (les recommandations minimales sont à 128 bits actuellement, et les plus gros calculs réalisés par le monde académique font au maximum 2^60 opérations). Sans compter que ces processeurs sont loin d'être sortis, il y a des chances que leur sortie soit prévisible par la loi de Moore...
Le gros intérêt d'augmenter la puissance de calcul est plutôt pour les attaques dictionnaires de mot de passe : par rapport à une clef cryptographique dimensionnée pour tenir longtemps, un mot de passe est généralement choisi pour être le plus simple possible modulo les exigences de ce casse-pieds d'administrateur... qui ne peut pas non plus imposer à chacun de retenir des mots de passe aléatoires...
[^] # Re: Intel Marketing
Posté par khivapia . En réponse à la dépêche Intel présente un prototype de processeur x86 octatétracontacœur. Évalué à 10.
Eh bien lis les et tu verras que à 700MHz, la puce Tile64 ne consomme que 22 W tous cœurs actifs, et que chaque cœur peut plonger dans un mode endormi.
[^] # Re: Bravo et bon courage!
Posté par khivapia . En réponse au journal Je fais un tabac. Évalué à 4.
Et sois gentil avec ta femme également ;)
[^] # Re: linux wireless
Posté par khivapia . En réponse au message problème carte broadcom : unsupported phy. Évalué à 2.
Un simple aptitude install linux-image-2.6.32-rc8-amd64 te donnera le noyau le plus récent qui soit, si tu as activé les dépôts unstable évidemment.
[^] # Re: linux wireless
Posté par khivapia . En réponse au message problème carte broadcom : unsupported phy. Évalué à 4.
Attention, risque de freeze (mais le pilote marche un peu. J'ai réussi à scanner les réseaux sans fil avec ce pilote avant que la machine se mette à tourner dans le vide)
# linux wireless
Posté par khivapia . En réponse au message problème carte broadcom : unsupported phy. Évalué à 4.
http://linuxwireless.org/en/users/Drivers/b43
J'ai le même problème avec le chipset 4312 (4315 en vrai), mais j'arrive à le faire fonctionner avec ndiswrapper en suivant un des nombreux tutos sur le web, et il paraît qu'il devrait marcher avec le noyau 2.6.32. Debian compte fournir un noyau 2.6.32 dans la prochaine stable, donc il y a des chances qu'il arrive dans unstable assez vite (il devrait sortir sous peu)
[^] # Re: Et tes homonymes
Posté par khivapia . En réponse au journal Fuyez pauvres fous !!!. Évalué à 3.
Il s'agit des enquêtes d'habilitations, menées dans le cadre prévu par la loi. Elles concernent également toute personne qui est amenée à travailler sur des données sensibles pour l'état (par exemple des fournisseurs de l'état), et plus généralement un nombre incroyable de métiers sont soumis à enquête (par exemple tous les métiers de la sécurité physique, avec port d'arme, ou bien le travail sur un aéroport, etc.)
[^] # Re: Et tes homonymes
Posté par khivapia . En réponse au journal Fuyez pauvres fous !!!. Évalué à 2.
En revanche, les banques préfèrent largement les cigales que les fourmis, c'est-à-dire que quelqu'un qui prend beaucoup de prêts et dépense son argent à tout va sera moins âpre au gain et un pigeon client plus intéressant.
[^] # Re: faux débat
Posté par khivapia . En réponse au journal Le réchauffement climatique est une vaste blague. Un complot.... Évalué à 10.
Alors sans préciser ce qu'on appelle les régions les plus développées (quel est le critère ?), cette phrase veut juste dire que les 18,3% les plus développés de la population mondiale représentent très exactement 18,3% de la population, c'est-à-dire que ça apporte une quantité d'information nulle. On pourrait dire aussi que les régions les plus développées représentent 99% de la population, ce sera toujours aussi vrai tant que je me cantonne à un "plus développées" aussi fumeux (ben oui, les 99% les plus développés sont toujours plus développés que les 1% restant...)
Faudrait aller voir le rapport de l'ONU (ça apparaît d'ailleurs pas clairement dedans mais j'ai pas le temps de creuser) pour voir ce que la notion recouvre, mais un manque de précision pareil sur wikipedia est navrant.
[^] # Re: Faire son RMS
Posté par khivapia . En réponse au journal Linux en légère croissance sur les mobiles, et controverse sur le Nuage.. Évalué à 6.
Techniquement ça ne se justifie pas, maintenant commercialement ils ne pouvaient tout de même pas espérer que les vendeurs de téléphones mobiles (aka les fournisseurs de téléphonie mobile et de tous les services qui vont avec) allaient tirer une balle dans le pied de l'apport que représente pour eux des téléphones verrouillés (donc sur lesquels il reste difficile de bidouiller), comme par exemple la difficulté d'ajouter des sonneries sans les payer cher, le blocage de la redirection de la connexion à internet (vous vous rappelez de l'iphone dernière version, qui permet ça, joie, pour 30€ par mois supplémentaires (gasp)), la mise en avant de tous les services inutiles et payants, ainsi que l'inévitable page de pub à l'allumage (qui n'a pas son logo Orange/SFR/Bouygues/Itineris/... (TGM)) ? Sans oublier la possibilité de développer un "Market" qui ne sera pas pollué par les inévitables applications gratuites qu'une plate-forme ouverte permettrait de télécharger et d'installer librement, dans le cas de google il faut déjà les porter...
Une question simple : est-ce que le téléphone me laisse l'accès à un compte root sans hacking (profiter d'une faille dans un logiciel, type dépassement de tampon, qui sera comblée un jour) ?
Techniquement sinon, je ne comprends pas non plus les innombrables restrictions sur l'ersatz de connexion, dite 'connexion à internet' qui est actuellement délivrée par les opérateurs 3G. Et je ne parle même pas des facturations...
(tiens tant qu'on est dans les bizarreries, il y a en Allemagne des forfaits qui ne comprennent pas l'envoi de sms, et où en envoyer sms coûte 19ct. Le truc marrant, c'est que quand on passe une frontière avec, la réglementation européenne sur les coûts des sms transfrontaliers les bride à 13ct maximum... je la refais, envoyer un sms de l'étranger avec un téléphone national coûte 35% moins cher que de l'envoyer du national au national.)
[^] # Re: Etre en colère contre les bonnes personnes
Posté par khivapia . En réponse au journal On connait un des brevets microsoftiens que linux viole. Évalué à 3.
[^] # Re: Interrogations...
Posté par khivapia . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 3.
D'un autre côté une fois qu'on a un interpréteur correct, c'est qu'on a réussi à appréhender la sémantique justement... Et de là à en écrire un compilateur (au moins vers une machine virtuelle), la marche est moins haute.
D'ailleurs comme tu le dis il existe des compilateurs pour langages de script vers du byte code (une référence se trouve ici, pour python 2.5.2 http://www.python.org/doc/2.5.2/lib/bytecodes.html ). Les opérations d'icelui sont naturelles pour un langage de bas niveau, et ne sont pas "beaucoup" plus haut niveau que de l'assembleur pur. Mis à part un linker il ne manque pas grand-chose au niveau analyse sémantique pour compiler finalement complètement le langage vers du code machine.
# Interrogations...
Posté par khivapia . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 8.
La gestion de la mémoire doit être automatique (garbage collector)
http://fr.wikipedia.org/wiki/Programmation_syst%C3%A8me
S'il faut un langage compilé pour obtenir de meilleures performances, pourquoi en faire un langage à gestion automatique de mémoire ? plutôt que d'utiliser de simples aides à la gestion comme les pointeurs intelligents, qui n'impactent pas les performances mais gardent la souplesse et la puissance d'une gestion manuelle ?
Linus Torvalds disait qu'il ne voulait pas de C++ dans le noyau Linux car il a tendance à cacher la gestion de la mémoire, qui est un élément trop important pour être laissé à de simples algorithmes. En programmation système c'est la même chose en général (gestion fine des ressources, la mémoire en particulier en fait partie).
En plus avec un garbage collector, le côté "temps réel" est beaucoup plus délicat à assurer (typiquement on a beaucoup de mal à régler le moment où il doit se déclencher et les mauvais cas sont fréquents).
Ça me paraît donc un peu aninomique, surtout qu'en compilant vite (ce qui est un objectif prioritaire du langage) on ne pourra pas profiter de beaucoup d'optimisations de la part du compilateur.
Ça s'apparente donc plutôt une sorte de langage de script compilé, avec une syntaxe proche du C. Mais alors les langages de scripts les plus utilisés sont vraiment si lents que ça par rapport à du code compilé en natif mais avec peu d'optimisation ? (la Faq sur le langage parle de python en disant que ce n'est pas efficace, les développeurs Python devraient apprécier ; il devrait être possible de développer un compilateur python rapide non ? ) http://golang.org/doc/go_lang_faq.html
Bref je ne comprends pas trop la position du langage par rapport à ses concurrents, au niveau des performances voulues/atteintes. En revanche les idées derrière l'implémentation de la concurrence sont intéressantes.
[^] # Re: Quel autre aternative ?
Posté par khivapia . En réponse au journal Bruxelles pourrait bloquer la fusion Oracle-Sun. Évalué à 5.
On me souffle dans l'oreillette qu'Oracle est leader sur les solutions de bases de données en Europe également, marché sur lequel la Commission Européenne veille à garder une concurrence saine.
La Commission peut tout simplement interdire à une société d'agir sur le marché européen, laissant toute la place à une nouvelle concurrence, ou bien infliger des amendes dissuasives.
[^] # Re: dbench
Posté par khivapia . En réponse au journal Linux, Gentoo, et gcc dans un bateau.... Évalué à 7.
Pour illustrer ça, voici deux codes qui calculent exactement la même chose (un crible d'Eratosthene, un des plus anciens algorithmes s'il en est :-) D'un point de vue algorithmique tout se passe de la même façon, d'un point de vue calculs ils sont très différents.
crible basique :
http://www.joux.biz/algcrypt/PROGRAMS/Sieve_4-1.html
crible par petits morceaux de 16ko tenant largement dans le cache L1
http://www.joux.biz/algcrypt/PROGRAMS/Sieve_4-2.html
Sur un intel atom N270 (1.6GHz), la différence est flagrante pour les tailles les plus grosses : (tous deux sont compilés avec gcc 4.3.4 -O3 ; avec gcc-4.4.2 on gagne à peu près 5 à 8 % dans les deux cas)
time ./cache_sieve > result
1234567890
real 0m53.146s
user 0m48.663s
sys 0m0.164
time ././basic_sieve > result
1234567890
real 2m43.930s
user 2m29.473s
sys 0m3.760s
(je vous recommande de rediriger la sortie vers un fichier pour bien mesurer le temps de calcul, sinon tout sera pollué par le temps d'affichage dans la console).
Notons que les accès mémoire du crible d'Eratosthene basique sont relativement simples, et sans doutes faciles à prédire et donc à optimiser par le compilateur et les mécanismes de prefetch du processeur. Dans des applications plus complexes, le gain d'une implémentation optimisée serait certainement encore plus important.
[^] # Re: Cela confirme ce que je pense
Posté par khivapia . En réponse au journal Linux, Gentoo, et gcc dans un bateau.... Évalué à 3.
En plus ça doit être extrèmement difficile de désactiver certaines unités pendant un calcul, car les transitions entre activité et inactivité donc réduction d'énergie possible sont très très courtes ! Quand on voit qu'un CPU met selon powertop quelques centaines de µs à changer d'état, on se dit que ce n'est pas gagné : en 100 µs un CPU a calculé 100 000 instructions, ce qui est énorme.
[^] # Re: Cela confirme ce que je pense
Posté par khivapia . En réponse au journal Linux, Gentoo, et gcc dans un bateau.... Évalué à 3.
Selon le manuel de gcc lui-même (si jamais vous l'avez installé à partir des sources), ils annoncent tout de go une augmentation de la vitesse de compilation de 7% rien qu'en activant ce switch.
Par contre ça a l"inconvénient de nécessiter une passe de compilation supplémentaire dans le cas de gcc, et des tests représentatifs dans les autres cas.
Quand on développe un code on réalise toujours quelques tests pour s'assurer des gains de performance quand on optimise une partie critique, il ne doit pas falloir beaucoup de travail pour les fournir proprement et ainsi être en mesure d'optimiser à fond grâce à gcov les parties du code les plus sensibles.
[^] # Re: Cela confirme ce que je pense
Posté par khivapia . En réponse au journal Linux, Gentoo, et gcc dans un bateau.... Évalué à 4.
Pas sûr qu'elle ne l'utilisera pas sans s'en rendre compte : les logiciels de gestion de photos à la Gwenview sous Kde permettent des traitements par lot d'opérations simples (comme le redimensionement justement) avec une interface clickodrome sympa et tout. Ça n'utilise sans doutes pas graphic magic ni imagemagik, mais des programmes similaires. On peut donc s'attendre à ce qu'elle bénéficie du même genre d'amélioration des performances.