samo a écrit 114 commentaires

Comment fais-tu lorsque tu dois gerer un repertoire plein de .deb (qui dependent les uns des autres, mais souvent avec un deb "maitre" qu'il suffirait d'installer car les autres en dependent) comme par exemple le rep DEBS/ contenu dans le .tgz de l'install de Libroffice ?
Avec ma methode ce serait :
sudo addfiledeb DEBS
sudo aptitude install libroffice4.2
sudo delfiledeb DEBS

Mais avec gdebi je pense qu'il faut installer tous les debs les uns apres les autres, et en reflechissant soi-meme a l'ordre dans lequel l'effectuer pour qu'il n'y ait pas de pb de dependances.

Tu avais raison, dans l'env du ssh -tX il manquait la partie :

GTK_IM_MODULE=uim

Maintenant ca marche nickel.
Pour info, j'ai eu la flemme de regarder directement sur le gros ordinateur, alors j'ai tout fait par le ssh.
Pour l'env par ssh, j'ai simplement tape

env | sort > ~/remotenv

Pour l'env en local, je me suis souvenu que skype tournait sur le gros ordi, donc j'ai fait

cat /proc/$(pidof skype)/environ > ~/localenv.unsorted

puis il a fallu transformer les caracteres bizarres de ce fichier en retours a la ligne, ce que j'ai fait sous vim (en utilisant 'ctrl-v y' pour copier le caractere special, puis 'ctr-r "' en mode commande pour le copier dans la commande vim, en l'occurence de la forme :%s/^@/^M/g)
puis une fois la modif enregistree :

cat localenv.unsorted | sort > localenv

Ensuite j'ai pu visualiser tranquillement les differences :

vimdiff localenv remotenv

Merci !

Padawan, Padumoor non plus tiens donc !
J'dis ça parce que ma note du dessus vaut -1, là :)

C'est pas moi qui ai oublié la majuscule du nom propre à la base !! :)
Manque de rigueur et d'humour tout ça (ma note du commentaire de dessus vaut -1 au moment ou j'écris ces lignes).

J'aime le principe de peter, c'est les gens autour de moi qui n'aiment pas.
->[]

J'ai omis le fait que je parlais du système tonale. Cependant, j'insiste il n'y a pas de concurrence dans le milieu.

Bah, les tablatures c'est la plupart du temps pour du tout-à-fait tonal.
Les neumes, il y en a beaucoup pour du tonal aussi, vu que le tonal vient de la liturgie chantée (et un chant liturgique nous a donné le nom des notes).
Et j'en passe.

Et la notation "classique" est utilisée presque tout le temps même quand c'est de l'atonal. (c'est un "langage" standard de fait)

En réalité la notation "classique" est impropre a la musique rigoureusement tonale, car il est malaisé de faire figurer les indications précises sur la fréquence des notes pour faire respecter les rapports accoustiques fondamentaux (ce qui se rapproche du tempérament pythagoricien).

Bon évidemment je suis lourd avec tous ces détails. Je pense que ta note -9 vient du fait que ton commentaire arrive de nulle part sans qu'on puisse voir le lien avec le sujet de la dépêche (ton métier, même si indirectement on devine que c'est musicien ?), et sans explications.

Padavwan ?
Si t'as pas d'avoine il fallait répondre "en recherche d'emploi" ;)

Non sinon plus sérieusement, mon métier recoupe testeur, enseignant (séminaires sur l'utilisation du soft), et dev (de scripts, de specs), donc je comprends ta frustration de ne pas pouvoir voter plusieurs fois.

Genre dans un sous-marin je les vois bien jouer à "touché-coulé" sur la console de lancement des têtes nucléaires en easter-egg le soir…

À la ligne du 1. :

L'exécutable gawk évolue donc ainsi ainsi :

Si tu penses que les élèves ne vont pas essayer de tricher, c'est que tu n'en as jamais vu en vrai et que tu n'as pas dû aller à l'école ni à la fac :)

Ça a changé, 67 bugs bloquants maintenant.
Vu la tendance, il est difficile d'en conclure que "c'est pour bientôt".

Il y a aussi "sur les traces des illustres de la commune".
Le mot manquant est sans doute "lieux"…

Non, moi aussi je faisais (presque) ça il y a quelques année quand j'étais dans ma chambre d'étudiant.
Avec cron, ce n'est pas un flux radio que je lançais mais un script qui choisissait aléatoirement un fichier parmis des son (enregistrés avec ma voix) qui disaient "c'est l'heure de se lever" avec différentes intonations (et même une variante en langue otaku).

Même si du fais organiser ça par une équipe mixte ? Pourtant dans ce cas les intérêts s'annulent et l'équipe a tout à gagner à un système électronique sûr.
C'est le même principe que pour des assesseurs "papier".

Ok très bien admettons que ce soit une menace réelle, pour continuer la réflexion.
Dans ce cas il suffit d'inspecter la chaîne de construction du hardware. Les outils logiciels et matériels utilisés pour créer les CPUs sont les mêmes que pour n'importe quel autre circuit (y compris de petits circuits, où une anomalie serait vite détectée), et il y a beaucoup de ces outils qui sont open source (en particulier pour passer du code RTL à du niveau gates).

Tu crois que je dis ça sans réfléchir ?
Par exemple les attaques brute force en cryptographie consistent à essayer toutes les possibilités.
Genre 2^{40=1099511627776} c'est énorme et pourtant : http://en.wikipedia.org/wiki/40-bit_encryption
<< A typical home computer in 2004 could brute-force a 40-bit key in a little under two weeks >>
Pour rappel les clés de 192 bits (tes 24 octets) sont réputées sûres actuellement pour le brute force, mais il y a plein de gens qui cherchent quand même à les casser avec des techniques plus fines.
Et donc, pendant que ça cherche l'ordi va planter bêtement parce qu'il aura essayé la séquence "CIA" ?
Et pour ce qui est de planter, je dis ça car des OS comme Linux ont certainement un comportement différent selon le flag de la page mémoire, et donc bien évidemment ce n'est pas le comportement "cohérent" qui aurait lieu, et dans le meilleur des cas ce sera rattrapé par une séquence de traitement d'erreur et il y aura un oops.
J'aimerais bien avoir ton avis, comment est-ce que tu penses que ça ne pourrait pas perturber l'OS ?

Autre argument : les ingénieurs de la CIA seraient bien embêtés pour documenter leur "fonctionnalité" !
Si leurs ordinateurs sont du même type, tout ceux qui essaieront de lire la séquence dans un fichier texte changeront la sécurité des pages mémoire…

Autre raison : si c'était le cas pour des séquences vraiment grandes (et donc peu probables), ça alourdirait tellement le temps d'execution de l'instruction que cette instruction deviendrait totalement inutilisable (et donc lors de l'implémentation de gcc pour cette architecture on s'en passerait).

Plus généralement cette famille d'arguments se fait ridiculiser classiquement ainsi :
* le compilateur gcc est fait pour utiliser une liste d'instructions, d'une certaine manière. Si le matériel n'est pas tout récent, ces instructions auront toutes été utilisées à peu près de toutes les manières possibles, pour les situations "sensées", c'est-à-dire pour le code C "sensé" correspondant. Par code "insensé" je pense à du code vraiment exotique qui se remarquerait tout de suite et qui ne passerait pas la moindre épreuve d'un commit officiel.
* si jamais des instructions "spéciales" existent pour une architecture, personne ne sait qu'elles existent et personne ne les utilisera dans gcc.

Conclusion : et paf, dans les dents pour ceux qui aiment bien faire marronner les autres avec des théories du complot foireuses : )
Les théories du complot en sécurité informatique, c'est bien quand c'est crédible (ça fait avancer le domaine), mais excusez-moi quand c'est des arguments foireux ça me met en colère, car au contraire ça désinforme les gens. Et sur un site comme ça on ne désinforme pas, c'est tout.

Je suppose que je dois prendre ça au 33e degré : c'est très ridicule comme blague.
Et si cette séquence est présente, genre dans une séquence produite par un générateur aléatoire (seulement 24 octets ça a une bonne grosse proba d'arriver dans une séquence !), tu fais planter ton ordi juste pour ça ? Tu vois bien que dans des machines utilisées pour des tas d'applications ça ne peut pas arriver ! Ou bien ça ferait longtemps que ça se saurait, et quand ça se sait ce n'est plus un problème.
Et paf, arg suivant ? (mais évite les blagues hein)

Qui aurait intérêt à dépenser des sommes folles à instrumenter tous les PCs du commerce pour le seul but que ceux qui sont utilisés dans ce process soient biaisés ?
De plus, il suffit de choisir une machine assez ancienne pour que le projet de son instrumentation secrète n'ait même pas pu être encore envisagé au moment de sa production en usine.

Et si tout simplement c'était des machines grand public, soit très grand tirage, soit assez anciennes, qui étaient utilisées ?
Il me semble que l'on peut avoir confiance aux machines standard : elles ont été tirées en séries et depuis longtemps pour tous usages, et un fonctionnement bizarre caché du CPU ou autres aurait été découvert, surtout avec les OS alternatifs.

Tout comme le post précédent, la réponse est la même : il suffit de surveiller le processus d'installation de la machine.
Partir d'une distribution Linux off-the-shelf (ou bien la graver avec des appareils lambda du commerce), et utiliser cet OS pour installer le serveur, les commandes étant vues par les "assesseurs techniciens". Ils pourront dire s'ils voient des manigances, car si il y a tentative d'obfuscation ce sera flagrant.

Non mais tu peux vérifier la chaîne de conception de la machine (design, usines).
C'est moins coûteux que de tester le produit fini et c'est aussi efficace.
Argument suivant ?

Le vote sur internet permet de voter à distance sans se déplacer et sans faire de procuration (de toute manière le procuré doit aussi se déplacer, pour le vote papier).
Donc ça permet également de solliciter le vote beaucoup plus souvent, car ça ne dérange pas beaucoup les citoyens. On pourrait donc imaginer un scrutin par problème posé, au lieu d'un scrutin global censé élire des politiques affirmant pouvoir répondre à tous les problèmes présents ou futurs…

Ben pour simuler le cerveau on prend les heureux gagnants du Top 500 et on les branche en calcul parallèle ? :D
--> []