Sytoka Modon a écrit 4546 commentaires

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.

> Au hasard ton point de vue sur le modele de securite dans Windows,
> qui est pourtant absolument identique a celui dans Linux

FAUX.

Le modèle UNIX a des variables d'environnement attachées aux processus et qui s'hérite de père en fils, mais non l'inverse. Un fils ne peut influencer le fils d'un autre processus. Cette indépendance est fondamentale pour la stabilité et la simplicité de l'ensemble et c'est pourquoi je déteste gconf. Lorsque je modifie un paramêtre important, je préfère relancer les applications. En plus, cela n'arrive pas souvent.

Sous Windows, les variables d'environnement sont globales par utilisateurs, voir pour le système. D'ailleurs, tout cela est stockée dans la base de registre qui est un énorme système de variable globale. C'est exactement ce que l'on déconseille à tout programmeur.

Sous UNIX, root avait (c'est en train de changer) tous les pouvoirs, ce n'est pas le cas sous Windows. Sous Windows, le root ne peut pas faire un chown...

Sous Windows, avec le système kerberos, on n'a pas de système équivalent a su, sudo... Bref de bit suid. Bilan, c'est une usine à gaz et une vrai daube lorsqu'on veut lancer en batch des choses sous un autre compte. Il suffit de voire le nombre de service qui tourne sous root sur un Windows pour voir l'échec de cette architecture de sécurité.

Je ne parle pas du compte SYSTEM qui existe sans exister et dont les scripts .bat ont un comportement parfois plus qu'étrange...

Alors oui, il y a des ACL sur les fichiers sous Windows et sous Linux. Ce n'est pas suffisant pour dire que la sécurité est basée sur le même modèle. Surtout qu'encore une fois, les ACL de Windows sont une telle usine à gaz qu'il y a tant de réglage possible que je n'ai pas encore rencontré une seule personne capable de faire des réglages beaucoup plus pointus que s'il y avait 4 ou 5 réglages possibles, comme sous UNIX ! La encore Windows à tuer les ACL avec leur complexité. D'ailleurs, lorsqu'on n'est pas en domaine, Microsoft a préféré les cacher aux utilisateurs, c'est tout dire.

Il ne faut pas oublier l'aspect multiplateforme de debian. Il ne suffit pas de faire une distribution x86 et amd64. debian corrige et fait remonter plein de bogue, notament pour X par exemple. Surtout que les développeurs debian sont par exemple bien plus pointilleux que ceux de ubuntu sur les scripts systèmes. Les scripts dans init.d chez debian sont nickel et si madame michu ne le voit pas, c'est bien qu'ils le fassent quand même. J'ai sous la main des anciens IBM qui ont 8 ans et le /etc est un vrai bordel.

Sur l'aspect multiplateforme, il y a debian hurd, debian BSD...

debian bosse aussi vachement à l'upgrade de ses systèmes. J'ai des machines en production qui ont eu 4 version de debian sans ré-installation ! Ils ont donc fait un fichier de config pour exim modulaire, idem pour apache2....

dernier exemple, debian bosse en ce moment sur netconf pour ocnfigurer le réseau de manière souple, un mix entre le système network/interface actuel de debian et NetworkManager. Tout cela avec le soucis de faire quelques chose de très modulaire, qui ne soit pas un usine à gaz, qui n'impose pas une interface graphique mais qui puisse être piloté graphiquement.

Bref, comme le disent les développeurs de X-Window, il n'y a pas que le noyau ou le dernier bureau à la mode avec ses effets 'eyes candy'.

Et toi, on voit que tu ne gères pas 300 machines ;-)

Dans un projet comme cela, je choisir la licence du langage. Donc si je fait du Perl, je vais mettre la même chose que Perl, c'est à dire Artistic Licence.

L'intérêt est de pouvoir utiliser tous les modules du langage sans se poser la moindre question.

Je ne sais pas sous quelle licence est le CPAN de LUA.

Pour le A6, je ne sais pas, je n'ai jamais fait si petit. Pour le A5, il y a psbook qui divise les pages en deux (a2ps aussi). On travaille en A4 et on imprime en A5.

On doit pouvoir faire la même chose et passer du A4 au A6, comme on passe du A4 au A0 lorsqu'on fait un poster pour une conférence.

Pour ce qui est de faire un macro langage, on est tous tenté de le faire. Mais de la à faire aussi bien que TeX... Ton histoire d'interligne et de police de caractère, on trouve cela dans toutes les bonnes doc sur LaTeX.

Je partirai personnellement plutôt vers un macro langage qui transforme en LaTeX qui transforme le résultat en pdf. Mais bon, encore une fois, tout dépend de l'utilisation finale.