mdlh a écrit 404 commentaires

Sans oublier qu'il y a a ce jour plus de logiciels qui lisent (plus ou moins bien) le format de MS Office que de OpenOffice.

Si on critique MS Office a se restreindre a Windows, OpenOffice se restreint a Linux sur les plateformes ia32, ppc, s390 et sparc.

De plus si je ne me trompe pas, seul OpenOffice peut lire son propre format. Le format est bien ouvert mais je ne connais pas a ce jour d'applications equivalentes capable de lire OpenOffice.

Par contre on trouve OpenOffice, abiword and probablement d'autre applis capable de lire des documents MS Office pas trop complexe.

Etant utilisateur de Linux sur une plateforme que je n'ai pas cite plus haut, je me vois contraint de demander du .doc

Et je ne suis pas sur d'etre le seul dans ce cas (On peut ajouter ceux qui trouvent que OpenOffice est beaucoup trop gros).

Si, de ce fait, le format MS Office assure sa perennite, je ne suis pas certain que l'adoption de OpenOffice soit aussi rapide qu'on le souhaite (meme si Format de Fichier != Application).

Ensuite ce n'est pas au compilateur de se soucier de ça : le processeur gère lui même un cache d'instruction en fonction de la fréquence d'apparition des instructions, et tu ne pourras jamais exécuter le code tout droit, il faut obligatoirement faire les tests de nullitée. Sans compter que de toute façon le processeur évaluera peut être les 2 branches s'il a rien d'autre à foutre (faut bien remplir le pipeline).

Merci. C'est grace a des raisonnements comme ceux la qu'on se retrouve avec du code ultra lent sur Itanium.

Pour info dans le cas de l'Itanium c'est bien le compilateur qui s'en soucie et qui va (tenter d')annoncer au processeur "tiens compte du branchement qui suit".

En plus je comprend rien a ce que tu dis a propos "de la fréquence d'apparition des instructions". Il etablit des statistiques sur les instructions executee dans le passe et il s'en souvient quand il revient dessus? Tu fonctionnes sur quel model? Parce que la tu m'interesses.

On m'a dit aussi qu'en programmation un "goto" c'etait pas bien. Et d'ailleur mes profs d'infos ne m'auraient pas pardonne de les utiliser.

Cependant tu pourras lire des ecrits de Knuth te disant que dans certain cas, c'est tout a fait acceptable et c'est d'ailleur la meilleure des solutions.

Tout ca pour dire, sans vouloir reduire la qualite de tes cours, qu'il est parfois beaucoup plus simple d'interdire l'utilisation d'une fonctionnalite plutot que d'enseigner le cadre idoine de son utilisation.

Pour en revenir aux variables globales, on peut les considerer dangereuses si on utilise les criteres ennonces dans l'article en lien. Cependant il faut avouer qu'au dela de l'aspect simplicite, l'acces en lecture/ecriture est beaucoup plus rapide.

Juste pour l'histoire:

Beaucoup de personnes ici se sont etonnees (pas tant que ca en fait) de la mediocrite de l'Itanium lorsqu'ils ont effectues leur tests. J'imagine que leur plateforme de test etait Linux. Juste pour preciser: La majorite des *glorieux* benchs Itanium viennent de HP-UX, pas de Linux.

Alors quand on m'annonce la fin de HP-UX, ca me fait bien *****. HP-UX est surement a l'oppose du logiciel libre: Tu choisis pas. Ca ressemble a un autre OS vous me direz. Mais contrairement a l'Autre, ca marche, et plutot bien.

Bref, plutot que de discuter sur la mort de HP-UX, il serait peut-etre bon d'en recuperer quelques miettes pendant qu'il en est encore temps. Pendant ce temps la je vais m'ouvrir une bonne bouteille de clava et admirer mon score aller dans l'infiniment negatif.

Dans le chapitre d'exemple presentant les differentes distribution:

C'est la troisième grande distribution commerciale, produite par une société
allemande. D'une excellente finition, elle pèche par certains détails. Ses
outils maison, notamment YaST, ne sont pas publiés selon une licence de
logiciel libre.

il est marrant de lire:

Le directeur marketing d'Intel est un gros connard sur le fait qu'Intel n'aurait pas donne de machine Itanium au projet, alors qu'on ne sait pas si Intel l'a fait ou pas....

Par contre, pour avoir vu le nombre de machines Itanium donnees par Intel et autres pour ce genre de developpement, si NetBSD n'en a pas recu, c'est qu'ils ont reellement loupe la vague.

Je me souvient plus de quel projet *BSD il s'agissait, mais il y a quelques annees nu des developeurs kernel Linux pour IA64 faisait mention des developeurs BSD pour Itanium. La question n'est pas de savoir ce qu'il disait, mais le fait est qu'il y avait une equipe de portage a cette epoque.

A moins que tu ne tapes tes caractères accentués avec les séquence d'échapement \xxx ?

Ca marche tres bien et c'est finalement pas tres contraignant, surtout quand tu as un clavier US ou un terminal ne supportant pas les accents. Ce qui etait le cas a l'epoque ou j'ai commence.

j'ai l'air bien con avec mon mémoire de stage fait avec un Latex sous un Red-Hat il y a 5 ans

TROLL L'erreur ici c'est RedHat, pas LaTeX

Et puis un jour tu grandiras et tu ne l'utiliseras plus que pour tes publications.

Je m'en sert pour mon CV (adaptation de ESIEEcv), generer des catalogues, faire des cartes de visites, taper les recettes de ma maman... Bref pas que des trucs que l'on trouve dans les revues IEEE.

per ex. à l'époque on n'arrivait à rien tirer de l'extension babel

J'utilise babel depuis 1996 sans probleme.

J'avoue que LaTeX est pas toujours ton meilleur amis. Mon cas n'est pas representant de la mojorite de la population, et probablement le tien non plus. Alors quand je lis:
Alors toi personnellement tu gardes Latex chez toi si tu veux

Je me dis que cette phrase aurait mieux fait de rester chez toi.

Je mets les pieds dedans....

Peut etre qu'ils se sont rendus compte que Itanium correspondait mieux
a leur besoin?

J'ai bien lu ta partie exactement le même programme de simulation. Cependant quid de l'existant? Comment leur calculateur va s'integrer dans leur infrastructure?

On a surement pas tout les parametres, et j'imagine que vu le prix, ils ont prit leur temps pour faire leur choix.

D'un autre cote, on peut se poser la question inverse: Pourquoi les usa ont choisit BlueGene/L alors que le CEA va utiliser Itanium?

on les persuade que derrière chaque black il y a un voleur et derrière chaque musulman il y a un terroriste
Perso j'ai pas vu beaucoup de differences avec les medias francais.
on les nourrit à coups de MacDo
McDo est bien moins present aux US qu'en France, pour ce que j'en ai vu.
on les informe à coup de FoxNew
Et oublie CNN, NBC et autres.
et on les persuade qu'ils sont libres et qu'ils sont dans la plus grande démocratie du monde
C'est pas trop ce qui en resort des medias et des gens qui en parlent.
et ils ne sont pas aimés dans le monde
J'ai pas visite assez de pays pour verifier.

Bref, une vision assez limitee de ce pays. C'est ce genre de raisonnement qu'on reproche aux ricains de faire.

reponse a moi-meme:
login: guest
password: y en a pas

Comme les screenshots montrent une avancee certaine du projet, et intrigue par le numero de la version, je suis curieux de regarder la liste des bugs recences...

Je clique sur "Bug Database" et la... login/password ?

Bon ca fait deux fois que ca tape sur le service info donc la je reagis...

Le pb c'est que lorsque chacun a ca petite base, avec des duplications de donnees, que l'on retrouve encore une fois dans une base au niveau du support informatique tu fais quoi?

Tu proposes de travailler ensemble afin de mettre en place une base unique ou chacun va pouvoir retrouver ces donnes, mais aussi celle des autres et enfin s'assurer qu'on a les infos a jour en beneficiant des mises a joru des autres.

Le temps de finir la phrase, t'as plus personne. Chacun a developpe son petit bebe et veut pas qu'un autre y touche. La premiere fois, tu dis c'est dommage, la seconde fois tu demandes ce qui se passe, la troisieme fois t'abandonne.

pour done c'est possible, mais j'ai pas la conf en tete.
C'est le cas de ftp-master sur debian.
Dans upload, tu peux mettre les fichiers de ton package source. Tu peux lister le contenu aussi.

Par contre pas le droit de lire les fichiers ou de les ecraser.

Linuxfr est un site francophone a en juger les commentaires de personnes outre-atlantiques. Ca donne a linuxfr un cote internationale (probablement moins etendu que slashdot, mais quand meme).

Fait gaffe, on va te demander si tu as poste des bug reports...

C'est pour ca qu'on developpe l'idee du smart data center. En gros en reorganisant ta salle machine, tu gagnes dans l'efficacite de ta clim. Je vais pas rentrer dans les details, mais c'est comme si tu changeais l'algo de ton appli pour qu'elle aille 2x plus vite plutot que de payer un microprocesseur 2x plus puissant.

Dans le cas des serveurs, je pense que Debian est idéal quand les sysadmins sont compétents.

Juste pour eviter des envolees:
Tu sous-entend pas qu'utiliser autre chose que Debian signifie etre incompetent?

Je suis pro Debian mais quand meme j'ai un minimum de respect pour les non-debianneux

C'est surtout qu'on a du mal a integrer que c'est pas parce que ca marche chez soi que ca marchera chez les autres et inversement.

Quand je lis: "Chez moi ca marche pas" et chez un autre "chez moi ca marche", faudrait retenir ca marche pas toujours (ce qui mathematiquement veut dire: ca marche pas).

Un petit bug qui arrive de temps en temps chez l'un, qu'il peut considerer comme mineur car c'est une appli qu'il utilise une fois tous les 22 du mois, peut etre un bug ultra frequent chez l'autre.

Tout ca pour dire que ce n'est pas parce que une dizaine de personne va dire ici que ca marche bien que:
1- ce sont des menteurs
et/ou
2- c'est la realite

Previsions meterologiques, detections de tornade, simulation du big bang et autres.

Y'a une liste de tout les patchs fait par debian quelque part d'ailleur ?

La pluspart du temps , on contacte le developeur d'origine et on corrige l'erreur dans le source original. Comme ca tout le monde en profite. Et on utilise pas toujours l'adresse e-mail Debian.

cas 1/ ca tourne et y'a rien a faire (ce doit etre 99.99% des paquets)

Desole, mais le chiffre est bien plus bas. C'est tout bete mais pas mal d'applis ont ete code avec l'architecture ia32 en tete. Genre sizeof(void *) = sizeof(int). Ca implique pas mal de pb quand c'est pas le cas. Et c'est qu'un exemple.
Ca ca se detecte, mais on a aussi des bugs qui se revelent a l'execution seulement. Et faut le trouver. Evidement, le nombre de volontaires pour trouver d'ou viens le bug est assez restreint.

Un qui etait pas mal (sur hppa) etait "more", qui n'est pas une applie marginale. Le code s'amusait a lire la pile d'appel... sans verifier dans quel sens la pile "empilait". Donc des cochoneries on en trouve partout.

Apres, la politique est de remonter le bug chez l'auteur. Ca peut prendre du temps, surtout lorsque l'auteur du soft s'en fout un peu de savoir que son appli tourne pas sur une autre arch.

cas 2: Je confirme. Y a deux possibilite:
- La liste explicite des arch supporte est specifiee dans le paquet
- L'autobuilder a une liste "not-for-us" de package a ne pas construire.

cas 3: comme je l'ai dit plus haut, le nombre de developeur est assez restreint. Ce qui ne veut pas dire que le nombre d'utilisateur l'est aussi. La majorite des developeurs debian sont la pour packager des applis (je blame pas), et tres peu sont la pour s'assurer que ca marche sur leur archi preferee.

Y avait quelques problemes de paquets. Jette un coup d'oeuil a la liste pour les problemes de dependances. Mais ca reste relativement mineur.

Tu devrais savoir que l'équipe d'Ubuntu a elle aussi beaucoup contribué au développement de Debian... Je ne vois pas où tu veux en venir.

Je reagissais au fait que tu disais:
Il y eut tout d'abord la sortie d'Ubuntu, qui a réussi avec quelques dizaines de développeurs à réussir ce que Debian n'avait pas réussi avec quelques milliers de développeurs...

Qui peut s'interpreter comme "que des branXXXXX". Bon maintenant tu precises:

Je crois que tu m'as mal compris... Je disais simplement que Ubuntu a réussi certaines choses (accessibilité aux débutants, simplicité d'installation et d'administration, intuitivité) avec une petite équipe que Debian peine à mettre en place....

Effectivement, je comprends mieux. Mais ca ne change pas trop mon point de vue: Debian peine a mettre en place la meme chose, mais sur quelque choses de plus gros: Un plus grand nombre d'architectures, un plus grand nombre de paquets, ne pas choisir pour l'utilisateur une solution par rapport a une autre.

J'ose te demander sur quelle "architecture" tu tournes ?

Pas de pb. J'aurais juste du mettre ca au pluriel:
Sparc, hppa, IA-64

Il y eut tout d'abord la sortie d'Ubuntu, qui a réussi avec quelques dizaines de développeurs à réussir ce que Debian n'avait pas réussi avec quelques milliers de développeurs...

Ubuntu etant base sur Debian, Ubuntu beneficie de la contribution de ces quelques milliers de contributeurs.

De plus Ubuntu != Debian. Je peux installer Debian sur ma machine. Je peux pas installer Ubuntu. Pourquoi? Parce que ma machine ne fait pas partie de la liste des architectures supportees par Ubuntu. Et l'un des pbs qui empechent l asortie de saege, c'est lie a une architecture non supporte par Ubuntu.

Es tu sur de bien connaitre Debian?

Si. Cependant, il faut prevenir le processeur a l'avance qu'il va devoir se bouffer du ia32. Ca c'est pour la theorie. La pratique, dans un OS avec plein de libs, tu peux pas mixer ia32/ia64:

- Une appli ia64 peut executer une appli ia32
- Une appli ia32 ne peux pas executer une appli ia64
- Une appli ia32 doit avoir toutes ces librairies en ia32 (pas de changement de mode via les appels de fonctions).

D'ailleur, le premier compilateur Intel pour ia64 fournit etait une application ia32. Le linker, lui, etait une application ia64.