Sytoka Modon a écrit 4551 commentaires

Va faire un tour dans le code de zoppe -> []

Si GCC devient plus intelligent dans cette version (gain de 20% annoncé), est-ce que gcc va rattraper son retard sur icc pour l'architecture Itanium. En effet, pour cette architecture, le microprocesseur execute les instructions dans l'ordre d'arrivée et c'est au compilateur d'être intelligent. L'idée, pas idiote développé par Intel, est d'éliminer des milliers de composants du microprocesseur dédié à l'ordonancement pour les remplacer soit par du cache, soit par de la puissance de calcul.

Le revers de la médaille est d'avoir un bon compilo et que l'architecture interne des versions d'Itanium ne change pas trop. Vu la cadence de sortie de celui-ci, il n'y a pas de risque !

A noter que depuis la lenny, il ne faut plus dire 5.0r2 mais 5.0.2 !

En effet et c'est nouveau, le fichier /etc/debian_version est mis à jour ce qui n'était pas le cas avant des versions en r...

En pratique, cela ne change rien mais signifie simplement que la machine est à jour avec le dépot debian. C'est plus pratique comme manière de faire et plus 'pro' que l'ancienne appellation r2, r3...

Intégré ne veut pas non plus dire refaire la roue. Ce qui est important, c'est que si le code n'est pas compilé en statique, les bibliothèques sont partagés (si elles sont utilisés ailleurs).

Comme je ne pense pas que mozilla a tout recodé dans son coin, il devrait y avoir du partage dans l'air... lorsque les distributions auront intégré cette version de mozilla.

> Bref, quand on ne sait pas, on évite de lancer des remarques comme celles là.

Parce que toi, tu ne dis jamais de bêtises ! Contrairement à toi, moi quand un tube fait sa décharge, je ne suis pas à l'aise. Je ne trouve pas que ce soit un comportement raisonnable même si d'après toi, il n'est pas dangereux.

Ensuite, j'ai pas dis que les écrans plat étaient mieux. J'ai dis que je n'en donnais pas car je n'en avais pas que l'on ne se servaient plus. Les écrans que nous donnons sont des tubes et en général vieux de plus de 6 ans... Je le vois bien que les écrans plats vieillissent pas si bien que cela.

Enfin, pour moi, un écran flou est dangereux... car je ne pense pas que cela soit bien pour la vue. Mais manifestement, nous n'avons pas le même point de vue !

Tu remarqueras que j'ai mis un SI en grand et que je ne participe pas directement à se genre d'opération. Cependant, je donne tout mon vieux matos a une assosiation qui en recycle une partie pour les enfants en faisant ce travail sur la qualité du matériel à garder (car j'ai donné des écrans impeccables mais qui ne servaient plus).

Si tu sais, tant mieux, moi je ne sais pas. Je vois que les vieux écrans balancent une sacré décharge au démarrage et j'ai de moins en moins envie d'être en face de ces décharges.

Pour la télé, on est collé ... à plusieurs mêtres. Il y avait beaucoup de différence entre un tube télé et un tube PC. Pour avoir quantité de tube, je peux certfier que la plupart veillissent mal. Après 8 ans, il n'y en a pas tant que cela qui reste de bonne qualité.

Je ne vous demande pas de partager mes choix mais moi, je ne met pas mes gamins sur du matos que moi je ne veux plus car il me fait mal aux yeux.

Sous ce titre accrocheur, je suis contre ce genre d'opération SI elle est réalisé dans les conditions suivantes : donner des vieux PC aux petits parce qu'on ne supporte plus de travailler dessus !

Je ne participe pas directement a ce genre d'opération car je n'ai aucun écran plat mais que des tubes. Je refuse de mettre mes gamins (et ceux des autres) devant des tubes que moi même je ne supporte plus car d'une qualité aujourd'hui dépassée. De plus, on est face à un canon à électron et plus le tube est vieux, moins j'ai confiance...

Bref, c'est comme pour le wifi et les portables, je me méfie de ce qu'on ne voit pas pour les enfants.

> il sera de plus en plus utilisé par les appli desktop

Et je trouve ca très bien !

Que l'IHM soit enregistré en XML plutôt qu'en dur, je ne vois pas ou est le problème. La définition d'une IHM n'a rien a voir avec la configuration du logiciel ! Je ne parle que de configuration, notamment dans /etc, ou le XML n'a pas sa place à mon sens sauf peut être des cas particuliers. Or, on nous transforme petit à petit le /etc (ou le ~/.config) en un mic mac de XML. Cela va finir par être incompréhensible et on va se retrouver comme sous Windows, avec une espèce de machin ou tout sera mélangé et pas grand chose ne sera commenté...

Le problème est que le XML s'introduit petit à petit partout. Les grands constructeurs en mettent dans leur gamme a grand d'IHM. Cela a pour conséquence :

- l'IHM n'est pas toujours libre...

- debian est très bien mais ne peut pas ré-écrire tous les programmes pour virer du XML ici ou la !

Le dernier exemple que j'ai en date et qui me traverse l'esprit est heartbeat2 et GFS de Red-Hat. Il y a aussi tout le tralala Tomcat. Ce sont certainement de bon outil mais conçu pour être piloté par une IHM. Cela se sens à la gueule du fichier de conf.

Je ne suis pas contre les IHM comme valeur ajoutée et comme manière d'introduire cela un peu partout plus facilement (PMI, PME...). Ce qui me chagrine, c'est la conception des service sous jacent qui n'ont pas été fait pour être humainement compréhensible.

C'est ce que j'ai partout ... sauf sur les machines de calcul qui ont un support !

C'est vrai que chez Microsoft, vous êtes des spécialistes de la question ;-)

Désolé mais autour de moi, ton serveur a la réputation de prendre un homme temps plein !!

Deux autres questions dans ma réponse :

- peux-t-on se connecter sous le compte root. On parle ici de PME et la première chose que je vois avec la Suse est que dès que le support vient, il se logue en root sous X !

- si interface web alors il y a un serveur qui tourne. Mais ce qui m'intéresse est-il possible de gérer les choses en mode console. Je prèfere une bonne interface ncurses réactive à une application Web mal codé, peu réactive et au final plus que dangeureuse.

Pourquoi ne pas suivre la trace de debian avec son debconf qui a un backend gtk et un backend curse (et qui pourrait avoir un backend web). Ainsi tout le monde est content. Si a cela on ajoute une couche d'écriture pour avoir des formats humains modifiable via vi, ce sera parfait.

Hier on avait des formats de fichiers de configuration humains et les machines les lisaient bien. Aujourd'hui, c'est à l'homme de s'adapter à la machine car celui-ci utilise des environnements qui mettre des boutons à click de partout mais ne savent plus faire un parseur adapté au problème.

OK si tu peux installer le paquetage sans avoir la dépendance X ! C'est le cas chez debian. Si tu me dis que tu n'as pas un paquet Xorg sur ta mandriva server, alors OK.

Je veux des serveurs qui ne font qu'une chose et qui sont configurés via cfengine. Je veux le minimum de paquet pour avoir le minimum de bogue et de mise à jour. X, j'adore et je trouve que c'est un truc merveilleux mais c'est un gruyère...

Parce que je ne veux pas l'installer...

Parce que je veux que cfengine gère mes fichiers de conf, donc je veux des fichiers de conf fait pour les humains et pas du XML....

Si tu suppose que tu as une IHM derrière, alors la config est un bric a brac de XML ou est mélangé paramêtre global et parametre de conf pur. Je le vois en pratique, les trucs à fichiers de conf en XML ne sont quasiment pas paramétrable sans IHM.

Comme ces entreprises nous mettent du XML partout dans /etc, il leur faut ensuite eclipse pour développer une super interface graphique de la mort avec 3 millions de ligne auto-généré rien que pour faire leurs boites de dialogues...

Bref, comme toi, ils me gonflent. Il ne va bientôt plus être possible d'avoir un serveur sans X !

L'objectif est d'apprendre l'algo, pas les subtiltés du C. La notion de pointeur et de référence en C fait que tu perds du temps à comprendre le *, les ->, les & ...

En Pascal, c'est bien plus lisible. Si tu passes un paramêtre qui sera modifier à une procédure, tu mets var, etc. L'objectif premier est d'apprendre l'algo au lycée.

J'ai connu plein de gens qui ne comprenais pas pourquoi on ne commençais pas par le C mais ils en faisaient tous les jours. Le jour ou ils ont enfin découvert les langages de script, ils ont enfin compris qu'ils faisaient tout un tas de chose en C et qu'il était beaucoup plus pratique des les faires en script. Bref, le C n'est pas à mon sens le meilleur langage pour commencer, ni pour tout faire.

Y'a pas un conteneur dans la STL pour faire ce que tu fais et du coup, profiter des bénéfices de la pré-allocation par la STL ?

OK, je t'envoi ça ce WE... Je suis un peu en surcharge au boulot pour le retrouver de suite !

Dans le même genre, quelle est la différence avec Vala ?

Il y avait un bogue dans l'installateur, OK. Mais l'important est dans le reste du code, celui-la est lui-aussi soumis a des bogues critique ou non ?

PS : j'ai un patch qui rajoute un mot de passe d'acces au service. C'est un mot de passe que l'on partage mais qui évite que le serveur soit complètement ouvert sur le net. Cela vous intéresse ?

> Le défi dans Eclipse, c'est de désactiver les option qui nous intéressent pas, et découvrir
> les options qui nous intéressent.

Cela me rappelle les menus dynamique dans Windows et Office qui cache les trucs en fonction de l'historique. Ca m'a toujours particulièrement gonflé comme approche car évidement, l'ordinateur ne réfléchi par encore comme moi ;-)

Encore une fonctionnalité qui ne va pas me motiver à utiliser ce truc.

Pas dans mon labo... Presque tout le monde développe en Fortran et les rares qui font du C++, dès qu'ils commencent à devoir paralléliser fortement leur code serrent des dents !