Sytoka Modon a écrit 4544 commentaires

Super, je ne connaissais pas. Merci.

la virtualisation et les schroot, je connais mais il faut être honnête, pour gérer le multi version de bibliothèque et de programme, c'est pas aussi souple et léger que modules et le réglage de variable d'environnement

Les personnes faisant du Java ont elles jamais eu les pieds sur terre ?

Je vois beaucoup de variable globale dans les codes de calcul ;-) Ensuite, je me suis aussi amusé a en rajouter une couche !

Une base de registre (dconf) revient à faire une modif par une programme et de la répercuter instantanément dans tous les autres. J'appelle cela une variable globale mais a un niveau encore au dessus. Donc encore plus à limiter car dangereux !

dbus est à la fois bien et à la fois casse pied… Va faire marcher deux dbus en // avec deux versions. Essaye de lancer un programme qui va utiliser le bon dbus parmi les deux… Je ne sais pas faire.

Avec modules et en jouant sur les variables d'environnement historiques, il n'y a aucun soucis pour utiliser plusieurs versions de programme en parallèle et de les tester.

PS : les variables d'environnements ne sont pas des variables globales car elle transite de père en fils (si elles sont exportés) mais non l'inverse.

Quand on développe, on utilise les dernières versions des bibliothèques car c'est celles là qui seront supportée le plus longtemps.

Pourquoi ces généralités balancés comme des vérités…

Dans mon laboratoire, on fait du calcul haute performance (principalement en Fortran). On doit tourner en local mais aussi sur les centres régionaux ou nationaux. Bref, tu n'as jamais la même configuration partout. Ton code doit être portable, la dernière version n'est pas toujours la meilleure, ni la plus pérenne !

Dans tous les centres, on doit gérer la diversité des versions. Cela veut dire plusieurs versions de python, de mpi, de compilateur, de… Cela se gère très bien avec "modules" qui modifie à la volée des variables d'environnements. Évidement, ça gère très mal la programmation par variable globale (type base de registre) qu'on voit de plus en plus (type dbus) pour tout et n'importe quoi dans les interfaces graphiques.

Bref, tout cela pour dire que le développement est quelque chose de très large qui englobe PLEIN de domaine.

Ce n'est pas avec une Debian et des versions de retards qu'on permet la corrections de bogues des projets dans leurs
dernières versions.

Encore une fois, l'aspect multi-arch de Debian remonte des bogues… Il faut aussi arrêter de croire que tous les vieux bogues n'existent plus dans les dernières versions des logiciels ;-)

Si Arch l'avait pas fait, tout le monde aurait utilisé python2 à vie et python3 serait mort.

Bravo, grâce à toi et à Arch, Python n'est pas mort ;-)

Tu as des chiffres pour dire qu'il y a tant de personne que ça sous Sid?

Pas facile d'avoir une vue d'ensemble. Il faudrait les stat google. voila un début http://popcon.debian.org/index.html

Statistics per popularity-contest releases:

1.26                      : 2          
1.28 (sarge)              : 83         
1.30                      : 1          
1.31                      : 6          
1.32                      : 4          
1.33                      : 19         
1.34                      : 5          
1.36                      : 5          
1.38                      : 5          
1.39                      : 23         
1.40                      : 14         
1.41 (etch)               : 2791       
1.42                      : 83         
1.43                      : 5          
1.44                      : 7          
1.45                      : 90         
1.46 (lenny)              : 10061      
1.47                      : 33         
1.48                      : 397        
1.49 (squeeze)            : 46688      
1.49.2.201104140421       : 4          
1.49em1                   : 1          
1.50                      : 9          
1.51                      : 73         
1.52                      : 90         
1.53                      : 724        
1.53ubuntu1               : 2          
1.54                      : 53         
1.55                      : 902        
1.56 (wheezy/stable)      : 80300      
1.57                      : 630        
1.58                      : 866        
1.59                      : 1183       
1.60 (testing/unstable)   : 14554      
1.60em1                   : 1          
unknown                   : 437        

Sachant que les gens sous sid mettent plus facilement le paquet popularity-contest… et que la stable est bien plus utilisé que les 80000 affiché…

Bref, des stats quoi ;-)

Ta vision de Debian est faussée. Debian est la seule distribution réellement multiplateforme depuis des années. Si le passage vers ARM des autres distributions a lieu en ce moment, qui a fait un boulot depuis 10 ans pour que l'ensemble soit a peu près cohérent ?

Debian n'a pas pour objectif de faire du développement amont. Elle est ainsi depuis le début et elle n'a jamais empêché le développement de code…

Pour faire du code, à chaque fois qu'on ajoute la moindre fonctionnalité, on ajoute aussi des nouveaux bogues. Il ne s'agit de faire le procès de tel ou tel. C'est ainsi, c'est humain. Avoir la certitude que ce que tu installes aux thésards fonctionne un certain temps est aussi une bonne chose lorsque tu gères un parc conséquent. C'est pas pour rien que Windows XP est très aimé en entreprise.

Cela fait des années qu'il y a testing dans Debian ainsi que Sid. Ceux qui veulent du mouvement continu, c'est aussi possible. Ensuite, il y a une myriade de distribution autour comme Mint qui font aussi du bon boulot.

Je dis pas qu'il faut pas faire un peu de testing pour vérifier que tout marche bien

Comment tu fais cela sur une architecture comme le PC, avec du multiplateforme ?

Debian change petit à petit en faisant des mises à jour noyau AYANT des éléments nouveaux. Il y a une phase de test ouverte avec les "proposed-update" et s'il n'y a pas de retour négatif, c'est poussé vers stable au bout d'un mois il me semble. Ainsi, contrairement a ce que tu dis, on profite tout de même de driver bien plus récent dans certain cas (je me souviens très bien des mises à jour du driver e1000e d'intel par exemple).

apt-get est bien plus rapide que aptitude, ne pas mélanger les deux.

Pas vrai pour les stations SGI… On les trouvait pour faire de la CAO car la 3D marchait dessus et rarement ailleurs aussi bien. Pas pour rien qu'OpenGL soit la suite de GL, le tout fait par SGI.

A l'époque, tous les logiciels de CAO et de calcul été développé et tournait sous SGI, sauf Catia qui l'était sous l'UNIX d'IBM… Malheureusement, ils ont été portés sous Windows et non sous Linux. On le les trouve pas sous Linux ou alors avec des portages plus que foireux (regarder le nombre de binaire PE32 dans une installation Ansys par exemple !).

Super, faut que je regarde cela de plus près la prochaine fois. Merci.

Alors pourquoi ne pas utiliser Gentoo ou Arch qui sont du coup, bien plus "stables" et testées que Debian sid?

Tu as des chiffres car il y a un paquet de gens sous Sid…

Perl est d'une incroyable stabilité avec les vieux codes et tu as trouvé tout seul la solution minimale. Enfin, une petite mise à jour du script ne ferait pas de mal parce que au bout d'un moment, les manières d'écrire ont bien changé…

    foreach my $res (@query_results) {
       next if not $res;
       my ($val1, $val2) = split /,,/, $res;
       if ($val1 eq 'Q4S') {
          # Server Info
          $temp_server_address = $val2;

Mettre d'autres nom que res et val comme nom mais avec aussi peu d'information, j'ai pas trouvé mieux ;-)

A mon sens, c'est assez différent. Le Xeon Phi concurrence le calcul sur GPU (nvidia TESLA ou autre carte de gamer). On a ici un aspect matériel.

La carte fait tourner son propre OS, un linux minimaliste. Dans ton code, tu rajoutes des options de même type que l'OpenMP qui simplifie la gestion des transferts et des échanges entre le CPU et la carte (problématique typique du calcul sur GPU).

Le HIC pour le moment est que cela ne marche qu'avec le compilateur Intel, qui est cher même pour les universitaires, surtout que la version de base ne suffit pas (et qu'on a pas non plus réussi à compiler en statique)…

Si le Xeon PHI marche, je ne vois pas ce qui empêche de faire à terme une implémentation libre.

Pour concurrencer nvidia, Intel a sortis le Xeon PHI qui fonctionne un peu comme une carte Tesla. Avantage, cela fonctionne un peu comme OpenMP via des directives dans le code, il n'y a pas de méta langage comme Cuda. Sur le papier, c'est bien plus simple…

A terme, il est fort possible que du code OpenMP et MPI, voire OpenCL, puisse profiter de manière semi transparente du Xeon PHI.

Je pensais au webm parce qu'il me semblait soutenu par google tout en étant ouvert,

Pour la pérennité, comme dis plus haut, il faut un format bien définit et surtout très utilisé. Les brevets logiciels ne sont pas valide chez nous et vont tomber un jour ou l'autre donc le choix est évident H264. Le H265 est en cours de mise sur orbite et il n'y a rien qui va lui faire de l'ombre à cours terme (d'ici trois ans). Ensuite… on verra.

Ne pas l'oublier celui-là. Moi j'avais noté l'ajout des espaces de nom en mode utilisateur. Bref, XFS continue et est loin de ne plus être utile…

http://www.phoronix.com/scan.php?page=news_item&px=MTQ1Nzc

"
The theme of the XFS changes for the Linux 3.12 merge window include allowing for more shared code between the libxfs user-space XFS library and the Linux kernel XFS module, performance optimizations, and other small work.

Some of the items worth pointing out include readahead to log recovery, support for project and group quotas to work simultaneously, performance optimizations for CIL, directory entry file type support, user name-space support, and other small fixes and improvements.
"

Pour le long terme, il vaut mieux du H264 que du VP8. D'abord, en Europe, les deux sont libres (pas de brevet) et les brevets ne dure que 20 ans donc pour le H264, il doit en rester 10 tout au plus.

Les télé et l'IANA enregistre en H264, le format est très très utilisé et se lira encore dans 20 ans.

Le VP8 est normalisé via une implémentation à mes souvenirs, il n'y en a pas 50… Bref, pas sur qu'en cas de changement d'architecture CPU, le bousin marche encore.

Bref, pour l'archivage, H264 sans hésiter entre les deux.

Pas FTP ! FTP n'a rien a voir avec SSH…

SFTP, c'est du SSH avec les commandes FTP/ Bref, presque du sucre syntaxique autour de scp…

L'évolution sécurisé du FTP est le FTPS qui comme le HTTP consiste, en simplifiant, a enrober le FTP dans une chaussette SSL. Il pose bien moins de soucis que le FTP car il n'utilise qu'un seul port.

rien que le volume revendu par un revendeur va faire qu'il n'aura pas les memes prix à la source

Le problème est là, CISCO choisi son pousse carton pour le marché A et lui fait un prix sur ce marché. Sur un autre, il choisit un autre pousse carton et ainsi de suite. En vérité, une grande partie des pousses carton se vaut sur le sujet sinon pourquoi celui-ci sur Orsay, celui-là à Rennes…

Au final, tu n'as aucun choix car CISCO impose celui qu'il a choisit selon ses propres critères bien évidement non public.

Ce système, plusieurs fournisseurs me l'ont confirmé à l'oral par téléphone en les travaillant un peu. Évidement, je n'ai aucune preuve écrite !

Il y a aussi le FTPS. Par rapport au SSH, il ne fais que cela…

Et en plus, dans les marchés public, ils contournent la loi en décidant qui aura tel ou tel marché… En effet, ils décident de manière complètement opaque le fournisseur qui sur le marché X ou Y aura un prix moins chère que les autres et à ma connaissance, il y en a toujours qu'un !

Je parlais de la doc intégrée dans le code source Perl. C'est pas du POD, il y a (de tête) des @class, @apmethod et autre…

A noter que c'est programmé en Perl et, au vu des quelques fichiers que j'ai parcouru, cela me semble du Perl propre et particulièrement lisible.

Question, vous utilisez quelle moulinette pour générer la doc car il me semble clair que les commentaires sont loin d'être idiot et in-structuré ;-)

Il faut rappeler quand même que l'Europe (UE) n'est pas concerné car les brevet logiciels ne sont pas valides sur ce territoire. Les distributions et les grandes fondations feraient bien d'avoir des dépôts physiquement en Europe afin de leur simplifier la vie ;-)

Vive le vieux continent !