En effet, le voyage aller-retour vers Mars est particulièrement long ce qui a des conséquences biologiques et psychologiques sur l'équipage. Il est intéressant de pouvoir étudier en grandeur nature tout ceci
Ça se fait déjà, ça s'appelle Mars 500 et ça consiste à enfermer six bonshommes dans un baraquement pendant quatre mois et voir si ça se passe bien ou c'est en train de virer à Half Life. Avantages : c'est très facile à mettre en place, ça ne coûte pas grand chose et surtout, on peut intervenir si ça se passe mal. Si ton vaisseau est déjà à mi-chemin entre la Terre et Mars, c'est plus difficile.
car si on envisage un jour de coloniser d'autres planètes, il faudrait connaitre ces effets avant avec plus de précision qu'aujourd'hui. ;)
'faudrait déjà commencer à coloniser la première avant de songer à coloniser les (éventuelles) autres.
Puis l'humain sait aujourd'hui faire plus de manipulation que les robots ce qui peut être intéressant pour l'étude de Mars malgré tout.
Oui, mais il faut vraiment se rendre compte qu'en l'état actuel des choses, il n'y a vraiment rien à f..tre sur Mars ! :-) Y a pas un McDo, pas un ciné, et d'une manière générale, aucune infrastructure pour faire vivre durablement des astronautes pendant la durée d'une mission. Il faudrait que ce soit le vaisseau spatial lui-même qui serve de base au sol, avec des vivres, des systèmes de recyclage et de production d'énergie pour plusieurs mois (parce qu'on est pas dans la banlieue terrestre comme dans le cas d'Apollo) et qui soit capable de repartir de lui-même vers la Terre. Et une fois passé les 24 premières heures à forer des cailloux, nos astronautes risquent de s'ennuyer plus encore que les lofteurs d'il y a dix ans.
Je pense qu'à partir de notre époque, les vrais colons à venir seront tous des robots et que la conquête d'un milieu hostile se fera exactement comme on a construit l'ISS : en livrant, les uns à après les autres, une suite de modules successifs qui seront assemblés de manière automatisée jusqu'à ce qu'il y en ait suffisamment pour accueillir décemment une première délégation humaine, qui pourra alors prendre à sa charge le pilotage du reste de la mission et à partir de quoi tout s'accélérera.
L'usage nous montre que ce n'est pas vrai. En général, un utilisateur « vierge » de toute technologie à tendance à s'attacher sentimentalement à la première qu'il utilise. Il faut beaucoup d'ouverture d'esprit, ensuite, pour faire l'effort d'aller voir ce qui se fait à côté, spécialement si ça implique des manipulations techniques complexes et si on doit pour cela se retrouver dans une minorité.
« Y'a un russe qu'a vraiment pas eu de chance, c'est Youri Gagarine : il a fait dix-sept fois le tour de la Terre et il est retombé en U.R.S.S., ce con. » :-)
"Léviter" me semble plus proche, car le verbe "voler" implique que le véhicule est actif (entrain de ce déplacer, ou se maintenir en position) alors que atterrire et amerrire implique que le véhicule est passif.
Pas forcément : un ballon dirigeable, par exemple, est un aéronef qui peut être statique. De fait, de la même façon qu'un hydravion « amerrit » parce que ce sont ses flotteurs qui le portent, il est tout-à-fait possible d'envisager un engin spatial sous la forme d'un très grand ballon chargé de gaz et qui vienne se poser sur la haute atmosphère d'un astre quelconque (pourvu qu'il en soit doté, bien sûr).
C'est pour ça qu'au bout d'un moment, on a fini par dire « se poser », tout simplement, ce qui a l'avantage de fonctionner partout. Vive l'interopérabilité.
Si tu veux mais ça ne changera RIEN à ton problème de terminal. Le seul moyen d'empêcher sa fermeture serait de lui envoyer une séquence de code, CSI, OSC ou autres qui lui en donne explicitement l'instruction mais après avoir rapidement parcouru la liste de ces séquences et les sources de xterm hier soir, je n'ai rien vu qui ressemble de près ou de loin à cela.
En revanche, un langage de programmation tel que le C ou le Python te permettrait effectivement d'ouvrir tes propres fenêtres et de les gérer comme tu le souhaites, mais c'est un autre niveau. Sans être vraiment difficile, il faut quand même initialiser un contexte, gérer une boucle principale, etc.
Juste un petit détail : tous les commentaires ici sont munis de leur propre lien « répondre ». Comme Linuxfr.org organise les discussions en arbre, ce qui est à la fois rare et très agréable, c'est mieux si tu veilles à les utiliser. :-)
Pour le reste, il faut savoir que lorsque tu ouvres un terminal, tu n'ouvres pas un shell comme si tu ouvrais une « boîte DOS ». Tu crées en fait un véritable terminal virtuel qui s'exploite à travers une pseudo liaison série. Par défaut, le fait de lancer un xterm provoque automatiquement le lancement d'un shell qui y est relié, mais ce n'est pas nécessairement le cas. Il peut très bien rester passif jusqu'à ce qu'une application externe prenne d'elle-même l'initiative d'envoyer quelque chose vers ce port.
Cela veut dire le terminal X-Term et l'application qui tourne dedans ne sont pas du tout liés entre eux et qu'ils ne communiquent qu'à travers une sorte de pipe bidirectionnel. Donc, tu ne peux pas empêcher le xterm de se refermer puisque c'est une application distincte. Tu peux simplement agir en conséquence.
Bref, quand tu auras D6D d'être de retour dans le présent, fais-moi 6gne.
Bof, de toutes façons, à l'heure d'iPot, ça ne sert plus à rien de rester dans le présent.
D'ailleurs le chrono-télé-travail, c'est l'avenir (ou le passé, enfin c'est pas le présent, quoi).
— Même dans ce fil, reconnais que mon commentaire initial reste beaucoup plus utile que les tiens ;
— Ça fait 13 ans maintenant que je participe à ce forum et je pense modestement avoir rendu service à un certain nombre de personnes ;
— Quitte à poster pour ne rien dire, essaie au moins de relire le fil avant de poster, ça m'évitera d'avoir à me répéter et d'augmenter le niveau de bruit.
C'est ce que je dis : « -b » était approprié mais la man page Linux déclare que c'est une option GNU, et comme l'option n'était pas disponible du tout sur un des mes shells sous OpenBSD, je m'en suis tenu à ce que j'avais écrit et je ne suis pas allé voir si le LS d'AIX proposait la même option. J'aurais dû.
Essaie d'utiliser l'auto-complétion avec la touche TAB. Si le shell est propre, soit il te l'encadrera avec des guillemets ou des « quotes », soit il te mettra des anti-slashes devant les caractères à problème. Sinon, tu peux toujours essayer un « find . -inum | hexdump » ou autre éditeur hexa pour voir s'il te les affiche explicitement.
Pour dépoussiérer une franchise vieillissante, l'éditeur d'un jeu vidéo à décidé de faire subir un viol à son héroïne. […]
La miss est plaquée au sol ; les mains attachées dans le dos (…). […]
Le tollé couve lentement mais sûrement et commence à se propager. Heureusement, c'est la fin du vendredi et le code source du jeu n'est pas disponible.
Par contre, les complotistes vont pouvoir passer le weekend à se demander si des "ultra-féministes" - n'ayons pas peu des mots - ne sont pas en train de
faire un raid dans cet univers informatique qui semblait si tranquille.
D'un autre côté, si c'est Lara Croft qui ligote un type au sol et qui le viole, ça ferait encore plus de ventes, je crois…
Ah, moi c'est l'inverse, c'est le logo « corporate » que je préfère. Et le dernier, au contraire, me fait l'effet d'une application X-Window mal configurée qui se rabattrait sur la fonte par défaut faute de trouver la bonne. Il est bien possible, malgré tout, que ce logo ait fait l'objet d'un vrai travail et que les caractères aient été dessinés individuellement mais, malgré tout, j'ai l'impression de voir la fonte Arial.
Je pense qu'un tel logo se fait en trois minutes sous Excel, carreaux compris. :-)
Il y a des esprits chagrins qui lui reprochent d'avoir mélangé C et C++ mais en réalité, il fait le tour de ce qui est réellement commun aux deux langages jusqu'au chapitre 8, à partir duquel le reste est C++ only. Je le trouve exhaustif, bien structuré, il est en français et, cerise sur le gâteau, en GFDL.
En principe, toutefois, on ne peut rien reprocher à un tel câble s'il n'est pas frappé du logo USB officiel, et il y a effectivement des chances pour qu'il ne le soit pas.
Un journal qui parle de langage C, qui tente de résoudre un cas de figure technique et qui finit en troll politico-sexiste dès le cinquième niveau d'imbrication : pas de doute, on est bien sur DLFP. Tout va bien. :-)
C'est une très bonne chose en soi ! Mais il est important de le faire uniquement pour les cas non définis par la norme ou alors explicitement marqués comme indéfinis par elle. Et en l'occurrence, dans le dernier draft de C99 (n1256.pdf), section § 6.7.2.1, on lit :
6.7.2.1 Structure and union specifiers
…
13
Within a structure object, the non-bit-field members and the units in which bit-fields
reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a
bit-field, then to the unit in which it resides), and vice versa. There may be unnamed
padding within a structure object, but not at its beginning.
Donc, tu es sûr que l'adresse du premier élément d'une structure sera toujours l'adresse de la structure elle-même avec tout compilateur qui se respecte (et qui, surtout, respecte la norme), ce qui permet d'échafauder de façon tout-à-fait officielle et sans warning des montages comme celui de XEvent.
Ça s'explique également par le fait que le padding est généralement utilisé à des fins d'alignement et que, si tu dois aligner un membre, alors tu auras besoin d'aligner de la même façon la structure entière d'une manière générale.
Oui mais justement, même pour quelques octets, c'est plus simple et plus efficace : en fait, la méthode des décalages telle que tu l'as écrite n'est intéressante qu'à partir du moment où ta file tient sur un seul entier (ou que les mots que tu empiles ne sont pas multiples de huit bits). Dès que tu dépasses 8 octets (si l'on considère le cas du long long), alors tu es obligé d'utiliser plusieurs variables consécutives.
De là, soit tu utilises une boucle et un pointeur, ce qui t'oblige à déclarer des variables supplémentaires, soit tu gères manuellement chacun de tes registres en contrôlant à chaque fois s'il est concerné en fonction de la valeur de « count ». Tu gagnes quatre octets de RAM mais tu perds 64 octets de ROM. Ce genre de chose est effectivement à prendre en compte dans le cas de micro-contrôleurs, mais pas sur PC. Pas seulement parce que la quantité de RAM disponible est considérable, mais surtout parce que c'est la même dans les deux cas.
C'est vrai, mais ça te permet en revanche de gérer une file d'une longueur arbitraire sans avoir à décaler tout son contenu. Avec 4 octets, la différence est subtile, avec 4096 elle devient beaucoup plus nette.
[^] # Re: La fin d'une époque
Posté par Obsidian . En réponse au journal Neil Armstrong bronsonisé. Évalué à 4.
Ben, justement, c'est « pas grave ». :-)
(Mauvaise blague, je sors →[]).
[^] # Re: La fin d'une époque
Posté par Obsidian . En réponse au journal Neil Armstrong bronsonisé. Évalué à 7.
Ça se fait déjà, ça s'appelle Mars 500 et ça consiste à enfermer six bonshommes dans un baraquement pendant quatre mois et voir si ça se passe bien ou c'est en train de virer à Half Life. Avantages : c'est très facile à mettre en place, ça ne coûte pas grand chose et surtout, on peut intervenir si ça se passe mal. Si ton vaisseau est déjà à mi-chemin entre la Terre et Mars, c'est plus difficile.
'faudrait déjà commencer à coloniser la première avant de songer à coloniser les (éventuelles) autres.
Oui, mais il faut vraiment se rendre compte qu'en l'état actuel des choses, il n'y a vraiment rien à f..tre sur Mars ! :-) Y a pas un McDo, pas un ciné, et d'une manière générale, aucune infrastructure pour faire vivre durablement des astronautes pendant la durée d'une mission. Il faudrait que ce soit le vaisseau spatial lui-même qui serve de base au sol, avec des vivres, des systèmes de recyclage et de production d'énergie pour plusieurs mois (parce qu'on est pas dans la banlieue terrestre comme dans le cas d'Apollo) et qui soit capable de repartir de lui-même vers la Terre. Et une fois passé les 24 premières heures à forer des cailloux, nos astronautes risquent de s'ennuyer plus encore que les lofteurs d'il y a dix ans.
Je pense qu'à partir de notre époque, les vrais colons à venir seront tous des robots et que la conquête d'un milieu hostile se fera exactement comme on a construit l'ISS : en livrant, les uns à après les autres, une suite de modules successifs qui seront assemblés de manière automatisée jusqu'à ce qu'il y en ait suffisamment pour accueillir décemment une première délégation humaine, qui pourra alors prendre à sa charge le pilotage du reste de la mission et à partir de quoi tout s'accélérera.
[^] # Re: hum
Posté par Obsidian . En réponse au journal Est-ce que la popularité d'Android permettra à Linux de progresser en adoption ?. Évalué à 10.
L'usage nous montre que ce n'est pas vrai. En général, un utilisateur « vierge » de toute technologie à tendance à s'attacher sentimentalement à la première qu'il utilise. Il faut beaucoup d'ouverture d'esprit, ensuite, pour faire l'effort d'aller voir ce qui se fait à côté, spécialement si ça implique des manipulations techniques complexes et si on doit pour cela se retrouver dans une minorité.
Ah… la paçion ! :-)
[^] # Re: La fin d'une époque
Posté par Obsidian . En réponse au journal Neil Armstrong bronsonisé. Évalué à 10.
« Y'a un russe qu'a vraiment pas eu de chance, c'est Youri Gagarine : il a fait dix-sept fois le tour de la Terre et il est retombé en U.R.S.S., ce con. » :-)
(© Coluche)
[^] # Re: Complications inutiles
Posté par Obsidian . En réponse au journal Neil Armstrong bronsonisé. Évalué à 3.
Pas forcément : un ballon dirigeable, par exemple, est un aéronef qui peut être statique. De fait, de la même façon qu'un hydravion « amerrit » parce que ce sont ses flotteurs qui le portent, il est tout-à-fait possible d'envisager un engin spatial sous la forme d'un très grand ballon chargé de gaz et qui vienne se poser sur la haute atmosphère d'un astre quelconque (pourvu qu'il en soit doté, bien sûr).
[^] # Re: Complications inutiles
Posté par Obsidian . En réponse au journal Neil Armstrong bronsonisé. Évalué à 10.
« Ætherrir ? » :-)
[^] # Re: Complications inutiles
Posté par Obsidian . En réponse au journal Neil Armstrong bronsonisé. Évalué à 6.
Ça s'appelle « voler », en fait. :-)
[^] # Re: Complications inutiles
Posté par Obsidian . En réponse au journal Neil Armstrong bronsonisé. Évalué à 9.
C'est pour ça qu'au bout d'un moment, on a fini par dire « se poser », tout simplement, ce qui a l'avantage de fonctionner partout. Vive l'interopérabilité.
[^] # Re: Re :
Posté par Obsidian . En réponse au message interception de fermeture de fenêtre. Évalué à 5.
Si tu veux mais ça ne changera RIEN à ton problème de terminal. Le seul moyen d'empêcher sa fermeture serait de lui envoyer une séquence de code, CSI, OSC ou autres qui lui en donne explicitement l'instruction mais après avoir rapidement parcouru la liste de ces séquences et les sources de xterm hier soir, je n'ai rien vu qui ressemble de près ou de loin à cela.
En revanche, un langage de programmation tel que le C ou le Python te permettrait effectivement d'ouvrir tes propres fenêtres et de les gérer comme tu le souhaites, mais c'est un autre niveau. Sans être vraiment difficile, il faut quand même initialiser un contexte, gérer une boucle principale, etc.
[^] # Re: Re :
Posté par Obsidian . En réponse au message interception de fermeture de fenêtre. Évalué à 4.
Juste un petit détail : tous les commentaires ici sont munis de leur propre lien « répondre ». Comme Linuxfr.org organise les discussions en arbre, ce qui est à la fois rare et très agréable, c'est mieux si tu veilles à les utiliser. :-)
Pour le reste, il faut savoir que lorsque tu ouvres un terminal, tu n'ouvres pas un shell comme si tu ouvrais une « boîte DOS ». Tu crées en fait un véritable terminal virtuel qui s'exploite à travers une pseudo liaison série. Par défaut, le fait de lancer un xterm provoque automatiquement le lancement d'un shell qui y est relié, mais ce n'est pas nécessairement le cas. Il peut très bien rester passif jusqu'à ce qu'une application externe prenne d'elle-même l'initiative d'envoyer quelque chose vers ce port.
Cela veut dire le terminal X-Term et l'application qui tourne dedans ne sont pas du tout liés entre eux et qu'ils ne communiquent qu'à travers une sorte de pipe bidirectionnel. Donc, tu ne peux pas empêcher le xterm de se refermer puisque c'est une application distincte. Tu peux simplement agir en conséquence.
[^] # Re: L'auto-hébergement d'amateur, ce fléau
Posté par Obsidian . En réponse au journal Newton Adventure la soluce 1/6: la terrible jungle. Évalué à 2.
Bof, de toutes façons, à l'heure d'iPot, ça ne sert plus à rien de rester dans le présent.
D'ailleurs le chrono-télé-travail, c'est l'avenir (ou le passé, enfin c'est pas le présent, quoi).
→[].
[^] # Re: caractères bizare dans le nom de fichier ?
Posté par Obsidian . En réponse au message Copier un fichier qui "n'existe pas". Évalué à 7.
Bon, puisqu'on est vendredi :
— Même dans ce fil, reconnais que mon commentaire initial reste beaucoup plus utile que les tiens ;
— Ça fait 13 ans maintenant que je participe à ce forum et je pense modestement avoir rendu service à un certain nombre de personnes ;
— Quitte à poster pour ne rien dire, essaie au moins de relire le fil avant de poster, ça m'évitera d'avoir à me répéter et d'augmenter le niveau de bruit.
Allez zou ! →[].
[^] # Re: caractères bizare dans le nom de fichier ?
Posté par Obsidian . En réponse au message Copier un fichier qui "n'existe pas". Évalué à 1.
C'est ce que je dis : « -b » était approprié mais la man page Linux déclare que c'est une option GNU, et comme l'option n'était pas disponible du tout sur un des mes shells sous OpenBSD, je m'en suis tenu à ce que j'avais écrit et je ne suis pas allé voir si le LS d'AIX proposait la même option. J'aurais dû.
[^] # Re: caractères bizare dans le nom de fichier ?
Posté par Obsidian . En réponse au message Copier un fichier qui "n'existe pas". Évalué à 2.
Exact. C'est écrit « OPTIONS GNU » dans les man pages linux et ça ne marche pas sous OpenBSD, donc je n'étais pas allé chercher plus loin.
[^] # Re: caractères bizare dans le nom de fichier ?
Posté par Obsidian . En réponse au message Copier un fichier qui "n'existe pas". Évalué à 4.
Essaie d'utiliser l'auto-complétion avec la touche TAB. Si le shell est propre, soit il te l'encadrera avec des guillemets ou des « quotes », soit il te mettra des anti-slashes devant les caractères à problème. Sinon, tu peux toujours essayer un « find . -inum | hexdump » ou autre éditeur hexa pour voir s'il te les affiche explicitement.
[^] # Re: Ça suffit maintenant
Posté par Obsidian . En réponse au journal Il n'y a pas que le sexisme des linuxiens qui fait débat. Évalué à 3.
Envoie un patch.
# Changeons le thème
Posté par Obsidian . En réponse au journal Il n'y a pas que le sexisme des linuxiens qui fait débat. Évalué à 10.
D'un autre côté, si c'est Lara Croft qui ligote un type au sol et qui le viole, ça ferait encore plus de ventes, je crois…
→[]
[^] # Re: Plagiat évident !!!!!
Posté par Obsidian . En réponse au journal Nouveau logo MS. Évalué à 2.
Ah, moi c'est l'inverse, c'est le logo « corporate » que je préfère. Et le dernier, au contraire, me fait l'effet d'une application X-Window mal configurée qui se rabattrait sur la fonte par défaut faute de trouver la bonne. Il est bien possible, malgré tout, que ce logo ait fait l'objet d'un vrai travail et que les caractères aient été dessinés individuellement mais, malgré tout, j'ai l'impression de voir la fonte Arial.
Je pense qu'un tel logo se fait en trois minutes sous Excel, carreaux compris. :-)
# Par d'erreur…
Posté par Obsidian . En réponse au journal Nouveau logo MS. Évalué à 7.
Moi je trouve que c'est surtout un plagiat de ceci :-)
[^] # Re: Que pensez-vous de…
Posté par Obsidian . En réponse au message Recherche bonne source pour apprendre le C++. Évalué à 3.
Moi j'aime beaucoup le cours de Christian Casteyde : http://casteyde.christian.free.fr/cpp/cours/online/book1.html
Il y a des esprits chagrins qui lui reprochent d'avoir mélangé C et C++ mais en réalité, il fait le tour de ce qui est réellement commun aux deux langages jusqu'au chapitre 8, à partir duquel le reste est C++ only. Je le trouve exhaustif, bien structuré, il est en français et, cerise sur le gâteau, en GFDL.
[^] # Re: cable ordinaire
Posté par Obsidian . En réponse au message Cable micro-usb pour smartphone. Évalué à 5.
En principe, toutefois, on ne peut rien reprocher à un tel câble s'il n'est pas frappé du logo USB officiel, et il y a effectivement des chances pour qu'il ne le soit pas.
[^] # Re: compteur ?
Posté par Obsidian . En réponse au journal Parlons C, parlons pipe !. Évalué à 5.
Un journal qui parle de langage C, qui tente de résoudre un cas de figure technique et qui finit en troll politico-sexiste dès le cinquième niveau d'imbrication : pas de doute, on est bien sur DLFP. Tout va bien. :-)
[^] # Re: ça marche !
Posté par Obsidian . En réponse au journal Et Dieu inventa le soutien gorge !. Évalué à 3.
C'est une très bonne chose en soi ! Mais il est important de le faire uniquement pour les cas non définis par la norme ou alors explicitement marqués comme indéfinis par elle. Et en l'occurrence, dans le dernier draft de C99 (n1256.pdf), section § 6.7.2.1, on lit :
Donc, tu es sûr que l'adresse du premier élément d'une structure sera toujours l'adresse de la structure elle-même avec tout compilateur qui se respecte (et qui, surtout, respecte la norme), ce qui permet d'échafauder de façon tout-à-fait officielle et sans warning des montages comme celui de XEvent.
Ça s'explique également par le fait que le padding est généralement utilisé à des fins d'alignement et que, si tu dois aligner un membre, alors tu auras besoin d'aligner de la même façon la structure entière d'une manière générale.
[^] # Re: compteur ?
Posté par Obsidian . En réponse au journal Parlons C, parlons pipe !. Évalué à 2.
Oui mais justement, même pour quelques octets, c'est plus simple et plus efficace : en fait, la méthode des décalages telle que tu l'as écrite n'est intéressante qu'à partir du moment où ta file tient sur un seul entier (ou que les mots que tu empiles ne sont pas multiples de huit bits). Dès que tu dépasses 8 octets (si l'on considère le cas du long long), alors tu es obligé d'utiliser plusieurs variables consécutives.
De là, soit tu utilises une boucle et un pointeur, ce qui t'oblige à déclarer des variables supplémentaires, soit tu gères manuellement chacun de tes registres en contrôlant à chaque fois s'il est concerné en fonction de la valeur de « count ». Tu gagnes quatre octets de RAM mais tu perds 64 octets de ROM. Ce genre de chose est effectivement à prendre en compte dans le cas de micro-contrôleurs, mais pas sur PC. Pas seulement parce que la quantité de RAM disponible est considérable, mais surtout parce que c'est la même dans les deux cas.
[^] # Re: compteur ?
Posté par Obsidian . En réponse au journal Parlons C, parlons pipe !. Évalué à 1.
C'est vrai, mais ça te permet en revanche de gérer une file d'une longueur arbitraire sans avoir à décaler tout son contenu. Avec 4 octets, la différence est subtile, avec 4096 elle devient beaucoup plus nette.