Sytoka Modon a écrit 4546 commentaires

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 !

Il faut 24 000 000 de ligne de code pour faire un IDE qui va me permettre de coder en Java... et bien, ca fait pas envie d'aller vers ce langage ;-)

Je suis d'accord avec toi. Si un langage est bien parce que il s'écrit en gros dans la "norme" donné par le C et que les algo sont de type impératif avec toujours les mêmes fonctions, on peut se poser la question d'avoir plusieurs langages...

Je ne comprends pas bien ni le Lisp, ni l'Haskell, ni le OCaml... et pourtant, j'en ai regardé des exemples. C'est pas pour cela que c'est de la daube. J'adore le langage du Makefile et pourtant, plein de gens déteste.

Bref, il faut de tout et surtout il faut essayer des nouveaux paradigmes car on a devant nous un mur à franchir qui est la parallélisation facile des codes. Sur ce chemin là, Erlang apporte à mon sens beaucoup. Comme en Erlang, les variables sont immutables, on peux oublier tout son java et toutes ses classes qui ne fonctionnent souvent que par effet de bord !

L'archarnement anti-Perl sur linuxfr est fatiguant. Moi je ne pipe rien a un programme Python et je ne la ramène pas tous les quatre matins la dessus.

Même avec un réseau gigabit, lorsqu'il faut rapatrier plusieurs téra, on arrive au limite de la connexion Renater...

Sinon, je n'ai pas parlé des clusters non utilisés la nuit. Dans ce cas la, les schedulers règles la question et marchent globalement bien. En pratique, je parlais des vacances d'été. Lorsque l'université t'impose plusieurs semaines de vacances l'été avec interdiction de rentrer dans des locaux fermé à clefs (et dont tu n'as pas la clef), il n'est alors pas raisonable de faire tourner tous ces kilowatt/heure sans controle humain.

Le point faible des salles serveurs autour de moi sont les clim... Je ne suis pas super inquiet pour les machines elles-même, ce sont les baies de stockage disques qui m'inquière en cas de monter de la température sur plusieurs jours !

En Perl, j'écris

point = Point::new(1.2, -3.7);

On est ainsi sur d'utiliser la méthode new de la classe et non la fonction new. Et puis, c'est plus homogène avec tous les appels de méthode dans Perl.

Justement, on a de plus en plus besoin de faire du post-traitement de données 3D et la problèmatique de ou sont les données posent alors un soucis. Il y a des solutions comme VirtualGL qui arrivent petit à petit mais c'est pas encore ca.