Florent Rougon a écrit 48 commentaires

Je n'ai pas discuté ce que tu appelles le francocentrisme de la définition pointée (je n'ai pas assez connaissance des us et coutumes de part le monde pour pouvoir prendre position sur ce point). Donc ton premier item n'est pas en rapport avec ce que j'ai écrit ; il faut peut-être relire le contexte.

Concernant ton deuxième point : oui, ce serait mieux à mon avis. Mais je ne suis pas censeur, tu fais ce que tu veux. À mon humble avis, déclarer fausse (ainsi qu'on peut le lire ci-dessus) une des définitions possibles ne donne pas une très bonne image de ton travail — sans oublier les autres contributeurs. C'est dommage, mais comme on dit, c'est vous qui voyez…

Enfin, votre paragraphe 0.4 : oui, très bien, à ceci près que dire que la définition pointée n'est jamais utilisée en dehors du lycée ne correspond pas à la réalité que j'ai connue et qui existe encore dans les livres que je possède (je parle bien de livres post-bac). D'ailleurs, dans cette réalité, la définition (pointée) de la limite m'a été enseignée correctement par mon prof de première (merci M. Coupry !), avec quantificateurs, epsilons et explications adaptées. Je ne sais pas si beaucoup de lycéens d'aujourd'hui ont la chance qu'on leur définisse correctement ce concept, avec lequel ils sont pourtant censés travailler dès la première (le programme de 1re S interdit explicitement une « définition formelle », celui de Terminale S reste très vague).

Voilà… bonne journée.

Je ne sais pas trop ce qui te permet de décider de ce qu'est « ce à quoi s'attend la totalité de la communauté », mais passons. Je ne rentrerai pas dans la polémique Wikipédia, en revanche je note que la dépêche qualifie toujours de « fausse » la définition donnée dans de nombreux livres de l'enseignement supérieur, et que cela ne semble pas t'émouvoir plus que cela. Niveau « principe de neutralité de point de vue », je suis sûr que les auteurs apprécieront. Je ne citerai pas les Tout-en-un niveau L1 ou CPGE divers et variés, mais juste deux livres d'analyse écrits par des mathématiciens français reconnus que j'ai sous la main (les livres…) : Roger Godement, Analyse mathématique, t.1, p. 65 et Gustave Choquet, Cours de topologie, p. 26. Je n'ai pas Bourbaki sous la main, mais d'après le papier de Daniel Perrin suscité, c'est également la définition dite pointée qui est adoptée dans son traité. Je ne pense pas que Daniel Perrin ait inventé cela. Si je comprends bien ton commentaire, tout cela n'est en somme que des « sources secondaires » ?

Je serais en ce cas très intéressé de connaître ta définition d'une source primaire pour le sujet qui nous préoccupe, à savoir la définition de la limite d'une fonction en un point. Ceci bien-sûr car je brûle d'impatience de pouvoir la consulter afin de connaître (enfin !) la Vérité. :-)

Comme tu as l'air de le savoir, les définitions en maths sont une affaire de convention, il y a hélas parfois plusieurs définitions non équivalentes pour le même terme, et c'est à chaque auteur qu'il revient de préciser avec lesquelles il travaille pour que les choses soient claires. Je ne pense pas qu'il soit acceptable de qualifier de fausse une définition simplement parce qu'elle serait peu utilisée en dehors de France.

Ce n'est pas parce que quelque chose vient de l'étranger, ou est très utilisé à l'étranger, que c'est forcément mieux que ce que l'on fait en France (il serait d'ailleurs temps que les médias s'en rendent compte). Voir par exemple le ridicule absolu des définitions d'une increasing funtion et d'une nonincreasing function sur un intervalle I, selon Wolfram/MathWorld (en terminologie française : respectivement fonction croissante et fonction décroissante). Pour ceux qui n'auraient pas réalisé, une fonction peut fort bien être « not increasing » sans être nonincreasing. Magnifique, n'est-ce pas ? Et c'est bien ce que « tout le monde » utilise en dehors de France, hein ? On appréciera aussi la clarté et la simplicité d'expressions telles que « non-negative » pour signifier « positif ou nul », sans parler des yards, feet et inches qui, heureusement, ont un pendant international un peu plus raisonnable.

@Benoît Sibaud : j'ai oublié de te remercier pour le ticket de suivi dans mon précédent message, voilà qui est réparé. :-)

Bien, j'espère que les gentils spécialistes de CSS aiment les fruits à basse altitude. ;-)

Merci pour ta réponse. Je connais le système de masquage automatique des commentaires en fonction de leur note, mais je confirme mon précédent message : je parlais bien de ce que l'on voit avant de poster le commentaire, après avoir cliqué sur le bouton Prévisualiser. Peut-être le problème est-il lié à la CSS ?

Voici ce que ça donne pour le présent commentaire :

Bonjour,

Merci pour le kolossal travail. Concernant la « définition fausse très discutable fausse donnée sur Wikipédia », c'est un tantinet exagéré et partial. Pour des points de vue plus argumentés sur les avantages et inconvénients de chaque définition, on lira avec intérêt ce papier de Daniel Perrin (grand mathématicien français et professeur très apprécié de ses élèves) ainsi que cette discussion sur le forum les-mathematiques.net.

(Bizarre : la prévisualisation de ce commentaire n'affiche que le sujet…)

Bonour, je cite une phrase de la dépêche :

GNUSTEP est le nom de cette distribution embarquant GNUstep, qui est comparable à Qt, GTK et plus encore, car il offre des API non graphiques appelées FoundationKit).

Cette façon de présenter les choses ne me semble pas correcte. Qt contient une quantité considérable de classes/APIs n'ayant peu ou rien à voir avec la création d'interfaces graphiques : pour les communications réseau, le multithreading, l'accès aux bases de données, l'internationalisation… D'ailleurs, on peut faire des applications Qt non graphiques avec la classe QCoreApplication, c'est prévu pour.

Cela fait longtemps que je n'ai pas regardé les APIs GNOME, mais il y a certainement là aussi des « API non graphiques » comme GVfs.

Oui, le wiki d'Arch Linux est remarquable. Il m'a servi bien des fois, alors que je n'ai jamais utilisé cette distribution. C'est une très belle vitrine pour Arch Linux !

Ouh là, quelle réaction. :-)

Bon, je pense qu'on est à peu près d'accord. L'idée à laquelle je m'opposais est celle selon laquelle sous Linux, on pourrait tranquillou recopier son /home et repartir comme en quarante. Si on est d'accord sur le fait que c'est faux, pas de problème.

Alors, que faire en restant réaliste ? Tu évoques le cas de l'utilisateur qui ne serait pas capable d'auditer son .bashrc autrement qu'en s'en remettant à un antivirus. Un tel utilisateur n'a par définition pas pu faire de changement « intéressant » à ces fichiers-là(*), par conséquent il n'a pas besoin de les récupérer : mieux vaut repartir des versions installées avec la nouvelle distrib, je pense. Eh puis il y a les autres utilisateurs, qui ont passé peut-être des dizaines d'heures sur leurs fichiers de config ou autres. Dans ce cas, je pense qu'il faut manuellement sélectionner et inspecter les fichiers qui en valent la peine, un à un, avant de les réutiliser pour le nouveau système. C'est chiant, mais moins que de ce qui pourrait se passer si l'attaquant gardait le contrôle du système (en tout cas, c'est moins égoïste, car rappelons que les machines rootées servent très souvent de base pour attaquer d'autres personnes plus ou moins incognito—hélas, il y a beaucoup de personnes égoïstes :-/).

Si les plus vieux backups que tu as datent d'un mois, c'est qu'il faut changer de système… de backup. Quant aux dépots Git et autres, je pense que c'est un des cas les plus simples à condition qu'ils aient un miroir en ligne et que d'autres personnes les utilisent et communiquent (oui, ça fait pas mal de conditions; la seule autre solution est de comparer avec un backup à mon avis…). Car même si l'attaquant a réécrit l'histoire dans le dépôt, à moins que tous les autres n'utilisent des paramètres très bizarres (--no-ff pour 'git pull' ?), ils vont s'apercevoir qu'il y a un problème en essayant de mettre à jour leur clone, et avant de se faire contaminer, en plus. Donc c'est bien. :-)

(*) Il a peut-être des documents OpenOffice, mais ça, c'est autre chose et l'antivirus doit mieux marcher pour ce genre de fichiers à mon avis.

Hum, prétendre qu'il suffit « simplement » de recopier son /home pour récupérer sa config, c'est pas être parano, c'est même être un peu imprudent, à mon avis.

Eh oui, quand on a été cracké, on ne peut faire confiance à pratiquement rien sur la machine crackée. Même en dehors des systèmes de fichiers, le secteur boot de chaque disque peut avoir été modifié (je crois que les Windowsiens connaissent bien ça). Dans le /home, il y a certainement des .profile, .bashrc, .zshrc, etc. et/ou un répertoire bin, ainsi que des fichiers de config divers et variés qui peuvent être mis à profit par l'attaquant pour récupérer le contrôle sur la nouvelle installation une fois que le /home aura été gentiment recopié. Lalala…

Mouais, ça a l'air super vachement cool, tout ça, mais moi je me souviens avoir lu :

Now, OpenCL runs stuff on the graphics card. I happen to know a few folks who ported fluid dynamics codes to OpenCL because you get a factor ~100 more performance that way. Despite that, they had pretty mixed feelings, because the results they got changed with every update of the graphics card driver. Um… yeah. It's not trivial to run accurate numerical code on floating point precision in the first place, and graphics cards sometimes, you know, do funny things. In rendering, it means the color value of some pixels might come out odd and often we can just shrug it off. In numerics - it means you're screwed.

(http://forum.flightgear.org/viewtopic.php?p=270463#p270463)

La vitesse, c'est bien. Avoir des résultats corrects et reproductibles, c'est souvent mieux… (après, je n'ai pas fait ces expériences moi-même ; je ne fais que relater ce que j'ai ouï dire ;-)

Exemple tout simple : supposons que tu souhaites tout couper (« killer ») à partir de la position courante jusqu'à la fin du buffer. Il suffit de taper C-end C-w. Pas besoin de faire C-SPC avant. Pour copier le même texte : C-end M-w. Pour copier entre la position courante et une position quelconque obtenue par recherche incrémentale : C-s ... M-w, etc.

Petite précision : les commandes classiques de recherche (C-s, C-r et leurs variantes travaillant sur les regexps ESC C-s, ESC C-r) ainsi que beginning-of-buffer (C-home) et end-of-buffer (C-end) posent automatiquement une marque là où se trouvait le curseur (« point ») avant leur appel lorsqu'elles se terminent normalement (pas avec C-g). Cela dispense donc souvent de poser la marque comme première étape pour définir une région sélectionnée.

Pour le manque de puissance, si les gaz sont à fond, c'est probablement le mélange air/carburant qui n'est pas adapté à la pression atmosphérique (laquelle dépend notamment de l'altitude). Utiliser M et Shift-M ou bien la tirette rouge (pour le c172p) mentionnée dans mon message précédent. Plus la presssion atmosphérique est faible, plus le mélange doit être appauvri (tirette rouge tirée) sinon le moteur reçoit trop d'essence par rapport à l'oxygène (raréfié) qui entre. C'est expliqué dans le manuel à la section 7.7.1 (Engine control, chercher "mixture").

Notez que j'ai changé d'URL pour le manuel par rapport au message précédent : en effet, le document indiqué hier se rapporte apparemment à FG 3.0.0, mais il est très incomplet comparé à celui référencé ci-dessus (de 2010, pour FG 2.0.0, mais contenant des tutoriels très intéressants).

Il y a aussi le poids qui peut jouer, réglable via la quantité de carburant embarqué et le nombre de passagers/qté de bagages (réglables dans le menu "Fuel and payload" par exemple avec le Boeing 777-200ER). Mais je ne pense pas que ce soit prépondérant dans ton cas.

Concernant la "tower view", as-tu fait Ctrl-V ? Je ne suis pas sûr de comprendre. Pour de tous petits aérodromes, il peut être normal de démarrer dans l'herbe je pense. Mais pour la quasi-totalité de ceux que j'ai essayés dans FG, on démarre directement sur une piste goudronnée. Quel est l'aéroport ? C'est peut-être un bug.

Pour la carte, plusieurs possibilités :

• menu équipement (schématique, mais bien utile pour les atterrissages avec ILS ; mais c'est de la triche si on l'utilise pour autre chose que le relevé des fréquences de communication et données de ce type ! ;-)

• en mode multi-joueurs, une fois connecté, on peut voir son avion et les autres sur fond de carte Google Maps à l'adresse http://mpmap02.flightgear.org/ (il y a d'autres serveurs, voir "multiplayer" sur le wiki FG). C'est génial !

• projet atlas que je n'ai pas essayé.

Quelques petites précisions par rapport à hier :

• J'ai mentionné des packages Debian avec quelques patches, mais le package source concerné par ces patches est précisément celui que je n'ai pas uploadé en raison de sa taille : flightgear-data. Cependant, les patches sont contenus dans http://people.via.ecp.fr/~flo/tmp/flightgear-data/flightgear-data_2.12.1-1~frougon+deb7.0u1.debian.tar.gz et l'on peut reconstituer le package source en plaçant dans un même répertoire ce fichier, le .dsc qui va avec (disponible ici) ainsi que le tarball upstream sous un nom tel que flightgear-data_2.12.1.orig.tar.bz2 (disponible par exemple ici).

Avec ces trois fichiers, on peut décompacter le package source de la façon suivante :

  dpkg-source -x <fichier.dsc>

à effectuer dans le répertoire contenant les 3 fichiers. On obtient alors un sous-répertoire <package>-<version>. Si les Build-Depends* sont satisfaites (cf. debian/control), il suffit de lancer debuild (éventuellement avec -us et -uc) dans ce dernier pour obtenir les packages binaires générés par le package source correspondant au .dsc. Pour installer ces packages, on peut faire dpkg -i <pkg.deb> ... sous le compte root en respectant l'ordre des dépendances.

• J'ai parlé de ~ (tilde) pour sélectionner tous les moteurs et de } (3 fois) pour les magnetos. A priori, ~ est à faire avant } puisque cette dernière est documentée dans /usr/share/games/flightgear/keyboard.xml comme Increase Magneto on Selected Engine. De même, quand on augmente ou diminue les gaz avec Page Up/Down, cela s'applique au(x) moteur(s) préalablement sélectionné(s), comme on le voit très bien par exemple dans le Boeing 777-200ER en regardant bouger les leviers à droite du pilote.

• Raccourci pratique surtout au début : Shift-Echap pour recommencer.

• En effet, Tab fait la même chose que clic droit mais il me semble que certains avions affectent cette touche à une autre fonction (Boeing 777-200ER je crois).

• [ et ] pour les volets ;

• Les avions compliqués (typiquement, avions de ligne) ont souvent une fonction autostart dans le simulateur (dernier ou avant-dernier menu) qui dispense de la procédure (plus ou moins) complète de démarrage.

• On peut faire du ravitaillement en vol avec FG (entre deux avions), on peut décoller et atterrir sur un porte-avion (certains ont réussi à atterrir dessus avec un avion de ligne !! cf. youtube, porte-avion se dit carrier en anglais), il y a des montgolfières en plus des hélicos et des ballons dirigeables, une jeep, une dedeuche, des avions de la première heure, des tail draggers de la Seconde Guerre Mondiale… C'est de la balle !

Sommaire

• Installation
• Lancement
• Choix de l'aéroport
• Les trois modes de la souris
• Premier vol
• Pour aller plus loin

Bonjour,

Je ne suis pas un expert FlightGear, mais j'ai passé le cap (ainsi que mes neveux !) des premiers temps où l'on ne sait pas trop dans quel ordre aborder les différentes étapes pour pouvoir voler.

Premièrement, avant de donner quelques indications, je tiens à réfuter une affirmation lue quelques commentaires plus haut : si mes neveux de 7 et 10 ans arrivent à piloter assez correctement avec un « joypad freebox » (DragonRise USB), c'est que la maniabilité n'est pas si mauvaise que ça. En revanche, c'est vrai, j'ai dû préparer moi-même un fichier XML pour avoir un contrôle convenable avec ce joypad (qui n'est vraiment pas terrible) et j'ai également fini par modifier /usr/share/games/flightgear/mice.xml pour diminuer la sensibilité de la souris qui était bien trop élevée dans mon cas pour pouvoir contrôler décemment le c172p (Cessna, avion par défaut), faire de jolis atterrissages à peu près dans les règles, etc. J'ai posté le "driver" du joystick dans la ML flightgear-devel (https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39957.html), mais je ne crois pas qu'il ait déclenché une quelconque réaction. Les possesseurs dudit joypad doivent donc toujours se
retrousser les manches.

Avant de passer aux conseils pratiques, je tiens à dire que FG est un logiciel très intéressant, en tous cas si l'on comprend l'anglais car il y a quelques tutoriels, à commencer par le manuel officiel, qui permettent de comprendre pas mal de choses "simples" sur le fonctionnement des avions, de la radio-navigation (comment se repérer sans visibilité ni GPS, dans les appareils pas trop récents, comment atterrir sans les mains (!)…) et des procédures en vigueur (traffic patterns à l'approche d'un aéroport…).

La difficulté principale de l'apprentissage initial tient au fait qu'il y a une incroyable quantité d'appareils disponibles sur flightgear.org et que ces appareils ne sont pas tous identiques :

% ls /usr/share/games/flightgear/Aircraft | wc -l
448

Mais c'est évidemment ce qui fait une bonne partie du plaisir à explorer ce monde : comment manœuvre-t-on un hélico, comment fonctionne un ballon dirigeable (quand on prend de l'altitude, la pression extérieure diminue, donc l'enveloppe principale va avoir tendance à augmenter de volume, d'où l'intérêt des ballonnets qui permettent aussi de contrôler la position avant-arrière du centre de gravité, le pitch… lire le wiki FG), qu'y a-t-il sur le tableau de bord d'un avion de ligne (ou même du Cessna c172p) ?..

Installation

• Debian unstable : c'est dedans (version 3 !)

• Debian stable : c'était dedans avant wheezy, c'est absent de wheezy (pbs de sécu non corrigés à temps je crois). J'ai mis un backport pour wheezy de la version 2.12.0 (mis à jour jusqu'à 2.12.1) de sid en novembre ou décembre accessible avec :

deb http://people.via.ecp.fr/~flo/debian wheezy main
deb-src http://people.via.ecp.fr/~flo/debian wheezy main

Hélas, étant donné le volume du package source flightgear-data et des packages binaires qu'il produit (859 Mo au total), je n'ai pas osé l'uploader chez VIA qui héberge ces modestes pages à titre gracieux. Il faut donc se débrouiller pour installer flightgear-data 2.12.1 et ses dépendances (arch: all, donc possibilité d'utiliser directement les packages binaires officiels Debian quand la version correspond) avant de pouvoir installer flightgear depuis le dépôt susmentionné. Qqs précisions supplémentaires ici.

Ces packages sont essentiellement des backports de ce qu'il y a dans Debian unstable au moment où je les prépare, avec quelques modifications mineures indiquées dans debian/changelog et debian/patches :

• support du joypad prêté avec la Freebox (DragonRise Inc. Generic USB Joystick) ;
• souris moins sensible que par défaut ;
• raccourcis Super-F1/Ctrl-F1, Super-F2/Ctrl-F2, …, Super-F10/Ctrl-F10, pour enregistrer/restaurer 10 vues personnelles persistantes pour chaque avion (très pratique pour zoomer sur les différentes parties du tableau de bord lors de la checklist !) ;
• raccourci Ctrl-M pour la carte (à faire parfois 2 fois de suite, très bizarre) qui est sans doute par défaut dans FG 3.0, vu que c'était déjà dans le Git quand j'ai incorporé ce patch.

Ces packages sont d'abord destinés à l'usage par mes proches ; il n'y a aucune garantie de suivi régulier des MAJ chez Debian ou flightgear.org.

• Autres systèmes : je laisserai les experts se prononcer. ;-)

Lancement

On peut lancer FG en ligne de commande. Pour la première fois, on peut se contenter d'un simple :

% fgfs

On se retrouve alors à San Francisco avec un c172p. Par la suite, un programme tel que FGo! (package Debian fgo) ou FGRun (qui a segfaulté lamentablement au premier lancement dans mon cas, d'où mon passage à FGo!) est très pratique pour choisir l'aéronef, l'aéroport + parking éventuel et diverses options. Au final, fgo me lance qqch de ce genre :

% fgfs    --aircraft=c172p \
          --airport=LFPO \
          --fg-root=/usr/share/games/flightgear/ \
          --fg-scenery=/usr/share/games/flightgear/Scenery \
          --enable-terrasync \
          --terrasync-dir=/mnt/mm/flightgear-data/scenery-terrasync \
          --timeofday=noon \
          --season=summer \
          --enable-fullscreen

Shift-F10 pour le plein écran
F10 pour cacher la barre de menu

Si les performances sont mauvaises (< 15 fps environ ; cf. View → View options → Show frame rate et sa copine), aller dans View → Rendering options, mettre les shaders au minimum, désactiver le reste (laisser si possible les nuages 3D très jolis et pas si gourmands que ça, la pluie et les particules atmosphériques…).

Terrasync : c'est le composant qui télécharge automatiquement le paysage au cours du vol. D'après la dépêche LinuxFR, il serait activé par défaut dans FG 3.0. Pour ce que je connais (2.6-2.12), les options ci-dessus font l'affaire. Avec fgo, il suffit de les mettre une fois pour toutes dans le champ texte en bas de la fenêtre principale. C'est aussi configurable dans les menus une fois FG lancé, depuis la version 2.6 ou qqch comme ça.

Quand on démarre dans un endroit non encore visité, il n'y a que de l'eau, c'est normal. Si Terrasync est actif et bien configuré, il suffit d'attendre quelques minutes le temps qu'il télécharge et de faire View → Rendering options → Reload scenery ou bien relancer Flightgear au même endroit.

Choix de l'aéroport

Chaque aéroport dans le monde est identifié par un code de 4 lettres (ICAO pour International Civil Aviation Organization en anglais, OACI en français), par exemple LFPO pour Paris Orly et LFPG pour Roissy Charles-de-Gaulle. Très facile à trouver sur Wikipedia, pratique dans FG.

On peut choisir l'aéroport :

• dans la liste proposée par fgo ;
• avec l'option --airport=ICAO de fgfs ;
• dans les menus de FG.

On peut aussi démarrer à une position GPS, altitude, vitesse, orientation etc. arbitraires, voire obtenir en plein vol un lien Google Maps correspondant à la position courante (: Y m, c'est un truc de vimiste, faire : puis tabulation pour comprendre).

Les trois modes de la souris

1. Au lancement de FG, la souris est dans un mode qui permet de cliquer dans les menus et sur les instruments de bord (pour ces derniers, voir le manuel : en gros, il y a bouton gauche à gauche ou à droite du "truc" à manipuler, bouton milieu pour aller plus vite et la roulette assez souvent pour tout ce qui n'est pas une simple bascule). Appuyer sur Ctrl-C pour voir ce qui est cliquable/roulettable dans le cockpit ou sur la carlingue.

2. Si on clique avec le bouton droit, le pointeur souris change d'aspect (crosshair) pour indiquer qu'on est dans le mode qui agit sur les commandes de changement de direction (essentiellement ailerons et gouvernail, aileron/elevator et rudder en anglais). Appuyer sur V pour passer à la vue suivante et voir les ailerons et Cie se déplacer avec les mouvements de la souris. Shift-V pour revenir à la vue précédente, Ctrl-V pour revenir au cockpit quelle que soit la vue actuelle. La touche 5 ramène les commandes en position neutre.

3. Si on clique encore avec le bouton droit, le pointeur souris change d'aspect une fois de plus, signalant le troisième mode, qui permet de tourner la tête, la déplacer, changer la focale… On peut :

• déplacer la souris pour regarder dans la direction voulue ;
• utiliser la roulette pour changer la focale ;
• avec le bouton milieu enfoncé, déplacer la souris pour translater la tête dans un plan particulier ;
• avec le bouton milieu et la touche Ctrl enfoncés, même chose dans une direction orthogonale ;
• cliquer à gauche pour recentrer.

Un nouveau clic droit ramène au premier mode.

Premier vol

Autant dire tout de suite qu'on ne va pas respecter les procédures !

On va prendre le c172p (avion par défaut).

1. S : c'est le démarreur, garder appuyé le temps qu'il faut pour que le moteur démarre (la carte son doit bien aider). Si l'on démarre en altitude, il faut parfois ajuster la richesse du mélange avec M et Shift-M (ou bien roulette sur la tirette rouge en dessous des cadrans pleins d'afficheurs à LED).

2. Passer la souris en mode flight controls (numéro 2 dans la description ci-dessus) sauf si l'on pilote au clavier ou au joystick.

3. Page up : c'est pour augmenter les gaz. Je ne sais pas si c'est recommandé, mais on décolle très bien en "plein gaz". Évidemment, on les diminue avec Page down. Si l'avion part de travers avant d'avoir décollé, déplacer la souris latéralement tout en maintenant le bouton gauche enfoncé.

4. Lorsque les roues quittent le sol, démerdez vous ! ;-)

Beaucoup d'avions ont les freins "à main" (parking brakes en anglais) enclenchés au lancement de FG. Faire Shift-B pour enclencher/enlever ces freins. (B permet de freiner lorsqu'on roule)

G / Shift-G pour le train d'atterrissage (non appliquable au c172p)

Pas mal d'avions utilisent des magnetos (traduction française ?) pour le démarrage. Il faut alors faire } 3 fois de suite (left/right/both) au tout début de la procédure, avant même d'appuyer sur S.

Enfin, pour les avions ayant plusieurs moteurs, on peut les sélectionner indépendamment avec les touches correspondant à 1/2/3/4 sur un clavier qwerty. La correspondance en azerty est immonde (!/@/#… approximativement). Autrement, le plus utile est souvent ~ (tilde) pour sélectionner tous les moteurs.

Au final, certains détails et raccourcis dépendent de l'avion choisi, c'est normal. Regarder dans le menu Help (raccourcis spécifiques et souvent aide succinte) ainsi que sur le wiki.

Après le c172p, on peut essayer le f-14b très stable. Penser à faire le plein (menu à droite pour le f-14b je crois, mais menu Équipement pour la plupart des autres avions) et à réparer l'aile après un crash (menu à droite).

Pour aller plus loin

• Le manuel, très utile (notamment les tutoriels)

• Les tutoriels vidéo d'Oscar, en anglais mais facile à comprendre. Excellente ressource pour apprendre à utiliser le pilote automatique, à atterrir avec le guidage radio (ILS, VOR/DME…), etc.

• Le wiki et le forum sur flightgear.org

• http://www.navfltsm.addr.com/ par exemple pour approfondir la navigation radio (non, je ne m'y connais pas plus que ça, c'est un lien qui a été donné sur le forum et qui me semble très bien fait pour le peu que je puisse en juger).

Bon vols !

On peut manœuvrer le palonnier avec la souris en gardant le bouton gauche appuyé, lorsque la souris est en mode "contrôle de l'avion" évidemment. Il y a aussi l'option --enable-auto-coordination de fgfs ; elle améliore sans doute les virages en l'air (pour les avions, pas les hélicos !) mais n'est pas suffisante pour bien se diriger sur la piste, puisqu'on ne peut alors pas contrôler indépendamment le gouvernail et les ailerons.

Hélas, la confusion « libre » = « libre de droits » inventée par les journalistes fainéants est devenue un grand classique dès que le logiciel libre est mentionné dans les médias généralistes.

Encore récemment, cette confusion a été entretenue par le Nouvel Observateur qui, dans son numéro 2360 page 62, publie un article sur Richard Stallman où l'on « apprend » que « logiciel libre » = « logiciel libre de droits » et que GNU est un langage collaboratif !

J'ai écrit un mail détaillé à Jean-Marcel Bouguereau, responsable de la rubrique « courrier des lecteurs », le 2 février 2010 et il ne m'a toujours pas répondu (de plus, aucun errata n'a été publié à ma connaissance). Bonjour la politesse et la conscience professionnelle.

J'ai mis ma lettre sous forme de fichier PDF (pour une lecture plus agréable) ici :

http://people.via.ecp.fr/~flo/tmp/r%c3%a9ponse-NO-sur-le-log(...)

Tatata, raisonnement simpliste.

Je te fais confiance sur le facteur 10^4, et j'imagine que cela correspond au ratio de puissance (maximum légale ?) entre un émetteur 3G et un émetteur WIFI.

Mais cette puissance d'émetteur, en l'absence d'obstacles absorbant ou réfléchissant les ondes, est conservée entre 2 sphères concentriques centrées sur l'émetteur. Vu que l'aire d'une sphère de rayon r est 4˙pi˙r², on en déduit que la puissance reçue à travers une surface donnée (ici, celle du corps humain exposé) située à une distance r d'un émetteur radio est proportionnelle à 1/r².

Autrement dit, la puissance reçue (par un corps de géométrie donnée) décroît très vite à mesure que l'on s'éloigne de l'émetteur. Ou encore (version « bouteille à moitié vide ») : en supposant (ce qui fait encore débat...) que l'exposition aux ondes lorsqu'on se situe à quelques centaines de mètres d'un émetteur radio est acceptable, elle devient en revanche dramatiquement plus élevée à mesure que l'on s'en rapproche.

Dans le cas du WIFI, si tu as choisi d'utiliser cette technologie à la maison, tu te trouves à quelques mètres d'au moins un émetteur ; alors que dans le cas de l'émetteur 3G installé par Monsieur Grande-Marque-de-Téléphonie-Mobile™ qui ne t'a sans doute pas demandé ton avis, on peut espérer que l'émetteur le plus proche est éloigné d'au moins quelques centaines de mètres, voire dizaines de kilomètres. C'est évidemment faux si tu habites au dernier étage d'un immeuble avec l'antenne juste au-dessus sur le toit, mais c'est très vraisemblablement le cas de PlOp3 qui nous dit qu'il n'y a pas de maison à moins de 150 m de chez lui.

Mes 2 centimes

dar, c'est d'la bombe, baby.

[http://dar.linux.free.fr/]

La dépêche dit (en répétant gentiment le communiqué de presse d'App^Wde Michael Sweet) que « CUPS [...] restera sous licence GPL/LGPL v2 ».

Ceci laisse croire que les contributions d'Apple et autres développeurs bénéficieront aux utilisateurs de systèmes libres, dès lors qu'Apple redistribuera CUPS. Hélas, ceci est un mensonge éhonté, puisque CUPS n'est plus sous GPL/LGPL v2, mais sous une variante de ces licenses avec exception :

http://www.cups.org/articles.php?L179+I0+T+M10+P1+Q

Et pas n'importe quelle exception ! Tout développement destiné à un OS "developed and/or marketed by Apple Computer, Inc." peut être proprio, rien que ça.

Ce rachat est à mon avis une sinistre nouvelle. Il confirme mon sentiment selon lequel Apple est, parmi les gros parasites du libre, de loin le pire (en particulier, je trouve Microsoft moins fourbe : avec leur puissance financière, ils ont tendance à tout redévelopper à côté ou à acheter des boîtes qui développaient du proprio, mais je n'ai pas l'impression qu'ils parasitent directement les projets libres comme le fait Apple).

Grumpf.

Moi, j'aimais bien les dépêches cinéma...

Sniff...

Bonjour,

Dans la news, je lis qu'il faut être indulgent car les personnes en charge de l'interview sont des amateurs. Eh bien franchement, j'ai trouvé leurs questions et rebondissements sur les éléments apportés par Sam très pertinents (je précise que je suis développeur Debian).

Donc, félicitations, vous avez bien travaillé votre sujet et nous avez offert une belle interview. Merci.

PS : petit point de précision : avant l'interview, vous mentionnez rapidement apt comme logiciel permettant la légendaire bonne gestion des paquets par un système Debian. C'est certes un élément important, mais il occulte presque toujours dpkg, qui est au moins aussi important. dpkg s'occupe de la gestion bas niveau des paquets ; il s'acquitte des tâches les plus élémentaires (essentiellement l'installation, la suppression et la mise à jour de chaque paquet pris individuellement). apt intervient au niveau supérieur pour gérer une mise à jour donnée sur un ensemble de paquets.

> > Et GNOME, le bureau, s'écrit en majuscules.
> Le problème, c'est qu'un mot tout en majuscule, c'est trop marqué, dans un texte.

Dans ce cas, la bonne solution est les petites capitales (small caps). Ça se fait avec \textsc{gnome} en LaTeX, ou mieux, si vous utilisez babel avec l'option frenchb, \bsc{gnome} (\bsc, qui signifie boxed small caps, met son argument dans une boîte, pour éviter toute coupure). Mais je ne sais pas si vous pouvez faire ça avec votre chaîne de production.

[ Contexte : « Software RAID » implémenté dans le driver md de Linux ]

Pour répondre à la question, non. C'est même recommandé, afin de réduire la probabilité que les disques tombent en panne en même temps.

Si les vitesses sont très différentes, je pense que c'est le disque le plus lent qui impose la sienne lors de l'écriture (dans les situations où le cache n'est pas suffisant pour masquer ce phénomène).

Par contre, pour la lecture, il y une sorte de « load balancing » (cela dit, pas très optimisé selon le mainteneur de md) : chaque bloc de données demandé par un processus en espace utilisateur est lu sur un seul des disques, évidemment pas toujours le même (en particulier, il n'est pas comparé aux copies de ce bloc situées sur les autres disques ; si on veut les comparer pour être tranquille, chose à faire régulièrement, il y a une interface sysfs pour cela [echo check >/sys/block/md?/md/sync_action]).

Bref, pour la lecture, en principe, avoir des disques de vitesses franchement différentes ne doit pas être très pénalisant ; par contre, je pense que ça l'est pour l'écriture.

M'enfin, à moins d'avoir des besoins critiques en termes de performance disque, je n'y accorderais pas tellement d'importance. Pour la plupart de mes besoins, les performances actuelles des disques sont largement suffisantes ; je privilégie plutôt la fiabilité.

Suis-le le seul à trouver ça absurde ?

Absolument pas. Mais j'ai l'impression que nous sommes une minorité ici (suite au moinssage d'un récent post où j'ai défendu un point de vue très similaire).

L'OSI a acquis un monopole sur le terme « Open Source » en lui donnant une définition ridicule, dont l'usage en pratique se limite à remplacer le terme « libre » dans le milieu corporate, où « Open Source » est plus politiquement correct (voire un peu fashion, selon la politique de l'entreprise).

Oui, « Open Source » était à mon avis le terme le plus naturel pour désigner un logiciel dont on peut obtenir gratuitement le code source, cependant il a été approprié par l'OSI et détourné de son sens naturel (et je suis bien triste de voir régulièrement des lecteurs de LinuxFR marteler la définition de l'OSI comme si c'était parole d'évangile).