Sytoka Modon a écrit 4556 commentaires

Oui, enfin, il y a des applications qui ne sont pas des monstres de propreté.

Juste un exemple : Nabucco. Ce logiciel sers à la gestion comptable dans les universités. On pourrait croire que c'est bien vérouillé d'un point de vue sécurité... Bon, je n'en dis pas plus mais cela laisse franchement à désirer. Par ailleurs, pour imprimer, il faut que le serveur ai accès à toutes les imprimantes, c'est le cauchemar des administrateurs de laboratoires qui sont obligés de mettre les imprimantes sur IP public et d'ouvrir les ports (enfin, pas sur le monde entier quand même).

Je crois qu'XLab au CNRS n'est pas mieux...

Si on souhaite se facher, on pourrait parler de l'annuaire agalan... Encore une fois, on ne va en dire plus sur un forum public.

Bref, il y a certainement des applications bien faites. Il y en a aussi un certain nombre qui ont couté des fortunes et qui, si on les diffusais, les services centraux auraient des gros problèmes dans le proche avenir.

Cependant, loin de moi l'idée de code fermé. Je suis pour le code libre dans l'administration, code qui serait payé une fois et non 85 ;-). Il faudrait donc ouvrir toutes les nouvelles applications dès les premières lignes et petit à petit les anciennes.

Les label sont /a priori/ portable sous PC, étant écrit dans la table des partitions.

Par contre, pour le matériel non PC, je ne sais pas. Cela peut être génant pour une distrubution multi-plateforme.

Personnellement, j'utilise les labels ou lvm pour les disques externes. Pour les disques internes, je ne les change pas tous les jours, je n'ai donc pas l'utilité de me compliquer ma fstab sur ce point.

Malgré ce que les témoignages de certains ici, l'UUID reste quand même imbuvable. Cela me rapelle la notation avec les lun...

Un coup de cfdisk, et tu sais en quelques secondes à quelle partition est associée ton label. Je ne fais personnellement pas super confiance aux commentaires dans un fichier fstab.

C'est évident. Merci la vente liée.

Ce qui est bien dans la fonction publique aujourd'hui, c'est que les PC sont vendus sans OS par défaut. Il faut cocher une case pour l'avoir. Ce serait mieux si on achetait la licence via le 'pool' logiciel et non avec la machine mais c'est déjà beaucoup mieux que dans plein d'endroit.

On ne peux plus voter !

Je ne sais pas combien de temps leur sondage reste en ligne. En tout cas, ils sont passés à u autre sondage ;-( Dommage, il n'y a pas eu beaucoup de votant en tout.

C'est l'amérique du nord qui est à 60Hz.

D'ailleurs, un point qu'on m'a signalé mais je ne sais s'il est toujours vrai. Il serait interdit de faire rentrer (et sortir) aux USA du courant alternatif.

Bilan : les lignes très haute tension venant du canada s'arrête juste avant la frontière, passe en courant continu la frontière et de là, reparte en courant alternatif à l'interieur du territoire des USA.

Je ne sais pas si c'est pour la même raison qu'entre la france et l'angleterre ?

En ce moment... Depuis combien de temps cela marche ? Et puis, SMTP n'est qu'un protocole, on peut en changer sans changer les fondements. Regardes, on est même en train de changer la couche basse en passant de IPv4 à IPv6 en douceur ;-)

Pour les pourriels, il n'y a pas que sur internet qu'il y a un problème. Ma boite physique est remplie de pub ! La aussi, il n'y a pas de bonne solution.

Par ailleurs, pas mal de gros spammeurs ont pignon sur rue...

Bref, ce que tu évoques a peu à voir avec les fondamentaux du net, même si effectivement, le SMTP a un statut spécial dans le DNS.

Si mes souvenirs sont bons, les 13 serveurs étaient pour le domaine .com uniquement. Le domaine .org ne tenait à cette époque là que sur 2 ou 3 serveurs.

Enfin, malgré ses défauts, internet globalement marche et est encore très ouvert sur le libre.

Lors d'un arrêt normal des transports en commun suite à une agression, j'ai deux copains qui ont fait du stop pour aller à la gare SNCF. Une voiture de flic les a pris et emmené la bas en moins de deux ! Cependant, manifestement, ils n'étaient pas pro Nicolas.

Bref, on peut ne pas être fanatique des flics mais je ne suis pas sur que cela soit gentil pour eux de leur coller Nicolas dessus ;-) Combien de flics (et de francais) aimerait se soustraire à ce pot de colle ?

Je sais que c'est fait exprès, mais du coup, ce n'est plus vraiment un langage pur objet.

C'est pas forcément un mal. Perl6 avec Parrot prennent aussi une direction intéressante. Ils ont choisis de ne pas faire du pur objet pour pas mal de raison et notament cela permet de faire du multi-dispatch.

Bref, j'essaye de me placer ici dans le contexte .Net (que je connais très mal) et non dans mon contexte personnel ;-)

perldoc WWW::Mechanize

En général, pour la date, si je veux être portable, j'utilise deux notations :

- YMD

- timestamp

On obtient le second avec date %+s

Je crois que un des problèmes des exemples, c'est que ce sont des trucs assez classiques et qu'il existe donc déjà sous UNIX des bonnes manières pour faire vite et propre en bash.

Là ou le shell windows va devenir intéressant, c'est quand on va rentrer dans des choses systèmes et mélanger un peu tout cela.

Dans les langages de scripts, on peut faire un peu pareil avec sous Windows les modules de type Win32 (Win32:: sous Perl). Mais il faut faire le "wrapper". On peut cependant imaginer qu'avec .Net et l'introspection, il soit possible, notament avec la force de frappe de Microsoft, de mettre au point un wrapper automatique, soit lors des mises a jour des logiciels, soit avec un mécanique du type AUTOLOAD pour Perl.

Bref, ca manque d'un langage de script...

Bon, très bien tout cela finalement.

Si je comprends bien, il ne devrait mettre que des slots 16x sur les cartes mères ;-)

Pour ce qui est des cartes graphiques, j'ai une nvidia sur port PCI, elle marche vraiment très bien pour ce que j'en fait (deux écrans). De temps en temps, je me demande combien d'utilisateurs (en entreprise) utilisent réellement le port AGP.

Vu le calcul que nous eu au niveau de la carte réseau gigabit, je vais finir par mettre la carte réseaux sur le port le plus rapide et la carte graphique sur le port le plus lent.

D'ailleur sur ce thème, comment on sais sur quel type de port sont les composants intégré comme le réseau ou la partie graphique (bas de gamme) ?

Il y a des outils pour administrer les clusters qui ont la particularité d'avoir des noeuds homogène dans de nombreux cas.

Sinon, pour un parc hétérogène, ssh ne suffit pas. ClusterSsh aide et permet d'administrer par exemple un vingtaine de machine en parallèle mais ce n'est pas suffisant.

Très vite se pose le problème de la gestion au quoditien...

Personnellement, j'utilise cfengine qui autoconfigure tous mes postes Linux et permet de gérer de manière souple et dans le temps des machines très différentes de manière centralisé.

Parce que tu te vois avoir des cartes de tous les formats !

Soyons raisonable. Tout cela coute cher et n'a que peu d'intérêt. Les PC ne vont pas avoir tous les slots dans le futur. Il va forcément y avoir un tri qui va se faire.

C'est un véritable problème au niveau acquisition. On ne change pas un PC d'acquisition tous les jours. Au niveau d'une manip expérimentale, la durée de vie de cette manip est bien plus longue que celle du PC. Et on ne change pas sa partie acquisition aussi facilement que cela.

Bref, un changement de bus, c'est un évênement important. Là, pour le moment, on est un peu dans le brouillard.

On m'a parlé par exemple de manip d'astrophysique ou les programmes de recherche sont très long et font intervenir de nombreuse équipes de recherche. Pour ce genre de manip, les choix sont fait très en avance et lorsque la manip tourne, ils peuvent être une génération en arrière.

Combien de manip tourne encore avec des cartes sur bus ISA ?

Effectivement, j'avais oublié cela.

Bon d'un point de vu syntaxe, c'est pas très beau. Peut être des redirection < et > particulière serait les bienvenues.

Je sais qu'on n'aime pas dire du mal de python sur ce site mais de la à perdre des points...

Sinon, je sais que .Net est ouvert sur les langages, cela n'empêche que Microsoft pousse particulièrement C# devant les autres.

Au niveau des langages de scripts qui existe, je persiste à penser que Ruby est plus proche de l'esprit .Net que Python (Ben oui, en Python, on se traine le self pour chaque méthode... C'est pas mieux en Perl).

Ensuite, Ruby est aussi basé sur une syntaxe à la C, bien plus que Python.

Bref, je ne critique pas le choix du shell de Microsft ici au niveau syntaxe. Mais à partir du moment ou ils ont fait un choix pour privilégier un langage compilé à typage fort (C#) et un langage shell, je dis simplement qu'ils auraient pu faire le choix pour un langage de script.

J'ai fait exprès de mettre Ruby pour ne pas tomber dans le troll Perl/Python.

Python, c'est bien mais comme Perl, c'est pas du pur objet.

Ruby est complètement objet dès le début, avec l'intropection et tout et tout. Bref, cela me parait clairement un meilleur choix pour l'architecture .Net. Et c'est pas parce que je suis fanat de Ruby, je ne l'a jamais vraiment utilisé...

Oui, enfin c'est un peu le bordel ce PCI-E. 1x, 4x, 8x, 16x ! C'est quoi ce bazard (en plus, il y a tous les autres PCI...).

Je veux faire de l'acquisition, j'achète quoi comme carte ?

Je crois qu'il faut que cela décante un peu et qu'il reste éventuellement que deux slots : un rapide et un lent. Là, avec la multiplication des types de slots, ca fait plutôt peur.

Pourquoi n'avoir pas choisi les deux seuls format : PCI-E 16x et 4x

Moi, le PCI-E 1x, je ne l'aime pas. Ce petit machin, j'ai du mal à croire que ma carte va tenir correctement dedans. En plus, avec tous les périphériques en USB2 ou en IEEE1394b (voire ethernet), c'est quoi qu'on va mettre sur ce genre de slot ?

C'est clair que le shell UNIX est au coeur du système et que de très grande partie sont scripté en shell.

Un des problèmes est que Windows ne démarre pas en mode terminal même si j'ai cru voir qu'une version de Vista le pourra. Le problème suivant est je n'ai pas connaissance qu'une seule partie de l'OS soit pour le moment en script. Il y a donc encore du boulot pour avoir un système souple et adaptable facilement.

Sur un UNIX, toute la connaissance que l'on apprend dans le terminal peut ensuite être réutiliser au coeur du système. C'est très positif.

Ce nouveau shell windows, c'est bien mais n'aurait-il pas été plus intéressant pour Microsoft d'intégrer un langage de script existant (et non de shell) à .Net, un langage dont le coeur est objet, je pense à Ruby par exemple, pour ensuite reprogrammer un partie de Windows en script justement.

Personnellement, je bannis awk...

En effet, dès que je commence à avoir de l'awk avec du sed... je considère que Perl est plus adapté et plus maintenable (et non, je programme pas comme un gorais en Perl et oui, on peut faire du Perl lisible).

C'est un peu l'approche de debian

- simple, couche base du système -> bash

- compliqué -> Perl

Il ai vrai que l'on voit aussi de plus en plus de python...

L'objectif d'un shell est aussi d'être interactif, de la à faire des gros programmes... Enfin, si le shell windows remplace à la fois command.exe et le vbs système, je crois que personne ne va pleurer. Sauf que malheureusement, il n'y a pas un portage minimal sur les anciens OS !

Je suis d'accord avec toi.

Le principe de base du shell est d'être unifié avec l'approche fichier d'UNIX.

Donc, on doit tout pouvoir rediriger dans un fichier puis traiter ce fichier plus tard ou balancer dans un pipe. Bref, il n'y a pas de différence entre pipe et fichier.

La, si le pipe n'est pas un "fichier", cela change tout.

C'est vrai qu'on a tendance à balancer dans un fichier en remplacement d'un stockage dans une variable. Mais quand même...

Bref, ce nouveau shell, faut le voir à l'usage.

Si le D-BUS principal tombe et que tous les autres tombent alors, cela perds pas mal de son intérêt ! Cela veut dire que l'on ne peut pas relancer le D-BUS sytème sans perturber les autres violament.

Au niveau fam et gamin, en pratique, cela est remplacé par inotify directement par le noyau. Par contre, on doit pouvoir utiliser D-BUS pour la transmission finale ?

Quand à la fin, que gconf utilise dans le futur D-BUS pour transmette ses informations, pourquoi pas. Mais cela n'a effectivement rien à voir. Un des objectifs de gconf est quand même de centraliser les paramètres de configurations des applications. Après, gconf fait plus que cela mais justement, je fait partie des personnes qui trouve qu'il en fait bien trop ;-) Si D-BUS lui enlève une partie du boulot, tant mieux.

A mon avis, upstart s'adpatera à D-BUS ou mourra ;-)

Personne n'a encore évoqué cette thématique ici donc je donne le coup d'envoi ;-)

Sun a fait très attention à ne pas mettre Solaris sous licence GPL à l'époque mais sous une autre licence, incompatible...

En mettant Java en GPL, ils se coupent un peu l'herbe sous le pied pour renforcer l'intégration de Java dans Solaris ?

Au dela de cela, est-ce une remise en cause à moyen terme de la licence Solaris pour finalement validé la démarche de la FSF au travers de la GPL ?

Je n'en ai pas fait beaucoup mais c'est vrai que cela m'a pris en général ma soirée.

D'un autre coté, je ne la trouve pas si mal cette dépêche.

Un point important à mon sens avec D-BUS est que normalement, cela ne tourne pas en root. Chacun a le sien. Je ne sais pas par contre comment les D-BUS communiquent entre eux ? (Le D-BUS utilisateur est-il client du D-BUS système) Cela est un plus par exemple avec le service 'fam' de notification de mofication de fichier qui devait absolument tourner en root, avec les problèmes que l'on connait pour les périphériques amovibles (il faut voir les astuces qui ont été réalisés sur ce point là à une époque pas si lointaines).

Un autre point important est que D-BUS est un bus de messages et de signaux. Cela n'a donc rien à voir avec un système de variable globale de type base de registre ou gconf. Cela me fait plus penser au système de message à la base d'OpenStep. Or tout le monde sait qu'OpenStep (donc GnuStep) qui fonctionne par message avec un langage objet dynamique (ObjectiveC) a montré depuis des années une souplesse de fonctionnement et d'adaptation aux problèmes avec une API d'une incroyable stabilité.