Désolé si j'ai été un peu agressif, mais dans ce cas je comprends pas ton premier commentaire.
Oui on peut mettre a jour le microcode d'un amd, mais on en revient a la problématique que je citais :
Certanis bugs peuvent être "contournés" via l'OS, mais il en reste d'autres qui ne peuvent être contournés qu'à partir du bios et que l'utilisateur reste très désarmé si les fabricants ne fournissent pas de fixs pour leurs bios.
Dans le cas d'intel, pourvu qu'intel fournisse une mise a jour, tout le monde en profitera, dans le cas d'autres cpu une mise a jour du bios (qui fera des mises a jour microcode a chaque demarage) est nécessaire.
Voila je voulais simplement dire que dans le cas des core2duo, la mise a jour pour corriger les bugs étaient relativement aisé sous Linux et on ne dépendait pas du bios( comme pour d'autres cpu tel que AMD).
Il n'affirme pas que les failles du CPU sont négligeables ou dérisoires...ce qui est compréhensible quand on regarde la liste !
Mais si on regarde les autres messages, on peut lire de la part de Andi Kleen (responsable linux x86_64) [1] : Overall I don't have the impression that Core2 is buggier
than earlier CPUs.
alors que c'est truffé de bugs
A tu des elements de comparaisons pour dire qu'il y a plus de bugs que dans les versions precedentes/chez les concurents ?
Tout les cores aussi complexe que les x86 ont forcement des bugs (a moins de valider le truc pendant des années et le sortir alors qu'il est deja obsolète).
Certains fournisseurs ne publient pas les bugs (regarde de quand date le dernier errata de AMD) ou encore pire dans l'embarqué ou il faut parfois se battre pour que le fondeur reconnaisse le bug.
Certains articles font état de microcode pour amd (le K8 par exemple):
oui IIRC, des personnes c'étaient amusé a analysé un bios pour essayer de faire une mise a jour depuis Linux, mais je crois que ca ete vite abandonné au vu des risque de tout casser (y a toujours pas de driver offciel dans les OS et ton truc date de 2004).
De plus c'est que pour les K8, le driver intel les supporte tous depuis les pentium pro.
Enfin intel fait des releases de microcode pour microcode.ctl (les derniere date de 04/2007), alors que pour le truc que tu cite il faut l'extraire des bios.
Certanis bugs peuvent être "contournés" via l'OS, mais il en reste d'autres qui ne peuvent être contournés qu'à partir du bios et que l'utilisateur reste très désarmé si les fabricants ne fournissent pas de fixs pour leurs bios.
Hum, contrairement au AMD, sous intel ont peut pacher le microcode au démarage avec des truc comme microcode.ctl (meme si on a pas de patch du bios).
apt-cache show microcode.ctl
[...]
The microcode update is volatile and needs to be uploaded on each
system boot i.e. it doesn't re-flash your CPU permanently, reboot and
it reverts back to the old microcode. The ideal place to load
microcode is in BIOS, but most vendors never update it!
Et puis il faut souligner que intel fait l'effort de publier pas mal d'errata.
Une petite question, au lieu de recoder un serveur, n'aurait il pas été possible d'utiliser un serveur jabber (avec l'extension salon de discution) + punjab [1] ?
Oui OK, ils sont allé un peu vite.
S'il y avait que la.
Quand je suis arrivé, ils parlaient de la récupération de donné sur disque dur.
- Alors qd on efface un fichier, on efface la première lettre du fichier (tout le monde n'utilise pas FAT).
- On accède au disque dur par des indexes (mouai, c'est plutôt les systèmes de fichiers).
- Ils ont donné l'impression que les donné ne pouvait pas être effacé (qui de shred, du cryptage des disques, ...)
Et tout ca de la bouche d'expert, a ce moment j'ai failli éteindre la tv.
Bref je veux bien qu'ils vulgarisent, mais j'ai parfois eu l'impression d'être pris pour un neuneu auquel on voulait faire gober n'importe quoi.
PS : les caméra à londres qui sont en wifi, a votre avis elles sont sécure ;)
Tiens c'est marrant tu ne commentes pas le cas des webappli (CMS/forum/...) modifié et pour lequels les utilisateurs n'ont pas le droit au modifs.
FAUX, avec des licences libres comme le GPL2 et le GPL3, je peux faire ce que je veux avec le code tant que je ne commence pas à distribuer l'application.
Et ben la tu peux faire ce que tu veux tant que tu ne donnes pas un accès (réseau) à l'application.
Du coup, si je veux intégrer du code gpl2 (non upgradable GPL3), du code d'une autre licence, genre openssl, voir du totalement non-libre dans du code AGPL, je n'ai pas le droit de le faire pour mes propres besoins dès lors que mon usage tombe dans la définition mensongère de "distribution" faite par l'AGPL.
Je le trouve pas si mensongère que ça la def.
Dans les 2 cas l'utilisateur utilise une appli sous une certaine licence qui lui donne certaines liberté.
La différence c'est que dans un cas l'appli est installé sur son PC, dans l'autre c'est une appli distante dont une partie s'execute sur le serveur distant, l'autre partie en local.
On est carrément en violation de la liberté 1!!!
J'ai un scoop pour toi : les softs sous GPL ne peuvent pas etre linké à des parties proprio (sauf exception (lib du systeme, ...)).
La seule difference c'est qu'ici tu peux pas le faire non plus sur les applis distante (au lieu des applis que tu distribues pour la GPL).
J'en conclu que la GPL viole aussi a liberté 1 ?
Quand il y urgence et que l'activité de l'entreprise est menacée, il faut parfois agir vite, quitte à revenir sur ses pas après pour avoir une solution plus propre et plus durable.
Ca concerne surtout les patchs de secu, ou tu as quelques chose de plus precis en tete ?
Avec l'ALGPL on met des contraintes sur l'utilisation du logiciel, on augmente certes les règles de préservation mais on réduit les libertés.
C'est marrant quelqu'un prechant pour la BSD/domaine publique pourrait dire la meme chose pour la GPL.
tu peux avoir besoin d'interagir avec des modules sous licence incompatibles, des modules proprios.
Peut etre que certains auteurs n'ont pas envie que leur soft soit modifié pour interagir avec des parties proprios (y en a bien qui prefere le bsd au (l)gpl).
u perd ton droit à apporter une solution court terme puis une solution long terme. Tu dois directement faire du long terme quitte à menacer la stabilité de tes activités.
Ha bon, qu'est ce qui t'empêche de publier ta solution quick&dirty d'abord et puis de faire un truc plus propre ensuite ?
Je te l'accorde, le fait de publier un patch/nouvelle version peut etre un peu lourd. Bon après y a peut etre moyen d'attendre que quelqu'un te demande les sources avant de devoir les diffuser (ce qui te laisse un peu de temps).
Forcément, il n'y a que les trucs mal programmés qui ont des problèmes, un bon programmeur n'oublie jamais rien, et tout ce qu'il sort comme code est directement avec un niveau de maturité impeccable.
Tu t'egares un peu. Le problème que tu exposais plus haut était :
dangereuse car cela risque d'obliger la publication du code prématurément, avec éventuellement des bugs ou des vulnérabilités. qui peuvent se retourner contre le site web publiant son code source honnêtement.
Ca suppose que tu mets en production du code qui n'a pas été validé en interne (la ou tu ne dois pas mettre dispo les sources).
De plus si le soft est sous ALGPL, il y a des chances que ca ne soit pas toi qu'il l'ai développé (sinon pourquoi tu aurais choisi une telle licence), mais un soft que tu as telecharger sur le net (ou les sources sont deja dispo) auquel tu as pu apporté quelques modifs.
Dans ce cas, pourquoi ne pas proposer tes modifs en upstream avant la mise en production ?
Comme ca tu auras l'avis d'autres dev et d'autres personnes pourront tester ton code.
Après quand t'as un soucis avec le soft tu ne peux pas remonter de bugs au près des devs du soft car tu n'as pas une version officielle. Ben tu les rapportes aux mainteneurs de ta distro. C'est eux qui ont fait la version modifié.
Oui les patchs c'est pas idéal, mais la pluspart du temps c'est difficile de faire sans.
premiere vue seule la licences des dits codecs
Mais ca fait bien longtemps qu'ils l'ont acheter la licence pour les codecs MS (cf les annonces de l'epoque).
L'accord n'apporte rien (sauf pression de MS)...
Par contre je ne sais pas si :
- c'est pour 1 million de lecture et ecriture au total ou séparement
- c'est 1 million/block ou octet ou s'ils utilisent une technique de répartition des données pour éviter d'ecrire trop souvent au même endroit (ce qui pourrait amener à 10 000 écritures réelles par block ou octet)
En interne tu as souvent des memoires nand + un µcontrolleur :
- c'est 1 million en écriture, les lectures impactant peu
- le µcontrolleur répartie l'usure des secteurs, mais vu qu'il n'a pas la connaissance de ce que veux faire le filesystem c'est pas toujours génial (voir ca peut etre catastrophique sur certains fs).
Donc oui, il faut limiter au maximun les écritures à la fois au niveau fichier mais aussi au niveau fs (noatime, pas un fs qui a besoin de réécrire toute les métadata (FAT, ...) à chaque modif, ...).
Le top étant d'avoir un "/" en ro, un "/tmp", "/var/log", ... en RAM et une partition rw pour les données user.
Pourquoi pas mais... au nom de l'exception de copie privée on a le droit de copier ces fichiers pour des proches, donc qu'un fichier portant mon nom se retrouve sur les réseaux P2P n'implique en rien ma culpabilité.
Ben quand tu prêtes ta voiture à tes amis, s'ils font des conneries avec, c'est ta plaque d'immatriculation qui sera relevé (et donc à toi les PV, emmerde ).
Posté par M .
En réponse à la dépêche Nexuiz 2.3.
Évalué à 5.
Je faisais référence au marché actuel, regarde un peu ce que te propose ton supermarché en entrée de gamme .
Oui c'est quand même pas comme ci le jeu venais de sortir (il a deja 2 ans d'après l'article).
Surtout que lorsque l'on apprend qu'il est basé sur le moteur Quake I, et Quake I d'après wikipedia [1] tourne sur un :
90 MHz Processor
8 MB RAM
80 MB Hard disk space
2 MB Graphics card
IRIX 5.3 / Linux 1.3.88 / MS-DOS 5.0 / Solaris 2.5.1 / Windows 95
j'aurais cru que modeste voulais vraiment dire modeste...
Posté par M .
En réponse à la dépêche Nexuiz 2.3.
Évalué à 5.
Télécharger 3 fois les ressources (ce qui est l'essentiel de l'archive) et bien non merci.
Y a un truc intelligent qui consiste à faire un paquet data et des paquets pour chaque machines.
Un des avantages de libmagic, c'est la protection contre un petit malin qui t'envoie un binaire tout en indiquant que son type est anodin.
Parce que tu t'amuse à exécuter les *.jpeg ?
IIRC c'est plus les utilitaires sous une certaine platformes qui sont moisi.
Et puis tromper libmagic en présentant une fausse signature, c'est pas non plus mission impossible.
ALSA étant depuis le début uniquement sous Linux il est vain d'imaginer pouvoir le porter.
Je crois que certains (bsd) on essayé de le porter ou faire une couche d'emulation et se sont cassé les dents.
Vu que cette version d'oss supporte l'emulation alsa, c'est une bonne nouvelle pour eux.
[^] # Re: ...
Posté par M . En réponse au journal l'Intel Core 2 Duo considéré dangereux par Theo de Raadt. Évalué à 2.
Oui on peut mettre a jour le microcode d'un amd, mais on en revient a la problématique que je citais :
Certanis bugs peuvent être "contournés" via l'OS, mais il en reste d'autres qui ne peuvent être contournés qu'à partir du bios et que l'utilisateur reste très désarmé si les fabricants ne fournissent pas de fixs pour leurs bios.
Dans le cas d'intel, pourvu qu'intel fournisse une mise a jour, tout le monde en profitera, dans le cas d'autres cpu une mise a jour du bios (qui fera des mises a jour microcode a chaque demarage) est nécessaire.
Voila je voulais simplement dire que dans le cas des core2duo, la mise a jour pour corriger les bugs étaient relativement aisé sous Linux et on ne dépendait pas du bios( comme pour d'autres cpu tel que AMD).
[^] # Re: Linus a dit : « c'est totalement insignifiant »
Posté par M . En réponse au journal l'Intel Core 2 Duo considéré dangereux par Theo de Raadt. Évalué à 3.
Mais si on regarde les autres messages, on peut lire de la part de Andi Kleen (responsable linux x86_64) [1] :
Overall I don't have the impression that Core2 is buggier
than earlier CPUs.
[1] http://www.realworldtech.com/forums/index.cfm?action=detail&(...)
[^] # Re: Linus a dit : « c'est totalement insignifiant »
Posté par M . En réponse au journal l'Intel Core 2 Duo considéré dangereux par Theo de Raadt. Évalué à 1.
A tu des elements de comparaisons pour dire qu'il y a plus de bugs que dans les versions precedentes/chez les concurents ?
Tout les cores aussi complexe que les x86 ont forcement des bugs (a moins de valider le truc pendant des années et le sortir alors qu'il est deja obsolète).
Certains fournisseurs ne publient pas les bugs (regarde de quand date le dernier errata de AMD) ou encore pire dans l'embarqué ou il faut parfois se battre pour que le fondeur reconnaisse le bug.
[^] # Re: ...
Posté par M . En réponse au journal l'Intel Core 2 Duo considéré dangereux par Theo de Raadt. Évalué à 3.
oui IIRC, des personnes c'étaient amusé a analysé un bios pour essayer de faire une mise a jour depuis Linux, mais je crois que ca ete vite abandonné au vu des risque de tout casser (y a toujours pas de driver offciel dans les OS et ton truc date de 2004).
De plus c'est que pour les K8, le driver intel les supporte tous depuis les pentium pro.
Enfin intel fait des releases de microcode pour microcode.ctl (les derniere date de 04/2007), alors que pour le truc que tu cite il faut l'extraire des bios.
Bref rien de comparable.
# ...
Posté par M . En réponse au journal l'Intel Core 2 Duo considéré dangereux par Theo de Raadt. Évalué à 4.
Hum, contrairement au AMD, sous intel ont peut pacher le microcode au démarage avec des truc comme microcode.ctl (meme si on a pas de patch du bios).
apt-cache show microcode.ctl
[...]
The microcode update is volatile and needs to be uploaded on each
system boot i.e. it doesn't re-flash your CPU permanently, reboot and
it reverts back to the old microcode. The ideal place to load
microcode is in BIOS, but most vendors never update it!
Et puis il faut souligner que intel fait l'effort de publier pas mal d'errata.
[^] # Re: Debian, Thunderbird et Icedove...
Posté par M . En réponse au journal Publication de la version 0.5 de Sunbird et Lightning. Évalué à 2.
Pour la traduction, il me semble que dans les options du plugin, on peut choisir la langue.
[^] # Re: if (i = 0) // je vérifie que i est égal à 0
Posté par M . En réponse au journal à quand un code commenté ?. Évalué à 2.
Pas vraiment :
essaye un if ( (i =0) || uneautrecond() )
Aucun warning ...
# jabber ?
Posté par M . En réponse à la dépêche AJAX Chat Engine a besoin de vous. Évalué à 10.
[1] http://www.butterfat.net/wiki/Projects/PunJab
# philips
Posté par M . En réponse au journal Une radio IP Wifi. Évalué à 2.
Il me semble qu'orange propose une radio wifi en option avec leur offre livebox...
# ...
Posté par M . En réponse au journal CNIL, accès aux données personnelles. Évalué à 5.
PS : on peut le demander aussi pour l'état (fichier d'infraction, RG, ...).
[^] # Re: Richard Stallman
Posté par M . En réponse au journal Soirée Big Brother sur Arte. Évalué à 2.
S'il y avait que la.
Quand je suis arrivé, ils parlaient de la récupération de donné sur disque dur.
- Alors qd on efface un fichier, on efface la première lettre du fichier (tout le monde n'utilise pas FAT).
- On accède au disque dur par des indexes (mouai, c'est plutôt les systèmes de fichiers).
- Ils ont donné l'impression que les donné ne pouvait pas être effacé (qui de shred, du cryptage des disques, ...)
Et tout ca de la bouche d'expert, a ce moment j'ai failli éteindre la tv.
Bref je veux bien qu'ils vulgarisent, mais j'ai parfois eu l'impression d'être pris pour un neuneu auquel on voulait faire gober n'importe quoi.
PS : les caméra à londres qui sont en wifi, a votre avis elles sont sécure ;)
# raw
Posté par M . En réponse au journal HDR Facile. Évalué à 7.
A propos y a http://lwn.net/Articles/225652/ et http://lwn.net/Articles/227852/ qui était pas mal sur le sujet.
[^] # Re: Mwais...
Posté par M . En réponse à la dépêche GNU Affero General Public License : la GPL des applications web. Évalué à 4.
FAUX, avec des licences libres comme le GPL2 et le GPL3, je peux faire ce que je veux avec le code tant que je ne commence pas à distribuer l'application.
Et ben la tu peux faire ce que tu veux tant que tu ne donnes pas un accès (réseau) à l'application.
Du coup, si je veux intégrer du code gpl2 (non upgradable GPL3), du code d'une autre licence, genre openssl, voir du totalement non-libre dans du code AGPL, je n'ai pas le droit de le faire pour mes propres besoins dès lors que mon usage tombe dans la définition mensongère de "distribution" faite par l'AGPL.
Je le trouve pas si mensongère que ça la def.
Dans les 2 cas l'utilisateur utilise une appli sous une certaine licence qui lui donne certaines liberté.
La différence c'est que dans un cas l'appli est installé sur son PC, dans l'autre c'est une appli distante dont une partie s'execute sur le serveur distant, l'autre partie en local.
[^] # Re: Mwais...
Posté par M . En réponse à la dépêche GNU Affero General Public License : la GPL des applications web. Évalué à 2.
J'ai un scoop pour toi : les softs sous GPL ne peuvent pas etre linké à des parties proprio (sauf exception (lib du systeme, ...)).
La seule difference c'est qu'ici tu peux pas le faire non plus sur les applis distante (au lieu des applis que tu distribues pour la GPL).
J'en conclu que la GPL viole aussi a liberté 1 ?
Quand il y urgence et que l'activité de l'entreprise est menacée, il faut parfois agir vite, quitte à revenir sur ses pas après pour avoir une solution plus propre et plus durable.
Ca concerne surtout les patchs de secu, ou tu as quelques chose de plus precis en tete ?
Avec l'ALGPL on met des contraintes sur l'utilisation du logiciel, on augmente certes les règles de préservation mais on réduit les libertés.
C'est marrant quelqu'un prechant pour la BSD/domaine publique pourrait dire la meme chose pour la GPL.
[^] # Re: Mwais...
Posté par M . En réponse à la dépêche GNU Affero General Public License : la GPL des applications web. Évalué à 4.
Peut etre que certains auteurs n'ont pas envie que leur soft soit modifié pour interagir avec des parties proprios (y en a bien qui prefere le bsd au (l)gpl).
u perd ton droit à apporter une solution court terme puis une solution long terme. Tu dois directement faire du long terme quitte à menacer la stabilité de tes activités.
Ha bon, qu'est ce qui t'empêche de publier ta solution quick&dirty d'abord et puis de faire un truc plus propre ensuite ?
Je te l'accorde, le fait de publier un patch/nouvelle version peut etre un peu lourd. Bon après y a peut etre moyen d'attendre que quelqu'un te demande les sources avant de devoir les diffuser (ce qui te laisse un peu de temps).
Forcément, il n'y a que les trucs mal programmés qui ont des problèmes, un bon programmeur n'oublie jamais rien, et tout ce qu'il sort comme code est directement avec un niveau de maturité impeccable.
Tu t'egares un peu. Le problème que tu exposais plus haut était :
dangereuse car cela risque d'obliger la publication du code prématurément, avec éventuellement des bugs ou des vulnérabilités. qui peuvent se retourner contre le site web publiant son code source honnêtement.
Ca suppose que tu mets en production du code qui n'a pas été validé en interne (la ou tu ne dois pas mettre dispo les sources).
De plus si le soft est sous ALGPL, il y a des chances que ca ne soit pas toi qu'il l'ai développé (sinon pourquoi tu aurais choisi une telle licence), mais un soft que tu as telecharger sur le net (ou les sources sont deja dispo) auquel tu as pu apporté quelques modifs.
Dans ce cas, pourquoi ne pas proposer tes modifs en upstream avant la mise en production ?
Comme ca tu auras l'avis d'autres dev et d'autres personnes pourront tester ton code.
[^] # Re: on y est déja sorti en fait...
Posté par M . En réponse au journal Le retour de RPM - Divergences sur la convergence. Évalué à 3.
Oui les patchs c'est pas idéal, mais la pluspart du temps c'est difficile de faire sans.
[^] # Re: Non
Posté par M . En réponse au journal Faut il que je retourne sous IE ?. Évalué à 5.
Le projet est arrété : les devs attendent un financement.
Domange un navigateur peu gourmand etait parfois intéressant.
[^] # Re: D'un point de vue commercial la decision de Linspire est logique!
Posté par M . En réponse au journal All your Linuxes are belong to Microsoft!. Évalué à 5.
Mais ca fait bien longtemps qu'ils l'ont acheter la licence pour les codecs MS (cf les annonces de l'epoque).
L'accord n'apporte rien (sauf pression de MS)...
[^] # Re: durée de vie
Posté par M . En réponse au journal Remplacer un disque dur par une compact flash, autre expérience. Évalué à 4.
- c'est pour 1 million de lecture et ecriture au total ou séparement
- c'est 1 million/block ou octet ou s'ils utilisent une technique de répartition des données pour éviter d'ecrire trop souvent au même endroit (ce qui pourrait amener à 10 000 écritures réelles par block ou octet)
En interne tu as souvent des memoires nand + un µcontrolleur :
- c'est 1 million en écriture, les lectures impactant peu
- le µcontrolleur répartie l'usure des secteurs, mais vu qu'il n'a pas la connaissance de ce que veux faire le filesystem c'est pas toujours génial (voir ca peut etre catastrophique sur certains fs).
Donc oui, il faut limiter au maximun les écritures à la fois au niveau fichier mais aussi au niveau fs (noatime, pas un fs qui a besoin de réécrire toute les métadata (FAT, ...) à chaque modif, ...).
Le top étant d'avoir un "/" en ro, un "/tmp", "/var/log", ... en RAM et une partition rw pour les données user.
[^] # Re: fair use / copie privée
Posté par M . En réponse à la dépêche Apple Plus : sans DRM, mais.... Évalué à -1.
Pourquoi pas mais... au nom de l'exception de copie privée on a le droit de copier ces fichiers pour des proches, donc qu'un fichier portant mon nom se retrouve sur les réseaux P2P n'implique en rien ma culpabilité.
Ben quand tu prêtes ta voiture à tes amis, s'ils font des conneries avec, c'est ta plaque d'immatriculation qui sera relevé (et donc à toi les PV, emmerde ).
[^] # Re: "Très modeste"
Posté par M . En réponse à la dépêche Nexuiz 2.3. Évalué à 5.
Oui c'est quand même pas comme ci le jeu venais de sortir (il a deja 2 ans d'après l'article).
Surtout que lorsque l'on apprend qu'il est basé sur le moteur Quake I, et Quake I d'après wikipedia [1] tourne sur un :
90 MHz Processor
8 MB RAM
80 MB Hard disk space
2 MB Graphics card
IRIX 5.3 / Linux 1.3.88 / MS-DOS 5.0 / Solaris 2.5.1 / Windows 95
j'aurais cru que modeste voulais vraiment dire modeste...
[1] http://en.wikipedia.org/wiki/Quake
[^] # Re: Tous dans le même sac ?
Posté par M . En réponse à la dépêche Nexuiz 2.3. Évalué à 5.
Y a un truc intelligent qui consiste à faire un paquet data et des paquets pour chaque machines.
Mais bon après tout c'est qu'un détail.
[^] # Re: Sécurité
Posté par M . En réponse au journal En finir avec libmagic. Évalué à 3.
Parce que tu t'amuse à exécuter les *.jpeg ?
IIRC c'est plus les utilitaires sous une certaine platformes qui sont moisi.
Et puis tromper libmagic en présentant une fausse signature, c'est pas non plus mission impossible.
[^] # Re: Rien à voir: MMX/SSE
Posté par M . En réponse à la dépêche Open Sound System de retour vers le libre. Évalué à 2.
[^] # Re: ALSA...
Posté par M . En réponse à la dépêche Open Sound System de retour vers le libre. Évalué à 4.
Je crois que certains (bsd) on essayé de le porter ou faire une couche d'emulation et se sont cassé les dents.
Vu que cette version d'oss supporte l'emulation alsa, c'est une bonne nouvelle pour eux.