Matthieu Moy a écrit 3255 commentaires

> commander une petite série de 10000 unitées ?
> Ca ferait quel prix par procs ?

Si tu veux un circuit du même niveau que ce qui se fait actuellement, tu comptes 1 million d'euro rien que pour le masque, et tu divise par le nombre de puces.

Le problème du hard aujourd'hui, c'est que les frais fixes sont *énormes*, et il faut produire des millions de puces de chaque modèle pour être rentable.

> Avec les capacités grandissantes des FPGA,

Ben oui, c'est facile : Les FPGA suivent la loi de moore aussi ... Mais avec un peu de retard, et ce retard est constant jusqu'ici. Donc, oui, on peut faire des choses avec un FPGA, mais toujours moins qu'avec un circuit dédié.

> J'ai vu à une expo un processeur ARM émulé dans _un_ FPGA

OK, mais justement, les processeurs ARM, ce sont en général des petits processeurs destinés à être intégrés dans des circuits bien plus gros.


Une usine de microelectronique, de nos jours, ça coute plusieurs milliards d'euros, et on en construit encore. Si c'était rendu obsolète par les FPGA, je crois que ça se saurait.

> Les besoins sont pourtant réels :

> 1) Il est possible que dans quelques années la gestion des droits (DRM)
> ou l'informatique de confiance (Trusted Computing) soit gérées
> directement "dans le silicium" sans permettre la liberté de l'utilisateur.

Ca ne changera pas grand chose avec du Hardware libre. D'ailleurs, les systèmes auxquels tu fais allusion (TCPA/NGSCB) auront vraissemblablement des spécifications publiques.

Le design de la puce peut être public, ce qui importe, c'est la clé privée qui est stoquée dedans ...

> 2) La sécurité dont se targue avec raison le monde du logiciel libre
> (code source auditable par tous) peut être compromise par une
> "backdoor" hardware directement implémenté dans le CPU....

Ca ne changera strictement rien non plus avec du Hardware libre.

L'intérêt avec un logiciel libre, c'est que tu as les sources, tu peux les recompiler, et vérifier que le binaire distribué à tout le monde est bien celui qu'il dit être. (aux backdoors dans le compilo près ...)

Avec du hardware, tu n'as *aucun* moyen de vérifier que la puce physique correspond bien à son code source.

> 3) Il serait sans doute sain de répartir sur de nouvelles bases et de
> suivre la démarche originelle du logiciel libre : Faire ses choix
> techniques et fonction uniquement de leur pertinence et non de leur
> adéquation commerciale avec les objectifs d'une entreprise
> particulière, favoriser les standards ouverts et interopérables.

Là, c'est clair, et les entreprises qui font du hard le disent bien. Aujourd'hui, le gros du boulot pour faire une nouvelle puce, c'est de récupérer un maximum de blocs (IP) existants, et de les assembler.

Ensuite, on envoie ça a la fab, et il y a des frais fixes *énorme*. Rien que le masque, c'est à dire ce qui doit être fait avant le premier exemplaire de la puce, coute un million de dollar, (et ça double environ tous les 18 mois, comme la loi de moore). Une usine de microelectronique coute également de plus en plus cher. On sait pertinemment qu'il n'y aura pas de la place pour tout le monde sur ce segment. Donc les industriels s'allient (cf. L'alliance Crolles2 ST + Philips + Motorolla en construction - plus gros investissement industriel français depuis 10 ans !) ou crèvent.

Bref, à part peut être Intel qui est loin devant, les géants du semiconducteurs savent qu'ils ne pourront pas réussir en jouant cavalier seul, et ils ont besoin de standardisation.

De là à dire qu'ils ont besoin de libre, je ne sais pas.




Reste un autre problème : Les outils logiciels libres pour faire du hardware. Et là, c'est quasiement le néant. Les gars de F-Cpu reconnaissent bosser majoritairement avec des logiciels propriétaires ne trouvant pas d'alternatives valables en libre.

> De plus pour loger un cpu entier, bonjour la taille du FPGA

Ben oui, la taille et le prix ... Pour mapper un circuit complet sur des trucs à base de FPGA, qui émule en temps réel, ben ça s'appelle un émulateur hardware, et ça coute plusieurs millions de dollars ...

Par contre, avoir des bouts de FPGA dans des circuits pour réaliser une fonction dédiée, de plus en plus de gens en parlent et c'est sans doute l'avenir. Niveau performance, il vaut souvent mieux un FPGA bien optimisé qu'un petit processeur qui execute du logiciel embarqué.

Pas mal, mais peut mieux faire !

> Mais en disposer aussi en mode console est un enorme plus.

Un plus par rapport à quoi ? urpmi tourne aussi en console.

> Ou sont les distibs anciennes encore supportées

Et la distrib Debian la plus ancienne encore supportée ? Bah, c'est la distribution stable. (Et pour cause : Ils ont fait un sondage pour savoir qui utilisait encore la potato, et la conclusion était que quasiment tout le monde avait déjà migré ...)

Menu -> Outils -> Numérotation des chapitres.

Mmmm ...

En principe, "echo >" et "echo >>" doivent suffire pour tout ça.

Et c'est quoi le rapport avec la chouroute ?

La pile tcp/ip de windows pompée sur BSD, c'est en train de devenir pire que Vi/Emacs comme troll !!! :-(

http://www.google.fr/search?hl=fr&ie=UTF-8&oe=UTF-8&q=i(...)

Quand bien même ça serait vrai, c'est quoi le problème ? C'est du BSD, donc ça serait légal.

Tu sais, y'en a qu'on peur de rien niveau copyright :

$ uname -a
SunOS drus 5.8 Generic_108528-23 sun4u sparc SUNW,Sun-Blade-100
$ cat `which true`
#!/usr/bin/sh
# Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T
# All Rights Reserved

# THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T
# The copyright notice above does not evidence any
# actual or intended publication of such source code.

#ident "@(#)true.sh 1.6 93/01/11 SMI" /* SVr4.0 1.4 */
$



Tu vois quelque chose, à part un copyright, dans ce fichier ? C'est peut être le code contenu dans ce fichier qui a été copié, qui sait !!

Sans doute : Ils pourront supprimer la possibilité de lire des vidéos protégées.

Tout comme il est possible de supprimer les parties non libres d'un logiciel. Tu perds les fonctionalités.

Ca ne résoudra surement pas les problèmes du DRM par contre.

Euuh, ça serait bien de rajouter, genre dans le corps de la news, que c'est un fake ... Sinon, y'a des gens qui vont y croire et l'utiliser pour alimenter leurs théories X-files & cie.

> l'algo pour valider un packet a envoyer est aussi dans le client.

Ben l'algo pour envoyer un packet valide dans le client, c'est le calcul proprement dit ...

Dans le cas idéal, il y a une vérification de façon sure du résultat qui est moins chère que le calcul lui-même (Genre, le client doit calculer une décomposition en facteurs premiers d'un grand nombre, le serveur vérifie que le produit est le bon)

Sinon, il doit bien y avoir un algo qui vérifie avec une bonne probabilité que le résultat n'est pas faussé. (Genre, le client doit calculer (x + y)*2, le serveur vérifie que le résultat est pair).

> À ma connaissance, un admin ne peut pas t'empêcher d'installer un logiciel sur ton compte.

Sous WinXP, si :-(

(Je sais pas exactement comment ça marche, mais le .exe a beau être là, tu n'as pas la possiblité de l'executer, et seul l'admin peut le faire.)

Ben dans la plupart des dictionaires, ce sont des synonymes.

Mais dans la tête de certains linuxfr-iens, c'est "standard = standard de fait".

Oui, enfin, je ne connais pas d'exemple ou IBM a utilisé les brevets pour limiter l'interopérabilité de ses systèmes (Il y en a peut être).

Ce qui est clair, c'est que cette histoire démontre une fois de plus que les brevets généralisés sur les logiciels sont une abhération. Un brevet qui nuit à l'intéropérabilité, ça devrait être interdit, point.

> tu sais qu'en HTML, il y a aussi une balise ,

tu sais qu'en HTML, il y a aussi une balise , < meta name="author" ... >

Pardon.

Pour info, il y a aussi un "flat XML" sous OOo.

L'intérêt est de pouvoir utiliser directement le fichier avec des outils de manipulation du XML. Mais c'est très con de ne proposer que l'un. Ca laisse entre autres penser que ce XML ne servira que de format d'échange et ne sera jamais le format par défaut (donc que les neuneus continueront d'envoyer du .doc)

En gros, ce format XML serait le remplacant du RTF (également documenté), en mieux, mais on n'est pas encore débarrassés du .doc !

> Cette fonction, contrairement à ce qui était prévu dans les bétas publiées, est
> réservée à l'édition professionnelle d'office,

Euh, c'est un peu le contraire, non ... Il avait en effet été question que les versions non-pro de Office n'autorisent pas l'import/export XML, mais dans la version finale, c'est dispo partout :

http://www.microsoft.com/france/office/editions/prodinfo/topten.asp(...)

Ce qui n'est pas possible dans les versions non-pro, c'est l'utilisation de schemas défini par l'utilisateur, mais le non-pro, justement, il s'en fout !

> MS stocke aussi des infos comme le nom de la personne, et Dieu sait quoi...

Incroyable !!!

tu sais qu'en HTML, il y a aussi une balise , qu'OpenOffice.org et toute suite bureautique, libre ou non, qui se respecte, fait de même ! Allez, sous OOo : Fichier -> Propriétés et voila les informations en question. Tu peux les consulter et les modifier à souhait.

(Le problème est dans le "dieu sait quoi". En effet, dans Office 97, il y avait un identificateur unique qui était inclu dans tous les documents contre le gré de l'utilisateur.MS avait du sortir un patch et un "nettoyeur de documents")

Aujourd'hui, le format .doc est assez bien reverse-engineeré. Je ne crois pas qu'on aurait beaucoup de surprises en regardant les specs. (Qui sont d'ailleurs à disposition, sous NDA, des gouvernements.)

> Et au prochain ms office, ils sortiront un tout nouveau format, rendront libre les
> schémas à nouveau, mais en attendant, ils continueront à faire évoluer le
> format comme bon leur semble.

Ca ne me parait pas très différent de ce qui se fait dans le monde du libre ...

Même en LaTeX, les documents 2.09 ne compilent pas avec 2e ...

Si MS ne conserve pas la compatibilité Office 2003 dans les versions supérieures à 2003, ils font une grosse erreur marketing. (Tout le monde trouvera que c'est la merde et migrera).

Pour info, Word 2003 gère l'import/export en Word 2.x, qui doit bien avoir 15 ans d'age ...

> Une licence pour un logiciel est toujours attachée à une instance d'un logiciel.

Tu oublies les brevets.

cf. http://linuxfr.org/2003/12/04/14771.html(...) pour le système FAT, pourtant bien supporté un peu partout. Si ils font pareil avec les formats de leurs documents, on n'aura pas beaucoup avancé.

> - ne concerne que la version Pro

... d'après les rumeurs qui circulaient avant la sortie définitive, en effet. Je n'ai pas de MS Office 2003 sous la main, mais visiblement, on peut sauver en WordML dans toutes les versions. C'est l'utilisation d'un shema défini par l'utilisateur qui n'est pas possible avec les éditions non-pro (mais les non-pro n'en ont rien à foutre.)

> - n'est pas exclusif (apparement, le format .doc existe toujours, non ?)

Si j'ai bien compris, oui. Ca se défend pour garder la compatibilité avec les anciennes versions.

C'est clair que tant qu'a faire un format documenté, ils auraient pu donner les specs du .doc aussi, ça n'aurait fait de mal à personne !

Les scénarios "il pourrait y avoir n'importe quoi dans leur XML", tu crois pas qu'il faudrait arrêter maintenant qu'on a les specs ? (et une implémentation de référence ...)

Moi, à mon avis, c'est juste qu'ils n'avaient pas trop le choix : Les clients mécontents du format fermé (en particulier les administration) se barrent sous OpenOffice.org ...

Ceci dit, perso, je reste méfiant sur la question des brevets.