Le truc d'une méga-tempête solaire, c'est que c'est un événement bref mais intense, et que ça induit des courants (intenses donc) dans les matériaux conducteurs branchés en circuit. Autrement dit, ça brûlera les composants électroniques (et les matériels électriques) sous tension et seulement ceux-là (bon, je suppose que le champ magnétique peut aussi effacer des disques durs éteints et débranchés)au moment de la tempête, qui peut durer de quelques secondes à quelques heures, mais pas plus (ne serait-ce que pour des raisons astronomiques : une tempête solaire est un événement localisé spatialement, et la Terre est en mouvement, donc même dans le cas d'un faisceau continu, elle passerait à travers).
Donc il n'est pas nécessaire d'avoir des composants résistants si on ne les utilise pas au moment de la tempête, et vu que c'est un événement imprévisible, la seule façon de s'en prémunir serait de les utiliser en permanence. Ce qui est difficile, au vu du besoin permanent de puissance de calcul.
je crois pas qu'elle ai eu de mise a jour Philae
Philae (l'atterrisseur) n'a été sous tension que peu de temps. Rosetta a été sous tension tout du long, mais dans un but d'économie d'énergie, Philae n'a été mis sous tension qu'à l'approche de la comète 67P. Ceci dit, ton commentaire s'applique si on prend en compte Rosetta et non Philae.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Oui et non. Le problème, c'est que dans l'espace, tu as tout un paquet de flux de particules chargées, qui causent des erreurs dans les composants électroniques. Notamment, ça interdirait l'utilisation de l'architecture x86 (c'est du conditionnel, je ne fais que répéter ce que j'ai lu, et si quelqu'un peut sourcer, je lui en saurais gré)
La plus part n'ont jamais approché les normes médicales ou d'aéronautique, pour affirmer cela.
On pet difficilement comparer ce qui n'est pas comparable… Le matériel médical comme aéronautique, c'est 100 ans d'expérience, des millions de répétitions de chaque procédure (alors que chaque voyage spatial est spécifique), des procédures de déclaration d'événements indésirables, et surtout, quand ça foire, tu peux analyser les débris/les cadavres. Quand une sonde foire son atterrissage sur Mars, bon courage rien que pour analyser ce qui a cloché !
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Honnêtement, que Google and co. fassent de l'évasion fiscale, c'est un problème entre eux et Bercy. Ça me pose beaucoup moins problème que l'utilisation qu'ils font de mes données, qui est, elle, un problème tout à fait différent.
J'ai l'impression que s'ils rentrent dans les clous au niveau fiscal ils deviendront d'un coup de gentils bisounours d'un point de vue médiatique. Ce n'est pas le cas, et le problème vient plus de leur activité de surveillance (même "bienveillante") que de leur non-paiement des impôts.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Sur Arch, le principal problème est généralement entre la chaise et le clavier. Et si tu casses sans arrêt ton Arch, interroge-toi sur tes propres pratiques :
Si tu utilises l'option --force en routine, il y a un problème.
Si tu utilises l'option --force dans n'importe quel contexte, il y a probablement un problème.
Si tu utilises l'option --sucre de yaourt pour tes mises à jour, il y a un problème vu que c'est un alias de (entre autres) --force.
Mets archlinux.org (ou même .fr) dans tes flux RSS et oublie-le. Chez moi, il est dans mes flux RSS, 9 matins sur 10 il n'a rien de nouveau et je le vois en un coup d’œil en lisant le dernier XKCD, un jour sur 10 il y a une intervention manuelle requise et là encore, 3 fois sur 4 elle ne me concerne pas. Quand une intervention manuelle est requise, elle est tellement détaillée qu'il est difficile de se planter.
Honnêtement, en 3 ans d'utilisation d'Arch, j'ai eu 2 cassages complets. Un était dû à la bronsonisation de mon disque dur (j'avais un backup), l'autre à une ISO corrompue lors de la réinstall (ma faute, j'aurais dû vérifier le checksum). Au final, j'ai retéléchargé une archive propre et ça s'est installé en 20 minutes, lecture de la doc comprise (ok je triche un peu, je l'avais déjà lue une première fois pour installer mon ISO corrompue).
Bon après, c'est vrai que c'est facile de casser son Arch. En root, si on suit pas la doc ou qu'on fait n'importe quoi, on a vite fait de casser un truc. D'où l'intérêt de lire les bonnes pratiques et d'y coller. Arch est relativement stable, à l'utilisateur près.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
En fait, ça crée un nouveau fichier nommé ls avec comme contenu l'unique ligne de code entre guillemets, du coup, quand on appellera la commande ls, ça aura pour seul effet d'afficher le contenu du fichier cat /challenge/binary/binary1/.passwd. Pourquoi on fait ça ? Je ne le sais pas, ça ne semble pas permettre une élévation de droits en soi. Peut-être que ça sert à contourner une limitation autre, mais dans ce cas autant appeler directement cat. Quoi qu'il en soit, ça ne change pas ma conclusion : n'exécute pas ces commandes (ou dans une machine virtuelle jetable :P).
(je voulais éditer mon commentaire mais pas eu le temps, d'où l'auto-réponse)
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Je vais faire court : n'exécute pas ces commandes, ça pue le soft malveillant.
rm –rf ./ls
Ça supprime le fichier ls dans le répertoire courant. Si tu te trouves dans /bin, ls est un binaire essentiel, que tu appelles dans tous les cas où tu veux lister les fichiers d'un répertoire (y compris dans un paquet de scripts shell que tu n'as pas écrits toi-même). Si tu n'es pas dans /bin, ça ne trouvera pas le fichier et ça te retournera une erreur.
On lit le fichier /challenge/binary/binary1/.passwd et on colle son contenu dans un nouveau fichier appelé ls, qui se situe précisément à l'endroit où a été supprimé le fichier ls précédent. Pourquoi on fait ça ? En effet, on pourrait tout à fait, en théorie, modifier le fichier sans le supprimer avant. Sauf que c'est une modification du fichier et qu'on n'a pas les droits pour ce faire sans être root. Alors que si on supprime un fichier appartenant à root, rm affichera simplement une demande de confirmation, qu'on force via l'utilisation de -f à la ligne précédente. Ainsi, on a remplacé un binaire très fréquemment utilisé, protégé par le système de droits, par notre binaire à nous, en contournant le système de droits.
chmod+x ./ls
On a notre binaire, mais il n'est pas exécutable. Qu'à celà ne tienne ! On le rend exécutable. Comme on a créé le binaire nous-même, on en est propriétaire : on peut modifier les droits dessus. Tout le monde peut donc désormais exécuter le binaire pourri qu'on a collé sur notre disque, et pire : tout le monde l'appellera de fait quand il croira appeler la commande ls, commande innocente s'il en est.
cd ~
pwd
On retourne dans notre dossier /home. On ne remonte pas d'un cran : on va dans le répertoire personnel de l'utilisateur courant. pwd sert à vérifier qu'on est dans le /home de l'utilisateur courant, si on en doutait.
./binary1
On exécute binary1. Rien que cette ligne devrait te mettre la puce à l'oreille : tu es en présence d'un programme exécutable, dont tu ne sais rien. Cette ligne l'exécute, tout simplement. Ce que fait binary1 ? Je n'en sais strictement rien, c'est un binaire. Mais je n'irais pas le tester.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Ben ca valide
Posté par Liorel . En réponse au journal L'astronomie à la portée de tous : Philae. Évalué à 2.
Le truc d'une méga-tempête solaire, c'est que c'est un événement bref mais intense, et que ça induit des courants (intenses donc) dans les matériaux conducteurs branchés en circuit. Autrement dit, ça brûlera les composants électroniques (et les matériels électriques) sous tension et seulement ceux-là (bon, je suppose que le champ magnétique peut aussi effacer des disques durs éteints et débranchés)au moment de la tempête, qui peut durer de quelques secondes à quelques heures, mais pas plus (ne serait-ce que pour des raisons astronomiques : une tempête solaire est un événement localisé spatialement, et la Terre est en mouvement, donc même dans le cas d'un faisceau continu, elle passerait à travers).
Donc il n'est pas nécessaire d'avoir des composants résistants si on ne les utilise pas au moment de la tempête, et vu que c'est un événement imprévisible, la seule façon de s'en prémunir serait de les utiliser en permanence. Ce qui est difficile, au vu du besoin permanent de puissance de calcul.
Philae (l'atterrisseur) n'a été sous tension que peu de temps. Rosetta a été sous tension tout du long, mais dans un but d'économie d'énergie, Philae n'a été mis sous tension qu'à l'approche de la comète 67P. Ceci dit, ton commentaire s'applique si on prend en compte Rosetta et non Philae.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: But de l'exploration spatiale
Posté par Liorel . En réponse au journal L'astronomie à la portée de tous : Philae. Évalué à 5.
Oui et non. Le problème, c'est que dans l'espace, tu as tout un paquet de flux de particules chargées, qui causent des erreurs dans les composants électroniques. Notamment, ça interdirait l'utilisation de l'architecture x86 (c'est du conditionnel, je ne fais que répéter ce que j'ai lu, et si quelqu'un peut sourcer, je lui en saurais gré)
On pet difficilement comparer ce qui n'est pas comparable… Le matériel médical comme aéronautique, c'est 100 ans d'expérience, des millions de répétitions de chaque procédure (alors que chaque voyage spatial est spécifique), des procédures de déclaration d'événements indésirables, et surtout, quand ça foire, tu peux analyser les débris/les cadavres. Quand une sonde foire son atterrissage sur Mars, bon courage rien que pour analyser ce qui a cloché !
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Rolling release et Chakra Linux
Posté par Liorel . En réponse au journal Une idée de distribution Linux. Évalué à 1.
Et si tu as peur de balancer ton adresse mail dans la nature, les flux RSS c'est le bien.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
# Oui, et ?
Posté par Liorel . En réponse au journal "Comment les multinationales (y compris françaises) font de l’évasion fiscale au Luxembourg". Évalué à -10.
Honnêtement, que Google and co. fassent de l'évasion fiscale, c'est un problème entre eux et Bercy. Ça me pose beaucoup moins problème que l'utilisation qu'ils font de mes données, qui est, elle, un problème tout à fait différent.
J'ai l'impression que s'ils rentrent dans les clous au niveau fiscal ils deviendront d'un coup de gentils bisounours d'un point de vue médiatique. Ce n'est pas le cas, et le problème vient plus de leur activité de surveillance (même "bienveillante") que de leur non-paiement des impôts.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Rolling release et Chakra Linux
Posté par Liorel . En réponse au journal Une idée de distribution Linux. Évalué à -1.
Sur Arch, le principal problème est généralement entre la chaise et le clavier. Et si tu casses sans arrêt ton Arch, interroge-toi sur tes propres pratiques :
--forceen routine, il y a un problème.--forcedans n'importe quel contexte, il y a probablement un problème.--sucrede yaourt pour tes mises à jour, il y a un problème vu que c'est un alias de (entre autres)--force.Honnêtement, en 3 ans d'utilisation d'Arch, j'ai eu 2 cassages complets. Un était dû à la bronsonisation de mon disque dur (j'avais un backup), l'autre à une ISO corrompue lors de la réinstall (ma faute, j'aurais dû vérifier le checksum). Au final, j'ai retéléchargé une archive propre et ça s'est installé en 20 minutes, lecture de la doc comprise (ok je triche un peu, je l'avais déjà lue une première fois pour installer mon ISO corrompue).
Bon après, c'est vrai que c'est facile de casser son Arch. En root, si on suit pas la doc ou qu'on fait n'importe quoi, on a vite fait de casser un truc. D'où l'intérêt de lire les bonnes pratiques et d'y coller. Arch est relativement stable, à l'utilisateur près.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: N'exécute pas ces commandes
Posté par Liorel . En réponse au message questions sur differentes commandes. Évalué à 3.
Je me suis planté dans l'interprétation de la ligne
En fait, ça crée un nouveau fichier nommé
lsavec comme contenu l'unique ligne de code entre guillemets, du coup, quand on appellera la commandels, ça aura pour seul effet d'afficher le contenu du fichiercat /challenge/binary/binary1/.passwd. Pourquoi on fait ça ? Je ne le sais pas, ça ne semble pas permettre une élévation de droits en soi. Peut-être que ça sert à contourner une limitation autre, mais dans ce cas autant appeler directementcat. Quoi qu'il en soit, ça ne change pas ma conclusion : n'exécute pas ces commandes (ou dans une machine virtuelle jetable :P).(je voulais éditer mon commentaire mais pas eu le temps, d'où l'auto-réponse)
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # N'exécute pas ces commandes
Posté par Liorel . En réponse au message questions sur differentes commandes. Évalué à 5.
Je vais faire court : n'exécute pas ces commandes, ça pue le soft malveillant.
Ça supprime le fichier
lsdans le répertoire courant. Si tu te trouves dans/bin,lsest un binaire essentiel, que tu appelles dans tous les cas où tu veux lister les fichiers d'un répertoire (y compris dans un paquet de scripts shell que tu n'as pas écrits toi-même). Si tu n'es pas dans/bin, ça ne trouvera pas le fichier et ça te retournera une erreur.On lit le fichier
/challenge/binary/binary1/.passwdet on colle son contenu dans un nouveau fichier appeléls, qui se situe précisément à l'endroit où a été supprimé le fichierlsprécédent. Pourquoi on fait ça ? En effet, on pourrait tout à fait, en théorie, modifier le fichier sans le supprimer avant. Sauf que c'est une modification du fichier et qu'on n'a pas les droits pour ce faire sans être root. Alors que si on supprime un fichier appartenant à root,rmaffichera simplement une demande de confirmation, qu'on force via l'utilisation de -f à la ligne précédente. Ainsi, on a remplacé un binaire très fréquemment utilisé, protégé par le système de droits, par notre binaire à nous, en contournant le système de droits.On a notre binaire, mais il n'est pas exécutable. Qu'à celà ne tienne ! On le rend exécutable. Comme on a créé le binaire nous-même, on en est propriétaire : on peut modifier les droits dessus. Tout le monde peut donc désormais exécuter le binaire pourri qu'on a collé sur notre disque, et pire : tout le monde l'appellera de fait quand il croira appeler la commande
ls, commande innocente s'il en est.On retourne dans notre dossier /home. On ne remonte pas d'un cran : on va dans le répertoire personnel de l'utilisateur courant.
pwdsert à vérifier qu'on est dans le /home de l'utilisateur courant, si on en doutait.On exécute
binary1. Rien que cette ligne devrait te mettre la puce à l'oreille : tu es en présence d'un programme exécutable, dont tu ne sais rien. Cette ligne l'exécute, tout simplement. Ce que faitbinary1? Je n'en sais strictement rien, c'est un binaire. Mais je n'irais pas le tester.Ça, ce sont les sources. Le mouton que tu veux est dedans.