Sytoka Modon a écrit 4551 commentaires

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.

C'est une question de statistique. Il y a bien un moyen d'écrire une mesure et de regarder l'aléa, l'équi-répartition, l'écart type... Donc cela va bien plus loin que de regarder si deux clefs sont identiques.

Enfin, tout cela existe déjà pour mesurer la qualité d'un générateur de nombre aléatoire.

J'ai pas l'impression de demander la lune en me posant la question de la qualité de l'aléa /a posteriori/ dans ce genre de programme. Je serais même très surpris qu'il n'y en ai pas déjà ?

Comment veut-tu que les développeurs améliorent la qualité des algorithmes s'ils n'ont pas les moyens de faire de mesures ? Ou alors, ils se basent sur des algorithmes publiés par des scientifiques mais ne vérifient pas par eux-mêmes de l'implémentation ?

> J'adore Debian, mais il me faut un peu plus qu'"un désolé on a
> merdé", j'espère une sérieuse reflexion sur

J'aimerais savoir combien de développeur d'OpenSSH utilisent debian comme poste de travail ?

S'ils sont plusieurs, eux non plus n'auraient pas regarder leur propre code ni vu l'erreur...

Sinon, y a pas moyen de faire un md5sum des clefs et de regarder la répartition de ces clefs dans un espace pour voir la bonne équi-répartition ? Certes, debian a merdé, mais comme beaucoup le disent, OpenSSL et OpenSSH n'ont pas de programme de vérification /a posteriori/ ?

Lorsque je programmais plus, on considérait que le code était valide s'il passait tous les cas tests. Si un codeur n'était pas content parce qu'on lui cassait une fonctionalité, on le renvoyait à l'écriture d'un cas test ;-)

Avoir des patch signé, reviewé, co-signé... C'est bien mais tout cela reste bien humain et parfois cela n'empêche de faire des grosses conneries. Il suffit de voir le nombre de personnes travaillant par exemple autour des ministres et d'entendre parfoit les grosses bourdes qu'ils font... (autre exemple, l'hélice du Charles de Gaule)

Mesurer l'aléa sur des programmes de crytographie me semble faisable et une distribution pourrait lancer le test avant de sortir une version stable de sa distribution. Un peu comme les tests ACID et autres pour les navigateurs.

Bref, pour prendre exprès le contrepied de certaines opinions qui se sont exprimés ici, développer un programme comme openssl ou openssh sans avoir un environnement permettant de valider de manière automatique (ou semi auto) la solidité de l'implémentation me semble peu cohérent.

Je précise pour finir que je ne sais pas du tout comment sont développé openssl et openssh en pratique.

La V3 sera peut être aussi morte dans 3 ans... Tout dépend de la numérotation choisie et certains vont plus vite que d'autres...

Enfin, avec un raisonnement pareil, je ne vois pas comment ubuntu va faire un support pendant 5 ans.

Donc cela veut dire que les paquets dans ubuntu changent au cours du temps, qu'il n'y a pas comme dans une debian, que des corrections de bogues ?

Ou peut être, est-ce une exception ?

> peut-être par le meilleur choix pour un LTS.

J'avoue que mettre un logiciel aussi important que Firefox en beta dans un distribution à long support me semble peu cohérent. Je ne sens pas ubuntu pret à faire du support sur 7 ans comme Red-Hat et Novell.

Je préfère personnellement une bonne debian stable quitte à mettre quelques paquetages de backports ensuite. Au moins, on sais ce que l'on fait et c'est cohérent.

> Sisi tu peux :
> http://wwwthep.physik.uni-mainz.de/~frink/chown/readme.html

Je ne connaissais pas. Très bien même si cela n'a aps l'air tout jeune. Enfin, c'est pas très Microsoft comme solution...

> C'est quoi une ruche ?

Un bout de la base de registre.

Mon bogue avec pskill, je fait un script .bat avec un

pskill.exe -t -accepteula thunderbird;exe

Juste avant d'installer ensuite la dernière version de celui-ci. Le script marche super en inetractif. Je le lance le script sous OCS avec la commande

START /B /I mon_script.bat

Et bien, cela ne marche pas. Le script ouvre une fenêtre au pskill et s'arrête dessus. J'ai essayer avec d'autre option de START et en mettant du START et du CMD devant pskill, mon script OCS ouvre toujours un fenêtre et se bloque dessus, soit au niveau de la commande pskill, soit à la fin de mon_script ! Je suis passé à la commande prcview (pv.exe) et la, cela marche.

Bref, je ne sais pas ce qui se passe avec pskill et le compte sous lequel tourne l'agent OCS.

Sinon, on niveau des comptes, effectivement tu peux créer des comptes avec des mots de passe par machine de manière automatique et un mot de passe de 200 caractères inviolable... ce que je vois en pratique, c'est que les développeurs ne le font pas.

Je n'ai pas dis que la sécurité n'était pas possible sous Windows, je dis que comme c'est une usine à gaz, les personnes l'utilisent mal (en plus Microsoft ne nous aide pas car les outils en ligne de commande de bas niveau ne sont pas livré avec les versions de base du système, ce qui ne leur couterait rien). Du coup, comme tu le dis toi même, tous les services tournent sous le même compte...

Effectivement, c'est une mauvaise tradition qu'on pris les développeurs et cela s'améliore avec le temps. Un développeur n'a pas besoin d'être admin du poste pour développer sauf s'il veut aller jusqu'au bout et faire l'empaquetage. Et a ce niveau là, pour tester, il doit être root donc il l'est en permanence. Tant qu'il n'y aura pas un équivalent de 'sudo' pour installer et supprimer un logiciel sous un compte normal, il y aura des soucis à ce niveau à mon sens.

Enfin, je sais bien que sur un XP pro qui n'est pas en domaine, on peux faire apparaître l'onglet sécurité (mais que celui-ci apparait tout seul si on rentre en domaine). Combien de personne ont trouvé cette option, comme de personne l'on activé ?

> Mais les a2* j'ai du mal à voir en quoi c'est sexy.

D'abord, certain paquet installe plus d'un module. Ainsi (a2dismod) tu déactive certain modules sans les dé-installé.

Si tu a plusieurs sites web, tu fait un a2ensite mon_site pour l'activer et si cela ne marche pas, tu refait un a2dissite mon_site pour le déactivé. Tout cela prends quelques secondes tout au plus. Bien pratique lorsqu'un site foire en production pour une raison X ou Y.

Bref, cela crée des liens symbolique, donc par derrière, c'est très simple. C'est juste que cela simplifie l'administration système et permet en cas de bogue non prévu de réagir vite sans faire trop de connerie.

Et bien oui, ces commandes sont géniales car tu peux faire ton paquet qui se déploie et le tout en script bash des plus simples. L'édition automatique de fichier n'est pas forcément quelque chose de simple, tous les utilisateurs de cfengine par exemple le savent. Il est beaucoup plus simple de déposer des fichiers dans des dossiers et de les activer ensuite.

Etre sexy, c'est pas forcément d'avoir un écran graphique avec de la 3D et des dégradés et des choses qui bougent de partout...

Par exemple, l'installateur debian était en mode ncurse et il y a une version graphique maintenant car tout avait été pensé pour mettre une couche intermédiaire qui l'autorisait. Et bien, l'installateur debian, je le trouve vachement sexy, il marche sur tout un tas de plateforme de la même manière et ca, c'est un boulot de fou.

Sur les variables d'environnements, certes les modèles se ressemblent mais non les usages. En pratique sous Windows, elles sont stockés dans la base de registre et comme on lance dans 99% des cas des binaires, on utilise ces variables comme des variables globales. Il est vrai cependant que depuis quelques années, c'est mieux et un peu moins le zouk. Il y a encore peu, un sacré paquet de programme allait rajouter leur chemin dans la variable PATH par exemple.

AU niveau des droits et de http://support.microsoft.com/kb/308421, c'est toi qui n'a pas compris à mon sens. En root, je peux faire sous UNIX

chown toto:titi un_fichier

Sous Windows, tu as le droit de t'approprier un fichier mais tu ne peux pas le rendre a son propriétaire. Windows a été conçu pour protéger les utilisateurs de l'administrateur. Ainsi, l'admin ne peut pas prendre un fichier que l'utilisateur ne veut pas qu'il prennne sans qu'il le sache (changement du propriétaire a sens unique).

Pour su, tu me sors runas ! Cela n'a rien à voir, vas faire un runas sous admin pour lancer un executable sous le compte toto ! Cela ne marche pas car tu n'as pas le ticket kerberos. Tu es obligé d'avoir le mot de passe de toto. Comment tu fait pour avoir des services qui tournerait sur un parc de 100 machine sous un compte toto sans que celui-ci n'ai le même mot de passe, tu déploie comment ?

Moi je dis que ne pas avoir de bit suid fait que c'est la merde. Bilan 99% des services tourne sous admin. On pourrait imaginer autre chose que le bit suid mais qui soit opérationnel simplement.

> Et tu m'expliqueras le rapport entre su et des services tournant
> sous root...

Regardes les script d'init sous une debian et tu verras... Je veux lancer par exemple un service flexlm sous le compte matlab pour un serveur de licence matlab. Je fait comment sous Windows ? Et bien, dans 99% des cas, il tournera sous root. Sous linux, il tournera sous un compte qui ne sers qu'a cela,

C'est pas que cela soit impossible à faire sous WIndows, c'est qu'en pratique, ce n'est pas fait car c'est une usine à gaz pour faire des choses simples.

> Perso, et au vu de ta meconnaissance du systeme, je pencherai
> pour une autre explication.

Je viens de tomber sur un bogue bien étrange avec pskill.exe ! Et des spécialistes Windows autour de moi n'y comprennent rien ! Le compte SYSTEM n'est pas un vrai compte car il n'a pas de ruche... C'est toi qui est mauvaise langue, il y a des choses parfois bizarre lorsqu'on lance des choses sous SYSTEM à cause de cela. Mais lancer des trucs sous SYSTEM est une des seules méthodes pour les lancer sans avoir à stocker le mot de passe dans le registre...

Au niveau des ACL, j'ai très bien compris comment cela marche et pour cause, je fait des ACL depuis des années sous UNIX. Je te dis que beaucoup de personnes sous Windows n'y comprennent rien, c'est différent. Le fait d'avoir mis une tripoté d'ACL fait qu'en pratique, c'est très peu utilisé. Il faut voir le nombre de logiciel qu'on installe et ou on est obligé d'aller bidouiller les ACL pour que cela marche pas lorsqu'on n'est pas admin.

Tu vas me dire, les logiciels sont mal fait. Je te dis oui et c'est mal fait car le système d'ACL est trop complexe et que, n'ayant pas de sudo et de su correct, les dévelppeurs sont tous admin de leur poste. Bilan, c'est mal dévleloppé et cela, depuis des années... heureusement, les choses de ce coté là aussi sont moins pire qu'il y a quelques années.

Enfin, sur la finition de XP, il n'y a pas d'onglet sécurité sur XP Pro ! Ce n'est que lorsque tu intègre XP pro en domaine que tout change et que tu te retrouves avec une interface comme 2000.

Donc pas d'ACL pour l'utilisateur lambda s'il n'est pas en domaine...

Pour tout cela, je continue de penser que le modèle de Microsoft est mal pensé car presque 10 ans après la sortie de 2000, c'est encore mal intégré par plein de développeur.

Tu peux aussi partir sur Catayst ou Jifty, c'est en Perl, dans le même esprit et même si je ne les ai pas essayé, je n'ai que très rarement été deçu par les grosses applications Perl qui s'avèrent souvent très stable dans le temps.