reno a écrit 3881 commentaires

> Vu l'implantation de MS-Office chez les entreprises et les particuliers, et la base de documents au format doc, on ne pourra se debarrasser de cette chienlit qu'avec une action de l'Etat. Bref la volonte qui pousse d'en haut je ne l'ai pas vue.

Bin l'etat ne peut pas dire acheter X ou Y, il doit quand meme rester impartial dans ses appels d'offre..
Par contre, il peut dire "acheter un traitement de texte avec un format de document ouvert".
Ce qui marche avec OOo mais aussi avec OfficePro (plus cher!) en utilisant le format XML..

> Et non, je ne pense pas qu'il y ait de difficultes d'adaptations particulieres entre MS-Office et OpenOffice.

Si tu parles de l'utilisation probablement pas, encore que pour les personnes tres habituees a une version de Word, cela les genera probablement au debut, pour la compatibilite entre document, ce n'est pas encore ca, le formatage est souvent pourri..

Certes, bien des normes sont inutilis'ee et entre le standard 'de facto' et 'de jure' c'est souvent 'de facto' qui gagne..

Mais bon, il faut etre optimiste: si cela devient une norme, et que des etats poussent a utiliser la norme [2 gros SI, surtout le deuxieme], on peut meme envisager que word se mette a supporter la norme..

Alors pour les documents la situation deviendrait comme celle du web, certe comme pour le HTML on peut s'attendre a avoir beaucoup de probleme sur des interpretations diverses de la norme, mais ce serait quand meme un gros progres vis a vis de la situation actuelle, non?

PS:
ceci dit il ne faut pas etre naif: meme si Microsoft ajoutait une compatibilite vis a vis de OOo, ils feront probablement comme pour leur format XML: ils ne changeront pas le format par defaut et ne l'integreront qu'a la version Professionelle d'Office, ce qui fait qu'on peut s'attendre a ce que le format .doc reste dominant longtemps..

Euh j'espere que tu l'as quand meme prevenu que c'était different parce que si elle fait son CV avec OpenOffice et qu'elle l'envoit en attachement..

Pour ce qui est d'une "complete" interoperabilité, je me demande si c'est juste pour le fond ou si ça inclut la forme? Les barres de révisions?

> Tu pense que la révolution Francaise était une mauvaise chose, que l'on aurait du laisser un roi au pouvoir?

Moui, euh note quand meme que la 'si fabuleuse' révolution Française a massacré pas mal de monde et au final il y a eu un dictateur Napoleon au pouvoir!

> Pour ce qui est des prisonniers politiques de Castro, il a appliqué ce qui serait appliqué dans nos pays si ont subissait ce qu'il subit.

Oui euh alors là, c'est franchement nul comme "justification", il ne subirait peut-etre pas tant de critique s'il n'y avait pas le parti unique et la liberté de la presse.

Et le fait qu'il ai viré une dictature d'extrème droite ou s'oppose à des actions douteuses des USA ne signifie ni ne justifie *rien* , Stalline a viré Hitler, et alors? C'est un super-gentil Staline?

Bien sur, si c'est OpenSource ce sera intégré à plusieurs distributions, mais si tu veux acheter une distribution pour faire tourner le software avec du support, tu prends laquelle?

Moi, personellement je prendrai une RedHat car s'ils ont investi 25 M$ dedans, tu peux penser qu'ils sont sérieux pour les évolutions, correctifs et supports du produit!

Esclavagisme moderne? 100 Euros par mois?

Non, tout depend du niveau de vie du pays: les ingénieurs Chinois avec lesquels je travaille sont payés beaucoup moins que les Français mais leur salaire est bien supérieur au notre si on le ramène au "SMIC Chinois", et ils sont payés bien plus de 100Euros par mois!

Ils n'ont aucun problème pour se payer des baby-sitter, femmes de ménages ou ouvriers, eux!

Quand a leur niveau technique, je dirais qu'il est peut-etre legerement inferieur a celui des Francais, mais c'est uniquement car en moyenne ils sont tres jeunes, et que l'Anglais est plus difficile pour eux que pour nous (et encore je suis probablement partial).

Donc au moins dans certains cas, les ingénieurs qui bossent à l'export ne souffre pas du tout d'"esclavagisme", la différence est que c'est une petite minorité du pays et que par contre les pauvres de ces pays sont beaucoup plus nombreux..

Euh merci pour le lien (le machin anti-spam est buggé et m'a perdu 5 minutes, mais j'ai fini par retrouver le bon message), mais j'avoue n'avoir pas tout compris, si ce n'est que la sémantique derriere a l'air puissante mais horriblement compliquée!!

Ca fait quand même très "usine à gaz" toutes ces règles complexes de sémantique..

OK j'ai trouv'e le select (en cas de conflit on peut choisir de quel pere on herite un element) mais tu peux preciser quels sont les problemes dont tu parles li'es a l'heritage multiple?

J'ai deja utilis'e l'heritage multiple en C++ sans probleme particulier et comme Eiffel impose la resolution des conflits, cela me semblait encore plus propre..

Je suis curieux de savoir quels sont les problemes qui apparaissent en pratique ..

>Au sujet de l'héritage non-conforme, il a était introduit en partie pour résoudre les problèmes lié à l'héritage multiple.
> L'ancien mécanisme pour gérer c'est problèmes, le mot clef "select" était loin d'etre parfait.

Tu peux préciser ce qu'est le select? Je ne le trouve pas dans mon (vieux) livre..

Après avoir appris la notion de "programmation objet" en lisant les livres de B. Meyer, j'avais tendance à considérer que la façon de faire l'héritage multiple en Eiffel comme une solution qui avait l'air élégante: en cas d'héritage multiple "en diamant", il faut renommer au moins une méthode dupliquée pour éviter les conflits et on peut choisir de reimplementer la méthode.


Pour ce qui est de la concurrence, en 93 Meyer étudiait une proposition, apparemment cela ne progresse pas vite!

> Au fait, Pascal est considéré par certains urluberlus comme un langage professionnel...

Le Pascal standard? Cela m'etonnerait!
Les differentes implementations qui ont toutes apport'ees leurs ajouts pour combler les manques du Pascal d'accord, mais peut-on vraiment parler de Pascal?

Tu as raison intégré n'est pas le bon mot, cohérente serait plus aproprié.

>Peux-tu donner une exemple ?
L'utilitaire de Mandrake pour la gestion des RPM, quand j'utilisais Mandrake, il n'était marqué nulle part dans l'aide de cet outil que c'était une surcouche d'urpmi qui lui marchait beaucoup mieux.

C'est une tendance assez globale des GUI de masquer totalement les outils en ligne de commande qui sont derriere, meme dans les docs!

Dans les outils d'admin graphiques sous HP-UX, ils donnaient les commandes executées ce qui permet de s'y retrouver en cas de probleme;

Bon etre obligé de faire des recherches sur le web ou sur IRC pour des choses qui devraient être intégré dans l'outil, ce n'est pas terrible..

> Parcque pour moi je ne vois pas en quoi une application "lourde" à
> lancée sera plus rapide sur un OS avec GUI "intégré", non
> franchement je vois vraiment pas le rapport.

Honnetement, je n'ai toujours pas bien compris comme cela marchait dans BeOS, il faut dire que si la reactivité m'a bluffée le manque d'application m'en a aussi detourné bien vite.
Je crois que tu as raison, c'est en partie de la faute un manque de feedback visuel ou mal intégré: pourquoi utiliser un splashscreen qu'on ne peut pas iconifié ou fermer (en cas d'erreur) au lieu d'une fenetre de demarrage équivalente?
L'autre partie étant une utilisation judicieuse des threads qui donnait des application moins figée: qui n'a jamais vu Mozilla figé alors qu'on aimerait bien pouvoir continuer a surfer sur d'autre tab par exemple..

> [Windows] mais pour autant la réactivité est très bonne

Tout est relatif.. La réactivité de Windows est meilleure que celle de Linux (la difference est assez faible) mais les deux sont pitoyables par rapport a celle de BeOS..

Je ne dis pas que la separation en couche de Linux est mauvaise, je dis juste que les couches sont peu integrees:
- souvent dans les GUI on ne donne pas le nom des commandes sous-jacente, ce qui est tres ennuyeux que l'IHM plante!
- comme je le disais quand la commande sous-jacente plante, pas d'avertissement: quand la fenetre disparait, c'est clair (et encore cela devrait etre mieux) mais si le plantage a lieu avant l'apparition de la fenetre, c'est penible: parfois j'attends un certain temps, parfois je trouve que c'est trop long et je me retrouve avec deux applications ouvertes..

Pour ce qui est de Syllable et des clones de BeOS, cela me parait aussi un enorme boulot, mais je suis peut-etre trop pessimiste [ dans un autre domaine, je pensais que les .doc ne mourraient jamais et voila que l'ISO veut standardiser le format d'OpenOffice! ], ce qui est dommage c'est qu'apparemment Blue Eyed OS le clone de BeOS bas'e sur Linux est mort (c'etait pourtant le plus pragmatique), ils devaient mettre leurs source en LGPL sur SourceForge, mais depuis plus de nouvelles..

> je vois vraiment pas ce qui empêche de concevoir un OS modulable, ou chaque couche est bien séparée, tout en orientant le tout côté GUI.

En theorie rien, en pratique souvent si tu concoit un OS uniquement sans GUI et qu'elle est rajout'e ensuite, la 'colle' entre les couches se voit..
Un exemple: sous Linux souvent les applications sont une surcouche graphique de commande et quand tu lances une applications et qu'elle se plante, souvent il ne se passe rien,pas de fenetre, rien.

Sous Windows si une application se plante, normalement tu as une fenetre qui apparait avec un message d'erreur.

C'est un exemple ou une meilleure integration apporte quelque-chose a l'utilisateur.

Aussi je ne sais pas si tu as test'e BeOS, mais c'etait un systeme vraiment agreable a utiliser: boot de l'OS et demarrage des applications super-rapide, application reactives (bon ok, il y avait tres peu d'applications).. Quand tu concois un systeme en couche, souvent l'efficacit'e est perdue: Linux est beaucoup moins agreable a utiliser du point de vue fluidit'e, r'eactivit'e.

Un exemple: BeOS boutait en moins de 20s jusqu'a l'interface graphique sur un Celeron333, Linux+X+KDE, c'etait plus d'une minute en ayant deja supprimer pas mal de demon inutile par rapport a l'interface par defaut.
Pour la fluidit'e/reactivite de l'interface (plus difficile a chiffrer), c'etait pareil..

Je ne dis pas qu'il est impossible de faire un systeme Linux aussi reactif que BeOS l'etait, mais franchement ce n'est pas pres d'arriver..

>Oui, le libre EST TOUJOURS mieux que le propriétaire

Euh, a niveau technique identique,oui, bien sûr, mais entre une solution libre qui marcherait mal et une solution propriétaire qui marcherait bien, non!
Si tu crois le contraire, cela s'appelle de l'integrisme..

Bof, ton argument est un peu creux: si par exemple, dans ton offre d'appel tu exige que tes documents soient stockés dans un format documenté pour des raisons d'inter-opérabilité.

La d'un coup tu viens d'interdire d'utiliser toutes les versions d'Office non-pro, je crois que les versions pro peuvent sauvegarder en XML mais comme ce n'est pas fait par défaut, je ne suis même pas sûr que cela conviendrait et le prix n'est pas le même!

J'ai aussi entendu dire que le XML fait par Microsoft n'était pas entierement récupérable, mais là j'ignore si c'est vrai: des que c'est fait par Microsoft tout le monde tape dessus..

>il ne s'agit pas du tout d'imposer des formats ouverts (ce qui serait aussi illégal que d'imposer des formats privés en réalité)

Ah? Alors la j'aimerais bien que tu m'expliques d'ou tu sors ce raisonnement curieux!

T'en a marre, deja?

Pour ce n'est pas pres de changer, les standards de faits, ça evolue difficilement!

A mon avis, un des seul espoir pour que que ça bouge serait que les administrations imposent des formats ouverts pour communiquer avec eux, mais ça n'est pas près d'arriver..

Personellement je pense que le reverse-engineering n'est pas equivalent a decompilation, la decompilation (traduction assembleur --> C) est juste un des outils utilis'e pour faire du reverse-engineering.

D'ailleurs il n'est pas obligatoire de faire une decompilation d'un logiciel pour faire du reverse-engineering, on peut y arriver aussi en espionnant les echanges de donnees par exemple..

Oui sous Mac, il me semble que l'utilisateur ne voit que 3 repertoires de base:
/Systems, /Application et /My document

Je ne me souviens plus des noms exact, mais dans l'esprit je crois que c'est cela.
Bon cela doit desorient'e un peu quand on se retrouve dans la console et qu'on voit "tout autre chose" mais c'est sur que c'est plus parlant.

Personellement les noms courts var,bin,etc ne me generait pas sous Linux s'il 'etaient planques sous un /system mais bon la ils sont un peu trop visible pour des utilisateurs normaux et cela fait desordre: c'est le basar pour le browser de fichier, avoir seulement une arborescence du type: /system /application /home /tmp /media (l'equivalent de /mnt) serait plus propre, mais changer tout l'existant c'est impossible..

Le probleme est que le mot est surchargé, un processeur est confondu avec la puce ou l'unité qui traite une thread sur la puce.

Le probleme c'est qu'utiliser le même mot entre un CPU complet et une unité d'un CPU SMT (ce qu'Intel appelle HyperThreading, beurk), cela induit en confusion.

A priori entre un bi-proc classique et un bi-proc SMT a frequence egale je prends le bi-proc classique!

Donc même si c'est incorrect, parler de SMT, multi-core, SMP donne plus d'informations que juste dire ce sont tous des multi-processeurs..

Je ne devrais pas repondre a ce troll, mais la reconnaissance vocale n'est pas pres de remplacer un clavier (fiabilite, bordel en open-space), ce qui n'empeche pas qu'elle puisse etre tres,tres utile pour les handicapes, les applications telephoniques, etc.

Pas que pour Windows, tu pourrais tres bien imaginer qu'un vendeur de Linux fasse payer le support au nombre de CPU utilis'e..

> Autant que je sache, le processeur est une puce.

Je pinaille un peu mais ce n'est pas necessairement vrai: a une epoque ou l'integration etait faible il est arrive que les processeurs soient realise par plusieurs puces (avec des processeurs "en tranches de 1 bit" par exemple).

Ceci dit, je suis d'accord avec toi sur la terminologie, multi-core decrits bien la situation.

> EMT64

A priori Intel n'a pas eu besoin d'acheter quoi ce que ce soit a AMD (accord de license croise).

> VT aka “Virtualization Technology” aka “Vanderpool/Silvervale Technology”
> Alors là je suis sceptique. Intel annonce la virtualisation comme une avancé majeur dans le monde informatique. Pourtant, j’utilise ça depuis 2 ans sur des serveurs IBM P690.

(soupir) Ca s'appelle du marketing, tu ne veux pas non plus qu'Intel dise qu'ils vont faire un truc qui n'est pas neuf du tout, non?
C'est neuf pour les 80x86, ce qui represente quand meme une grosse evolution.

[Coup'e question de nommage sans grand interet]
> Enfin la question la plus importante, toutes ces évolutions seront-elles prisent en compte par les noyaux libres ?

Je ne vois pas pourquoi elles ne seraient pas pris en compte??

L'AMD64 l'est deja (EMT64 n'etant qu'une variante), le multicore etant une variante intermediaire entre SMP et SMT les deux etant deja support'e cela ne devrait pas etre trop dure, pour VT je ne sais pas: la description est assez legere dans l'article, mais j'imagine que tout ceux qui s'interesse a la virtualisation sous Linux doivent en saliver d'avance..

L'article est un peu leger en detail, je trouve leurs comparatifs d'appareil photo, de carte video, d'ecran LCD bien meilleurs..

Ce que je voulais dire c'est que RMS a beaucoup encouragé le projet "The Hurd" sans pour autant que ce projet aboutisse à grand chose (du point de vue nombre d'utilisateur, je ne critique absolument pas les developpeurs).

Donc les critiques ou encouragements de "stars" ou pas n'influencent pas toujours..

D'un autre coté, je me souviens que quand Alain Cox s'est interessé a des problemes de lenteur du gestionnaire de fichier Gnome les problemes ont été résolu assez rapidement, je pense que ça doit motivé pas mal quand tu as quelqu'un comme AC qui se manifeste..