C'est sur que sur tous mes serveurs, je passe mon temps à accéder à la ligne 100000 des fichiers de log !
Perl est capable de trouver cette ligne très rapidement et c'est pas une action vraiment utile en temps réel sur un OS standard... Que sur un serveur central de log, cela soit utile, OK, mais on peux alors utiliser un backend SQL spécialisé...
Combien de service démarre avant rsyslogd ? C'est le problème de la poule et de l'oeuf... Ni a t'il pas un moyen de gérer cela d'une autre manière. Par exemple, ces applications enverraient leur log au noyau donc klogd tant que syslogd n'est pas actif. Tout remettre en cause et rendre les choses incompatible pour quelques secondes me semble excessif.
J'utilise monit pour relancer les services qui crash. Ca marche... On aurait pu améliorer monit !
Monit permet de dissocier le démarrage de la supervision des services eux-mêmes.
Un des principes d'UNIX, faire une chose et le faire bien. Je trouve personnellement que systemd en fait trop et j'aime pas trop son connecteur DBUS. Pour un processus aussi sensible, cela fera la joie du vers un jour...
Format libre = souplesse au cours du temps. Des outils comme Perl parse cela sans problème...
Date -> bordel -> timestamp
Base données mysql -> bof. Je verrais plutôt une base de taille fixe à la RRD s'il fallait changer ou plutôt donner le choix !
Non compatibilité avec syslog -> débile
Problème au démarrage -> je croyais qu'il y a avait klogd pour ca.
...
Syslogd n'est pas parfait. Plutôt que de faire des améliorations, on change tout ! Ca va être un produit conçu à la mode du moment. Red-Hat a déjà foutu des fichiers XML de config à droite et à gauche, c'est bien pour les IHM payante de gestion de parc mais c'est loin, très loin d'être parfait. Bref, j'ai pas une confiance à 100% dans tout ce que fait Red-Hat (d'ailleurs, j'ai quitter les distributions Red-Hat il y a plus de 10 ans pour justement des problèmes de conception).
Idem, je ne sais pas vraiment comment marche le son sur mon PC mais je ne vois aucun truc en puseaudio. Je précise qu'il y a toujours 2 sessions en // par deux utilisateurs différents. J'ai rien modifié, tout marche tout seul (Debian Squeeze).
Je ne crois pas trop au tout espace utilisateur pour les drivers...
Par contre, avec la virtualisation qui s'invite de plus en plus partout, le "nettoyage" par le noyau d'un driver foireux sera de plus en plus facile à faire en restant en mode noyau. Xen par exemple explore cette piste en mettant certain driver dans des dom0 prime (cela reste pour le moment de l'ordre de la recherche je crois).
J'ai pas compris son problème avec la sécurité. Tu envois tes log sur un serveur central qui est blindé...
Si effectivement, toute ton architecture est une passoire, les log ne serviront à rien.
Sinon, la souplesse d'UNIX est de faire des choses simples, souples et orthogonales. A force de trop vouloir normalisé, il va finir par trop contraindre l'ensemble qui n'arrivera pas à évoluer au cours du temps et devra être remplacer un jour par autre chose car il aura oublié de traiter un cas particulier.
Les "Stores" ont aussi un avantage (ou un inconvénient) comparé au dépôt des distributions, la personne dépose elle même son application et en gère elle même les évolutions. Je suis sur qu'un paquet d'application que l'on trouve dans l'AppleStore aurait un mal fou à intégrer les dépôts debian par exemple ;-)
On ne paye pas le prix des industriels mais depuis quelques années, le tarifs montent bien plus vite que l'inflation. Par exemple, Comsol a été multiplié par 5. La palme du pire a été un module Ansys qui a pris un facteur 7 en 2 ans... Heureusement que nous n'en avons pas une utilisation intensive !
Bien sur, les solver d'Ansys sont natifs ! C'est le workbench qui m'a l'air d'être une daube de première.
Sinon, nous utilisons en pratique Soliworks dans mon labo (c'est aussi Dasasult mais beaucoup plus abordable) mais a petite dose par les expérimentateurs afin de dessiner les futurs manip. Rien de crucial de ce coté là. Je vais regarder du coté de NX mais à vrai dire, c'est une activité tellement annexe chez nous que mon point est assez faible dans les décisions ;-)
Sur debian squeeze, j'ai basculé tous mes serveurs sous sssd. C'est sssd qui est connecté au LDAP. La configuration est au final bien plus simple et le tout est robuste au petit problème réseau. Bref, même sans réseau, cela fonctionne tout seul en autonomie...
Je peux te dire que si tous les outils d'Adobe était sous Linux, on les achèterais dans mon laboratoire ! On les as sous Mac et Windows, et il n'y a aucune raison pour lesquelles on ne les aurait pas sous GNU/Linux.
Ceci dis, Adobe ne les vends pas et personnellement, cela m'arrange ;-)
Matlab, Ansys, Comsol, ifort, IDL... tournent sous linux et les universitaires y laisse un paquet d'Euros
Cela fait des années qu'on attend un CATIA sous Linux (qui marche d'ailleur déjà chez eux).
Les éditeurs de logiciels proprio SONT les bienvenues. Ne sont pas bienvenue les virus grand public à la "adaube" qui n'apporte rien au final...
PS : a noter qu'Ansys est une énorme DAUBE pour le prix qui le vende. Lors de l'installation, il y a un paquet de fichier .exe et on apprends via un file qu'il sont au format PE et tournent avec la CLI de C# ! Evidement, cela se traine lamentablement et pose quelques soucis avec X-Windows. Pour le prix du logiciel, on aimerait avoir du natif.
PPS : A noter que tous les gros logiciels sont livrés avec tout (leur java, leur...) et donc tournent souvent très bien sous tous les GNU/Linux (jamais eu de vrai problème sous debian par exemple).
Il m'arrive de faire un ipmitool power off / power on sur des noeuds de calcul. Pas souvent mais quand même trop...
Ce qui m'intrigue avec Minix, c'est que c'est simple robuste, très bien pour l'embarqué et tout et tout mais :
cela ne tourne pour le moment que sur x86
quid de l'amd64 ?
le portage vers ARM ne commencera qu'en janvier !
Bref, on parle d'un système génial et super robuste mais qui semble ne tourner actuellement que sur une seule archi. Tout programmeur sais que le changement de système amène son flot de bogue...
Est ce qu'EFL a un bus logiciel au dessus de la boucle d'évènement ? Si ce bus est si optimisé que cela, on pourrait peut être le proposer à systemd en remplacement de dbus ?
Dommage que la machine la plus puissante soit réservé exclusivement aux militaires et en plus pour l'arme atomique qui est sensé ne jamais servir. La priorité serait quand même de trouver des solutions à la fin du pétrole...
Sinon, ce genre de machine consomme un paquet. A une époque, le CERN ne fonctionnait pas l'hiver mais seulement l'été pour une question de coût électrique (a ce qu'on m'a dis). Ne pourrait'on pas faire tourner ces clusters la nuit à la place de l'éclairage public qui de minuit à 5h du matin ne sers à rien. Au moins l'énergie des centrales nucléaires pourraient servir à quelques choses d'utiles... (en plus, de nuit dans pas mal de région, la clim est inutile si la salle serveur a été conçu en circuit ouvert).
J'utilise un cluster de relais de courriel codé en Perl : Qpsmtpd. Depuis qu'on utilise cette solution, on a des délais bien plus faible de livraison des courriel qu'avec Postfix par exemple.
Un reverse proxy HTTP n'a rien à voir avec un relais SMTP mais c'est juste pour dire que les langages de script ne sont pas toujours mauvais. Idem avec la comparaison Nagios (coeur en C) / Shinken (coeur en Python).
PS : l'ajout de module et la modification de code dans Qpsmtpd est hyper facile donc j'en ai fais quelque unes alors que je n'ai jamais modifié un Postfix ni recompilé celui-ci...
Sur le papier, Bourane est d'ailleurs bien mieux conçu que la navette américaine justement car elle est au sommet d'une fusée et n'intègre pas le moteur principal ce qui est une mauvaise bonne idée à notre niveau d'ingénierie.
Hermès est mort né mais après coup, on peux dire que c'est une bonne chose. Actuellement, la voie Russe est la bonne pour transporter des humains, à savoir des vaisseaux simple, basique et de très bonne qualité fabriqués à la chaîne qu'on jette après la première utilisation.
S'il y avait vraiment besoin de faire revenir des satellites sur Terre, une navette automatique la plus légère possible de type Bourane serait une bonne voie je pense. D'ailleurs, une ou deux navettes de ce genre au niveau mondial devrait suffire, j'ai l'impression qu'on ramène finalement peu de chose de la haut...
C'est mon "vocabulaire". Il suffit de se renseigner en lisant à droite et à gauche. Le module lunaire n'avait par exemple qu'un seul moteur qui n'a jamais été testé en condition réel avant alunissage... Il faut voir la mission Apollo 13... Pour la première mission sur la lune, le président américain avait un discours tout près s'il fallait faire un sacrifice humain. Cela donne l'impression d'un super boulot d'ingénieur comme peux être régler une voiture de formule 1 mais pas forcément une mission dont on maîtrise tous les paramètres. Ceci dis, le matériel américain a été parfait même si de nos jours, on ne renverrais pas des personnes dans ce même matériel (sauf peut être les chinois). L'erreur de conception a été faite après avec la navette mais cela est une autre histoire...
Sinon, la NASA a parait'il bidouillé quelques séquences vidéo, c'est une énorme erreur après coup car il y a maintenant des personnes qui remettent en cause l'ensemble du programme lunaire, ce qui n'a aucun sens !
Tout à fait d'accord avec toi, il faut arrêter de prendre les russes pour des cons ;-)
Il faut savoir qu'un gros problème de satellites (sondes...) est que lorsque les moteurs sont a l'arrêt, il n'y a plus de gravité... Or, quasiment tous les systèmes que nous avons font l'hypothèse d'une gravité. Sans gravité par exemple, les fluides n'ont aucune raison de prendre certains tuyaux si on ne les aide pas a les prendre. On peux donc facilement avoir des soucis d'amorçage !
Les américains sur la lune ont eu "de la chance". Le matos était exceptionnel mais il serait impossible dans les conditions actuelles de renvoyer des spationautes dans le même type de matériel. D'ailleurs, sur la lune, il y a de la gravité ce qui d'un certain coté a simplifié les choses pour le module lunaire.
[^] # Re: systemd
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 2.
Qu'est ce qui empêcherait monit ou mon d'être notifier directement ?
[^] # Re: Problèmes de Syslog
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 3.
C'est sur que sur tous mes serveurs, je passe mon temps à accéder à la ligne 100000 des fichiers de log !
Perl est capable de trouver cette ligne très rapidement et c'est pas une action vraiment utile en temps réel sur un OS standard... Que sur un serveur central de log, cela soit utile, OK, mais on peux alors utiliser un backend SQL spécialisé...
Combien de service démarre avant rsyslogd ? C'est le problème de la poule et de l'oeuf... Ni a t'il pas un moyen de gérer cela d'une autre manière. Par exemple, ces applications enverraient leur log au noyau donc klogd tant que syslogd n'est pas actif. Tout remettre en cause et rendre les choses incompatible pour quelques secondes me semble excessif.
[^] # Re: systemd
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 6.
J'utilise monit pour relancer les services qui crash. Ca marche... On aurait pu améliorer monit !
Monit permet de dissocier le démarrage de la supervision des services eux-mêmes.
Un des principes d'UNIX, faire une chose et le faire bien. Je trouve personnellement que systemd en fait trop et j'aime pas trop son connecteur DBUS. Pour un processus aussi sensible, cela fera la joie du vers un jour...
[^] # Re: Problèmes de Syslog
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 7.
Aller au 100 message -> ligne 100
Format libre = souplesse au cours du temps. Des outils comme Perl parse cela sans problème...
Date -> bordel -> timestamp
Base données mysql -> bof. Je verrais plutôt une base de taille fixe à la RRD s'il fallait changer ou plutôt donner le choix !
Non compatibilité avec syslog -> débile
Problème au démarrage -> je croyais qu'il y a avait klogd pour ca.
...
Syslogd n'est pas parfait. Plutôt que de faire des améliorations, on change tout ! Ca va être un produit conçu à la mode du moment. Red-Hat a déjà foutu des fichiers XML de config à droite et à gauche, c'est bien pour les IHM payante de gestion de parc mais c'est loin, très loin d'être parfait. Bref, j'ai pas une confiance à 100% dans tout ce que fait Red-Hat (d'ailleurs, j'ai quitter les distributions Red-Hat il y a plus de 10 ans pour justement des problèmes de conception).
[^] # Re: systemd
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 3.
Idem, je ne sais pas vraiment comment marche le son sur mon PC mais je ne vois aucun truc en puseaudio. Je précise qu'il y a toujours 2 sessions en // par deux utilisateurs différents. J'ai rien modifié, tout marche tout seul (Debian Squeeze).
[^] # Re: Avis de Linus Torvalds sur les micro-noyaux
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 2.
Je ne crois pas trop au tout espace utilisateur pour les drivers...
Par contre, avec la virtualisation qui s'invite de plus en plus partout, le "nettoyage" par le noyau d'un driver foireux sera de plus en plus facile à faire en restant en mode noyau. Xen par exemple explore cette piste en mettant certain driver dans des dom0 prime (cela reste pour le moment de l'ordre de la recherche je crois).
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 4.
J'ai pas compris son problème avec la sécurité. Tu envois tes log sur un serveur central qui est blindé...
Si effectivement, toute ton architecture est une passoire, les log ne serviront à rien.
Sinon, la souplesse d'UNIX est de faire des choses simples, souples et orthogonales. A force de trop vouloir normalisé, il va finir par trop contraindre l'ensemble qui n'arrivera pas à évoluer au cours du temps et devra être remplacer un jour par autre chose car il aura oublié de traiter un cas particulier.
[^] # Re: Premier commentaire du Zeit
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Entretien avec Linus Torvalds sur ZEIT ONLINE. Évalué à 2.
A l'université, on utilise bien plus de 1000 Windows, jamais entendus parlé des sources...
Je pense que c'est quand même un peu plus compliqué pour avoir les sources !
[^] # Re: Tout faux
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Entretien avec Linus Torvalds sur ZEIT ONLINE. Évalué à 2.
Les "Stores" ont aussi un avantage (ou un inconvénient) comparé au dépôt des distributions, la personne dépose elle même son application et en gère elle même les évolutions. Je suis sur qu'un paquet d'application que l'on trouve dans l'AppleStore aurait un mal fou à intégrer les dépôts debian par exemple ;-)
[^] # Re: Tout faux
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Entretien avec Linus Torvalds sur ZEIT ONLINE. Évalué à 3.
On ne paye pas le prix des industriels mais depuis quelques années, le tarifs montent bien plus vite que l'inflation. Par exemple, Comsol a été multiplié par 5. La palme du pire a été un module Ansys qui a pris un facteur 7 en 2 ans... Heureusement que nous n'en avons pas une utilisation intensive !
Bien sur, les solver d'Ansys sont natifs ! C'est le workbench qui m'a l'air d'être une daube de première.
Sinon, nous utilisons en pratique Soliworks dans mon labo (c'est aussi Dasasult mais beaucoup plus abordable) mais a petite dose par les expérimentateurs afin de dessiner les futurs manip. Rien de crucial de ce coté là. Je vais regarder du coté de NX mais à vrai dire, c'est une activité tellement annexe chez nous que mon point est assez faible dans les décisions ;-)
# sssd
Posté par Sytoka Modon (site web personnel) . En réponse au message Problème LDAP (enfin plutot réseau). Évalué à 2.
Sur debian squeeze, j'ai basculé tous mes serveurs sous sssd. C'est sssd qui est connecté au LDAP. La configuration est au final bien plus simple et le tout est robuste au petit problème réseau. Bref, même sans réseau, cela fonctionne tout seul en autonomie...
[^] # Re: nouveau langage ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Entretien avec Linus Torvalds sur ZEIT ONLINE. Évalué à 5.
Vala ?
[^] # Re: Tout faux
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Entretien avec Linus Torvalds sur ZEIT ONLINE. Évalué à 4.
Je peux te dire que si tous les outils d'Adobe était sous Linux, on les achèterais dans mon laboratoire ! On les as sous Mac et Windows, et il n'y a aucune raison pour lesquelles on ne les aurait pas sous GNU/Linux.
Ceci dis, Adobe ne les vends pas et personnellement, cela m'arrange ;-)
[^] # Re: Tout faux
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Entretien avec Linus Torvalds sur ZEIT ONLINE. Évalué à 5.
Matlab, Ansys, Comsol, ifort, IDL... tournent sous linux et les universitaires y laisse un paquet d'Euros
Cela fait des années qu'on attend un CATIA sous Linux (qui marche d'ailleur déjà chez eux).
Les éditeurs de logiciels proprio SONT les bienvenues. Ne sont pas bienvenue les virus grand public à la "adaube" qui n'apporte rien au final...
PS : a noter qu'Ansys est une énorme DAUBE pour le prix qui le vende. Lors de l'installation, il y a un paquet de fichier .exe et on apprends via un file qu'il sont au format PE et tournent avec la CLI de C# ! Evidement, cela se traine lamentablement et pose quelques soucis avec X-Windows. Pour le prix du logiciel, on aimerait avoir du natif.
PPS : A noter que tous les gros logiciels sont livrés avec tout (leur java, leur...) et donc tournent souvent très bien sous tous les GNU/Linux (jamais eu de vrai problème sous debian par exemple).
[^] # Re: Fiabilité
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 5.
Il m'arrive de faire un ipmitool power off / power on sur des noeuds de calcul. Pas souvent mais quand même trop...
Ce qui m'intrigue avec Minix, c'est que c'est simple robuste, très bien pour l'embarqué et tout et tout mais :
cela ne tourne pour le moment que sur x86
quid de l'amd64 ?
le portage vers ARM ne commencera qu'en janvier !
Bref, on parle d'un système génial et super robuste mais qui semble ne tourner actuellement que sur une seule archi. Tout programmeur sais que le changement de système amène son flot de bogue...
[^] # Re: Pas assez bien
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 10.
Si Minix prends réellement, on aura de toute manière une Debian GNU/Minix ;-)
[^] # Re: Ou pas
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 10.
C'est exactement cela. On sens dans ses réponses qu'il n'a toujours pas digérer le succès de Linux. Il en veux aussi à la GPL...
[^] # Re: Java en 78?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 10.
Java n'a rien inventé. Je me souviens avoir utilisé début des années 80 le Pascal USCD.
http://en.wikipedia.org/wiki/UCSD_Pascal
Tout cela est bien connu. Java est une opération marketing qui a plutôt bien fonctionné...
[^] # Re: Dommage que la dépêche soit un peu courte
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche EFL 1.1 alpha. Évalué à 1.
Est ce qu'EFL a un bus logiciel au dessus de la boucle d'évènement ? Si ce bus est si optimisé que cela, on pourrait peut être le proposer à systemd en remplacement de dbus ?
# En france
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le Top 500 de novembre 2011. Évalué à 0.
Dommage que la machine la plus puissante soit réservé exclusivement aux militaires et en plus pour l'arme atomique qui est sensé ne jamais servir. La priorité serait quand même de trouver des solutions à la fin du pétrole...
Sinon, ce genre de machine consomme un paquet. A une époque, le CERN ne fonctionnait pas l'hiver mais seulement l'été pour une question de coût électrique (a ce qu'on m'a dis). Ne pourrait'on pas faire tourner ces clusters la nuit à la place de l'éclairage public qui de minuit à 5h du matin ne sers à rien. Au moins l'énergie des centrales nucléaires pourraient servir à quelques choses d'utiles... (en plus, de nuit dans pas mal de région, la clim est inutile si la salle serveur a été conçu en circuit ouvert).
[^] # Re: PHP vs C
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche NAXSI, un module de filtrage HTTP pour nginx. Évalué à 4.
J'utilise un cluster de relais de courriel codé en Perl : Qpsmtpd. Depuis qu'on utilise cette solution, on a des délais bien plus faible de livraison des courriel qu'avec Postfix par exemple.
Un reverse proxy HTTP n'a rien à voir avec un relais SMTP mais c'est juste pour dire que les langages de script ne sont pas toujours mauvais. Idem avec la comparaison Nagios (coeur en C) / Shinken (coeur en Python).
PS : l'ajout de module et la modification de code dans Qpsmtpd est hyper facile donc j'en ai fais quelque unes alors que je n'ai jamais modifié un Postfix ni recompilé celui-ci...
# FileTea
Posté par Sytoka Modon (site web personnel) . En réponse au journal De la bonne façon d'échanger ses fichiers dans un serveur.... Évalué à 2.
C'est assez pratique et en plus il y a maintenant un paquet debian
https://filetea.me
http://blogs.igalia.com/berto/2011/11/10/filetea-now-available-in-debian/
En gros, on obtient une URL qu'on va partager par courriel à l'autre personne qui récupère le fichier.
Plutôt que le courriel, on doit pouvoir aussi utiliser le bon vieux talk sous UNIX si on est sur la même machine...
[^] # Re: Pas des débutants mais...
Posté par Sytoka Modon (site web personnel) . En réponse au journal La sonde russe Phobos-Grunt en perdition. Évalué à 2.
Sur le papier, Bourane est d'ailleurs bien mieux conçu que la navette américaine justement car elle est au sommet d'une fusée et n'intègre pas le moteur principal ce qui est une mauvaise bonne idée à notre niveau d'ingénierie.
Hermès est mort né mais après coup, on peux dire que c'est une bonne chose. Actuellement, la voie Russe est la bonne pour transporter des humains, à savoir des vaisseaux simple, basique et de très bonne qualité fabriqués à la chaîne qu'on jette après la première utilisation.
S'il y avait vraiment besoin de faire revenir des satellites sur Terre, une navette automatique la plus légère possible de type Bourane serait une bonne voie je pense. D'ailleurs, une ou deux navettes de ce genre au niveau mondial devrait suffire, j'ai l'impression qu'on ramène finalement peu de chose de la haut...
[^] # Re: Loi de Murphy
Posté par Sytoka Modon (site web personnel) . En réponse au journal La sonde russe Phobos-Grunt en perdition. Évalué à 2.
C'est mon "vocabulaire". Il suffit de se renseigner en lisant à droite et à gauche. Le module lunaire n'avait par exemple qu'un seul moteur qui n'a jamais été testé en condition réel avant alunissage... Il faut voir la mission Apollo 13... Pour la première mission sur la lune, le président américain avait un discours tout près s'il fallait faire un sacrifice humain. Cela donne l'impression d'un super boulot d'ingénieur comme peux être régler une voiture de formule 1 mais pas forcément une mission dont on maîtrise tous les paramètres. Ceci dis, le matériel américain a été parfait même si de nos jours, on ne renverrais pas des personnes dans ce même matériel (sauf peut être les chinois). L'erreur de conception a été faite après avec la navette mais cela est une autre histoire...
Sinon, la NASA a parait'il bidouillé quelques séquences vidéo, c'est une énorme erreur après coup car il y a maintenant des personnes qui remettent en cause l'ensemble du programme lunaire, ce qui n'a aucun sens !
[^] # Re: Loi de Murphy
Posté par Sytoka Modon (site web personnel) . En réponse au journal La sonde russe Phobos-Grunt en perdition. Évalué à 3.
Tout à fait d'accord avec toi, il faut arrêter de prendre les russes pour des cons ;-)
Il faut savoir qu'un gros problème de satellites (sondes...) est que lorsque les moteurs sont a l'arrêt, il n'y a plus de gravité... Or, quasiment tous les systèmes que nous avons font l'hypothèse d'une gravité. Sans gravité par exemple, les fluides n'ont aucune raison de prendre certains tuyaux si on ne les aide pas a les prendre. On peux donc facilement avoir des soucis d'amorçage !
Les américains sur la lune ont eu "de la chance". Le matos était exceptionnel mais il serait impossible dans les conditions actuelles de renvoyer des spationautes dans le même type de matériel. D'ailleurs, sur la lune, il y a de la gravité ce qui d'un certain coté a simplifié les choses pour le module lunaire.