Sytoka Modon a écrit 4586 commentaires

> 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 ;-)

> Certains (cf. par ex. Sytoka Modon plus haut) semblent avoir mal
> compris pourquoi cette fonction peut utiliser de la mémoire non
> initialisée.

Désolé mais je n'ai pas du tout dis cela. J'ai dis que je n'y connaissais rien au fonctionnement interne. Moi ce qui me surprends en lisant les commentaires, c'est que ca a l'air vachement compliqué d'utilisé la bibliothèque OpenSSL puiqu'on retrouve cet appel a MD_Update() plusieurs fois dans le code. Si on veut du code sur, j'ai l'impression que le mieux est d'avoir une API simple ?

Comme tout le monde va de sa proposition et tu en fait des bonnes, j'y suis allé de la mienne sur un thème peu évoqué ici du contrôle par cas test /a posteriori/.

Le contrôle par cas test est à la charge du concepteur de l'application et permet de s'assurer, en plus des autres contrôles, une certaine stabilité de l'application, et cela de manière relativement automatique.

> es brute-force n'ont des chances de réussir que si on connait déjà
> une faille...

Ou si l'algorithme n'est pas bon...

Comment vérifie-tu ton algo si tu n'as pas de cas test ?

De plus en plus, on met de l'aléa dans le coeur des systèmes pour ne pas faire des choses prévisibles qui se révèlent dangeureuses en cas de bogue (inévitable) : adresse ELF variable dans le noyau lors du chargement de bibliothèque, séquence IP aléatoire, numéro de PID aléatoire...

Mais du coup, avec ces aléas, cela devient très difficiles pour un humain de voir s'il y a un problème à ce niveau la. C'est normal, cela a été fait pour !

Donc il faut bien vérifier la qualité de ces aléas via des mesures statistiques ET automatiques.

Les brutes forces ont aussi des chances de réussir si on n'est pas capable de certifier la qualité de son aléa.