Sytoka Modon a écrit 4538 commentaires

> ça ne passe pas le NAT

Le problème est que c'est le NAT qui est mauvais pas FTP.

Le NAT n'apporte aucune sécurité, que des emmerdements. Le réseau internet a été conçu pour faire du point à point entre tous les membres du réseau.

Le NAT ne fait que retarder IPv6. Sans NAT, on aurait déjà IPv6.

Le FTP est un protocole en clair. Certe, le fait d'utiliser un double port est merdique (d'un point de vu d'aujourd'hui) mais n'importe quel firewall aujourd'hui sais suivre un connexion FTP.

Bref, je te trouve trop sévère vis à vis du FTP qui a rempli et qui remplit encore une tâche utile.

Par contre, je ne comprends pas comment on peut faire les protocoles suivants qui sont bien moins anciens et qui sont 100 fois plus merdique que le FTP :

- H323, ok c'est pas tout jeune et ca dérive des téléphonistes mais bonjours les ports. Va trouver un firewall qui filtre correctement une multi-session sur un pont + gatekeepers sur H323. Il n'y en a pas tant que cela qui marche vraiment.

- SIP, le concurrent du H323 qui vient des informaticiens. Une daube inconcevable de la part d'informaticien. C'est pas croyable que des gars ai pu pondre un truc pareil.

Bref, il y a de vieux protocole qui ont été conçu pour un internet sans NAT (et il ne devrait pas y avoir de NAT) qui ne sont pas si compliqué que cela et il y a des protocoles jeunes qui sont nés avec le NAT et qui n'aurait pas du voir le jour...

Laissons le FTP mourrir tranquillement comme gopher. Respect le FTP.

En fait, ce qu'il dis n'est pas faux mais pas complètement juste !

Il y a une fréquence dangeureuse qui est celle des micro-ondes car elles excitent les molécules d'eau. Il est assez facile de faire bouilir de l'eau avec donc cela peut tuer toute vie...

Ensuite, lorsqu'on monte en fréquence, cela redevient moins dangereux. Par exemple, les laser de CD sont dans l'infra ouge et ne sont pas hyper dangeureux.

Enfin, arpès le domaine du visible, on rentre dans le vrai domaine dangeureux mais on sors des applications électroniques de type réseau : ultraviolet, rayons X, rayons gamma...

/A priori/, le CPL utilise des fréquences bien plus faible que les micro ondes. Cela se rapproche des ondes radio. La puissance semble très faible. Je ne comprends pas pourquoi tout ce stress autour du CPL, cela me parait surdimensionnés. Il y a bien d'autres technologies qui me semble bien plus dangeureuse et qui mérite toute notre énergie : à commencer par les portables et tous ses appareils wiki !

Enfin, à moins de phénomène particulier, je ne vois pas comment un signal de faible puissance et de grande longueur d'onde va se transformer en signal de forte fréquence ! On a des phénomènes d'accélération de fréquence dans la nature mais c'est assez rare me semble-t-il. Je pense notament au fréquence sismique dans des zones sédimentaires entourés de montagne qui peuvent être bien plus élévé dans la cuvette. Un petit clin d'oeil aux grenoblois du site dont la ville est le site français le plus connu pour cela.

> Pourquoi ne pas aller jusqu'au bout de la démarche, en rédigeant la
> doc de ton outil dans cette langue ?

Peut être que tout simplement il ne le parle pas !

Tous mes programmes ont des noms bretons, plutôt en vannetais d'ailleurs mais malheureusement, je ne le parle pas. Peut être un jour...

On peut aimer une langue et ne pas la parler.

Non seulement ils sont torsadés mais pour ils sont blindés. Je pense qu'il ne sors pas gand chose d'un cable catégorie 6.

Surtout que l'important, à mon sens est tant la puissance que la fréquence. Le wifi et les portables posent problème car les fréquences sont proche du four à micro-onde donc excite les particules d'eau. Or le corps humain est surtout constitué d'eau...

Pour le CPL, je ne sais pas exactement qu'elle sont les fréquences ni les puissances de rayonnement (car ce qui est dans le fils de cuivre, on s'en fiche un peu).

> Mais bon c'est une preuve de plus que le passage des postes client
> a linux n'est pas impossible et ne fait pas perdre en
> fonction/productivité

Parce q'un député est productif !

-> []

Y-a-t-il un espoir de voir apparaître un support pour les tablatures d'accoréon diatonique ?

Merci.

A noter que GRR est dérivé de MRBS et était plus avancé question développement.

Ceci dis, j'ai l'impression que MRBS est repartis depuis quelques temps donc je ne sais pas qui a les fonctionalités les plus avancés a ce jour.

Nous on utilises GRR

http://grr.mutualibre.org/

C'est simple et cela convient à nos besoins modérés.

> ... demandant un entretien régulier, des changements de pièces ...

J'ai résumé ton raisonnement. Je le croyais bon il y a quelques années mais je le pense faux aujourd'hui.

La vidange est passé en une dizaine d'année de 7500km a tous les 20000km voire plus !

Les voitures sont de plus en plus fiables pour la partie mécanique. Si tu ne prends pas un monstre d'électronique mais une voiture simple et pas chère, elle est bien plus fiable qu'il y a 20 ans.

Ayant des onduleurs au bureau de grosses capacités, je ne suis pas capable de dire ce qu'il y a de plus fiable entre entre un moteur à explosion et une quantité non négligeable de batterie surchauffant sous un capot.

Bref, la fiabilité ne me semble pas le noeud du problème que tu soulèves aujourd'hui.

Attention, la relativité générale ne doit pas être prise au même titre que les principes de la thermodynamique. Les principes de la thermo sont très généraux, coule du bon sens cartésien (même si le second est moins facile).

La relativité générale a un problème intrinsèque, il y a trop d'équation, il manque une équation. Einstein a donc posé une normalisation pour s'en sortir. Cette normalisation sors du chapeau ! Mais enfin, cela marche pas mal. Il y a quelques chercheurs qui explorent des voies annexes qui donnent des résultats pas si mal, c'est à dire que l'on retrouve à peu près la même chose... La difficulté est d'avoir des mesures très précises et du temps pour mettre au net tout cela.

Mais l'énergie des physiciens est toute prise dans leur thérorie des cordes d'après ce que j'ai cru comprendre. C'est peut être un peu dommage.

Travaillant dans les sciences (public) depuis longtemps, il est vrai qu'il y a des voies qui sont mal explorées et cela ne va pas s'arranger. Avec les gands programmes, le pilotage politique, la pression financière sur les laboratoires de recherche, la course à la publi (la plus nulle)... La recherche publique aime de moins en moins les originaux, à moins qu'ils ne soient exceptionnellement bon et que le système ne les aient pas "cassé" avant.

Il est clair que svn a une excelente intégration dans Windows (Tortoise) ce qui fait que des non informaticiens utilisent le produit avec très peu de formation.

C'est un des soucis aujourd'hui, subversion est bon moyennant ce problème de merge de branche et les autres sont bon aussi moyennant l'aspect multi-plateforme et facilité pour l'utilisateur lambda.

Un de mes objectifs est de fédérer le développement pour des utilisateurs lambda dont une bonne partie est sous Windows, projets qui ont un développeur principal. Donc je suis parti sur quelque chose de simple qui apporte une réelle plus value rapidement : trac + svn.

Il est clair que quelques utilisateurs avancés (dont moi !) arrivent rapidement aux limites de cet environnnement. Mais globalement, j'aurais mis un git en place que seuls ces quelques utilisateurs l'auraient utilisé, et je ne serais pas plus avancé aujourd'hui.

Ton jpackage m'a l'air surtout orienté RPM vu le peu que j'ai de ton lien. Sur ce crémeau, il y a les deux poids lourds, Red-hat et Novell et je doute qu'il mette en commun leur paquetage de base...

Ensuite, toutes les debian (et dérivée) me semble éliminées...

Bref, je ne crois pas trop à jpackage en fin de compte. Le plus dur dans la construction de paquet, c'est de bien définir les dépendances avec les nuémros de version de ces dépendances. Cela prends un temps fou de faire un truc propre et homogène sur une disribution comme debian. Je ne vois pas comment tu veux mutualiser cela dans un format jpackage, mais peut être n'ai je rien compris.

Si en fin de compte, jpackage est un tarball plus évolué, cela me semble de peu d'intérêt aussi. De plus en plus, on va avoir des gestionnaires de versions de type GIT qui vont faire la liaison entre l'équipe de développement du code et la partie adaptée pour la distribution. Avec ces outils de versionning, tout le monde va y gagner en boucle de retroaction.

Donc jpackage la dedans ... Non vraiment je ne vois pas bien.

As tu regarder du coté de Perl ? Faisant pas mal de Perl, je ne suis pas objectif mais il me semble que la bibliothèque Perl, via le CPAN est immense et que dans le nom même de Perl, il y a déjà ta problèmatique de bot IRC de traiter. Bref, Perl me semble parfaitement adapté à ton exemple. J'irais par exemple voir comme cela du coté de POE.

Si les serveurs de fichiers sont des samba, dans mon cas, je fait du NFS avec montage via AutoFS. Soit des tables statiques, soit des tables dynamiques qui peuvent s'adapter à la personne. AutoFS et NFS marchent très bien ensemble.

> j'ai pensé a partagé mon repertoire CA par nfs mais c'est un peu
> ''lai''.

Je ne vois pas l'intérêt de faire des certificats avec ssh si tu enchaines sur NFS ensuite !

Pourquoi prendre ssh dans ton cas et non kerberos ?

Pour propager ta configuration de serveur en serveur de manière sécurisé et sans stress, le mieux est de se mettre à cfengine, il va faire tout cela automatiquement et de manière très sécurisé ;-)

Avec pam_mout ou pam_script, tu peux monter des partages en début de session. Donc cela me semble personnellement suffisant. Normalement, l'utilsateur n'a pas a monter lui même un partage.

Dans le même genre, pour virer MSM, outlook... Il faut dé-installer les logiciels mais aussi les composants ! Evidement, on ne pense jamais à virer les composants...

J'ai utilisé pendant des années un pentium pro 200 sous linux et c'était merveilleux... Puis les PII sont arrivés ... puis un beau jour, le pentium pro n'avancait plus ! Alors qu'au début, il foudroyait les stations Indy de SGI sous LaTeX !

Qu'est ce qui avait changé, on avait maintenant GNOME (avec sawfish) ou Enlightement... Bref des usines à gaz comparé au bon vieux FVWM version 1 qui marchait super bien. L'affichage, c'était pas en 24 bits couleurs, mais pour les meilheures machines en 32000 couleurs et cela allait bien, on faisait son site web avec un palette finit de couleur, idem, les bureaux n'utilisait qu'un nombre réduit de couleur (comme les logos des entreprises par ailleurs).

Les applications d'aujourd'hui ont des dégradés de couleurs partout, la GLIB est peut-être super bien pour les applications d'aujourd'hui mais un xfig et un xv étaient (sont toujours) fonctionnel en étant 'moche' selon les standards de nos jours.

Bref, perso j'utilise wmii car je retrouve avec lui un bureau simple et pratique sans colorant de partout, mais il y a beaucoup d'application inévitable, et gecko lorsqu'il tombe sur du flash est terrible, quelque soit la machine !

Sur une ancienne amchine, il faut virer tout le superflu, avahi .... Bref, tous les machins qui ne servent à rien. Faire un noyau sur mesure et sans initrd (il n'y en avait pas à l'époque). Bref, c'est du bout ;-)

C'est très bien tout cela, je vais forwarder à mes spécialistes de l'acquisition. Je ne pensais pas que c'était aussi avancé. Merci.

Labview est très lié à National Instrument et à ses cartes d'acquisition. Donc dès que l'on aborde ce thème, on pense de suite aux drivers de ces dites cartes...

Autant je pense que pas mal de programme Matlab pourrait être écrit sous Scilab, autant j'ai des doutes de virer Labview de mon laboratoire avant des années !

> J'imagine que ce n'est pas la réponse que tu espérais

En fait, je n'esperais pas grand chose si ce n'est de faire avancer le débat et essayer qu'un grand nombre de personne comprenne vraiment le sujet (dont moi). J'ai donc pris un exemple classique dans un laboratoire de recherche, pas si anodin que cela car il y a une grande histoire Fortran et pouvoir passer par exemple du Fortran à l'Ada serait dans certain cas intéressant.

Ta réponse finalement ne m'éclairicie malheureusement pas les idées. Tout cela me donne l'impression d'un truc énorme qui nécessite des projets énormes avec des moyens humains énormes...

J'ai regardé mais je dois dire que ce n'est pas du tout dans les domaines que j'utilise et donc les 3/4 ne me parlent pas plus que cela.

Dommage.

Prenons un exemple concret de laboratoire, j'ai un code Fortran 95, c'est capable de me le transformer en C++ ou en Ada 95 ou pour le moment, il n'y a que le Java qui marche ?

Ca va le nombril ;-)