Matthieu Moy a écrit 3251 commentaires

Quelqu'un a déjà utilisé DejaGNU ?

C'est un truc pour faire des tests de non-reg je crois.

Pour les pros d'unix, oui (et en général, ils apprennent vite à lire le postscript et le LaTeX "dans le texte"). Pour un newbie, je demande à voir ...

> car pour eux libre et en plus gratuit se traduit par " ca ne fonctionne forcément pas bien puisque c'est gratuit". Ca ne marche pas si ils prennent une distribution commerciale, ou bien si ils créent un service qui fournit du support à l'intérieur de l'administration en question.

Oui mais non. La possibilité d'utiliser un interprêteur, c'est surtout pour les premiers tests et le debug (La phase ou on trouve un bug toutes les 5 minutes ...) Ensuite, pour faire une vraie campagne de tests, oui, il faut un truc automatique. Sinon, l'idée d'utiliser plusieurs environnements (Compilateur + interprête) n'est pas non plus une mauvaise idée au sens ou ça permet de tester la portabilité du logiciel. Mais là aussi, les tests de validation finale doivent être passés dans le même environnement que la release finale.

Pour les commandes à executer, c'est limité au sens ou tu peux difficilement jouer de toutes la puissance des wildcards, substitutions, commandes shell de gourou, mais tu as une bibliothèque d'actions prédéfinies intéressantes, et tu peux en rajouter. Par exemple, pour une arborescence de fichier Java à compiler, rien à faire, et en plus, ant et javac tournent dans le même processus, donc, pas besoin de relancer de JVM, et ça va vite. Par contre, pour des compilations censées être rapides, le temps de lancement d'ant est assez décourrageant. (Genre, pour dire machin is up to date, c'est long ...)

Non, puisque le document Word que tu ouvres, il n'est pas propriété de MS. Les graphismes de WC, ils sont proprio.

En plus, IDC, c'est une boite sérieuse, c'est écrit là :

http://www.microsoft.com/windows2000/migrate/unix/tco.asp(...)

IDC, a recognized leader in cost analysis methodologies,

Ben non, justement, dans un vrai interprête, y'a jamais de code natif. Le code de l'interprêteur ressemble à ça :

switch(instruction) {
case INSTRUCTION1:
exec_inst_1(); break;
case INSTRUCTION2;
....;
}

Un autre intérêt de la chose est que c'est portable, alors que la partie génération de code d'un compilo doit être réécrit pour chaque plateforme. (Ici, on s'en fout, vu que g++ existe déjà sur quasiment toutes les plateformes.)

Pour ton environnement interactif à base de bash, essaye de lancer ton programme, de l'arrêter au milieu d'une fonction, de changer la définition d'une autre fonction pendant ce temps là, de continuer un peu l'execution, de créer une nouvelle classe, d'appeler une méthode de cette classe, puis de terminer l'execution. Le tout sans redémarrer le programme. (note : C'est à peu près ce que font les utilisateurs d'Emacs quand ils trifouillent leur config. On va pas redémarrer Emacs à chaque fois ...)

Norme ISO, mais tellement bien foutue qu'il n'y a pas deux compilo qui font la même chose sur des programmes compliqués ...

C'est souvent lié quand même. L'interprête parse le programme et charge une structure en mémoire. Du coup, il est très facile de faire un environnemnet interactif.

En général, quand un environnemnet interactif dit qu'il "compile" un programme, il le compile en byte-code (d'ailleurs, pour les dérivés de lisp, c'est assez rare d'avoir de la vraie compilation en code natif), qui est ensuite interprêté. Pour faire de la vraie compilation à la volée, c'est plus difficile, vu qu'il faut charger dynamiquement un morceau de binaire, faire l'édition de liens, etc. Ca casse une bonne partie des optimisations (inlining, ...). Je ne connais pas d'environnement interactif qui compile réellement le code en code natif.

Y'a quand même un truc qui pourrait être intéressant : Faire des sessions interactives. On peut déjà faire un peu ça en gdb avec "p fonction(argument)", mais c'est très limité.

Le projet GNU a commencé en 1984, Linux en 1991. NT est sorti en 1996, je ne sais pas quand a commencé le developpement.

Il me semble bien que ce que tu as fait est explicitement interdit par la licence d'utilisation des brevets sur le pdf.

> ses spécifications sont disponibles pour quiconque se donne la peine de retrouver le lien

Essaye d'ouvrir un pdf crypté avec xpdf et regarde le message d'erreur. En gros, ça dit :

"Aille, celui-la, j'ai pas le droit de l'ouvrir. Désolé :-("

> Mouais mais non, concernant alcatel, le "bug" est surtout que si on publie un document contenant des révisions

Tout à fait. D'ailleurs, OOo fait ça aussi en version 1.1beta.

Par contre, le truc gênant, c'est que souvent, c'est activé par défaut et l'utilisateur lambda ne le sait pas.

> les spécifications qu'il *NE* publie *PAS* (rtf, doc,...)

Pour le .doc, oui, mais bon, le RTF, c'est un standard ISO il me semble ... Le truc c'est que chez MS, on fait un standard ISO pour faire bien, mais ensuite, on ne l'utilise pas ...

En quoi ils forcent ? Elles peuvent toujours télécharger la version download, non ?

> les defendeurs de Java affirment que les interfaces sont mieux que l'héritage multiple,

Ils n'ont pas tord.

Une interface ne change pas la taille de l'objet par exemple. Or, en C++, quand tu as de l'héritage multiple avec des données, le cast de pointeur vers l'un ou l'autre des parents entraine un décallage d'addresse, qui fout la merde dans bien des cas. Par exemple, (parent *)x va marcher là ou (parent *)(void *)x va faire un segfault.

Le C++ n'est pas capable de faire le lien entre une implémentation héritée d'un parent et une méthode virtuelle pure héritée d'un autre parent. Il dit toujours que la méthode n'est pas implémentée.

En Java, on est sur de ne jamais avoir de problème si la hierarchie de classes est un DAG.

> a rétention des descendants et la covariance !

C'est quoi ?

Un logiciel libre ne *peut* pas faire de DRM. Si un logiciel est modifiable, on peut faire ce qu'on veut avec les données. Si on peut faire ce qu'on veut avec les données, ce n'est plus du DRM ... Regarde les pdf non imprimables. Si un logiciel vraiment libre peut les lire, il suffit d'implémenter la fonction "imprimer" dans ce logiciel ...

http://www.microsoft.com/france/securite/entreprises/palladium/faq-tech.asp#faq32 "Palladium" est-il l’implémentation de Microsoft de la spécification TCPA (Trusted Computing Platform Alliance) ? Non, "Palladium" n’est pas une implémentation de la spécification TCPA. Les deux projets ont effectivement certaines caractéristiques communes, telles que l’attestation et le stockage scellé, mais leurs architectures sont fondamentalement différentes. (Pour en savoir plus sur l’approche de la TCPA, vous pouvez télécharger une copie de la version 1.1 de sa spécification sur le site Web http://www.trustedcomputing.org/). Tu as vu ou que Palladium utilisait TCPA ?

Gni ?

Tu peux relire un peu les docs sur TCPA et me dire d'ou tu sort ça ??

Moi, je peux ...

http://www.trustedcomputing.org/docs/tcpa_layout_v1.3.pdf(...)
page 6

http://www.research.ibm.com/gsal/tcpa/tpm-1.1.tar.gz(...)
Un pilote TCPA pour Linux sous licence GPL, et qui n'a rien à voir avec Palladium.

La FAQ Officielle de TCPA dit ça :

2. What are the goals of the TCPA?
Through the collaboration of hardware, software, communications and technology, vendors drive and implement TCPA specifications for an enhanced HW and Operating System based trusted computing platform that implements trust into client, server, networking, and communications platforms.


Les gars, si vous voulez lutter contre un truc, il faudrait peut être apprendre à connaitre son ennemi, non ?

> Encore une fois TCPA n'est pas DRM !

TCPA est la couche logicielle + matérielle sur laquelle on peut batir un DRM efficace.

Du DRM 100% logiciel, ça existe déjà (DVD crytpés, pdf non imprimables, fichiers WMA, ...), mais c'est crackable avec un effort raisonnable.

Il y a d'autres applications intéressantes sur lesquelles je ne crache pas par contre.

>Parce qu'à première vue, dire qu'une communauté auto-gérée va plus vite
>qu'une boîte commerciale, ce n'est quand même pas si évident que ça !

Oui, mais communauté ne veut pas dire auto-gérée.

Linux est développé par plusieurs entreprises (IBM, Red-Hat, SuSE ...) + des individus. On peut appeler ça une communauté, mais pourtant, il y a des moyens qui suivent. Idem pour Gnome (SUN contribue pas mal je crois depuis qu'ils ont choisi de l'adopter pour Solaris), GCC (développé en grande partie par Red Hat, et Ada Core Technologies pour le front-end Ada), et pleins d'autre projets.

Pour l'exemple Debian Vs Mandrake, c'est difficilement comparable. Debian a un cycle de release en version stable beaucoup plus long que Mandrake, mais c'est parce que leur définition de la stabilité n'est pas la même.

C'est contraire au principe de séparation des pouvoirs, qui est une des bases de la démocratie.

En principe, les affaires de justices se règlent avec la justice, et non avec les gouvernements. Je dis bien /en principe/.