flavien75 a écrit 315 commentaires

je suis chez Sosh (donc en 4G) et chez moi ça marche (tm).
Pour être plus précis concernant la configuration,
- serveur SSH (à la maison sur ligne ADSL orange) répond sur un port > 10000,
- le téléphone Android est en mode point d'accès,
- sur l'ordinateur portable, je me connecte au serveur SSH

J'imagine que c'est à peu près ce que tu voulais faire?

Les vrais naviguent en -42

Il va effectivement falloir que je plonge dans ces histoires d'async-signal-safe. Ce sera effectivement intéressant de voir si 2 écritures "simultanées" (programme et signal) peuvent se retrouvées entremêlées ou pas.

Enfin là pour le coup le but était juste de "neutraliser" les Ctrl+C et cette solution (la seconde) fonctionne à tous les coups et sans risque.

Dans la première le but du exit() était d'épargner à l'utilisateur d'aller faire un kill -9 quand l'application ne répond vraiment plus du tout. Elle n'était déclenchée que dans les versions beta, les versions finales quittant en général en moins d'une seconde (donc avant que l'utilisateur ne perde patience).

La remarque de Krunch m'a par contre fait réfléchir à l'effet d'un exit() au moment où la boucle principale exécuterait la fonction atexit(). J'ai effectivement des doutes sur la fiabilité du programme dans ce cas. D'où l'idée de remplacer exit() par _exit().

Les vrais naviguent en -42

Pour le type sig_atomic_t, il faut pas exagérer. A part sur Pic (et 8051 ?) le type "int" fait 32 bits, donc l'écriture (ce n'est plus un read-modify-write) se fait en 1 cycle (non-interruptible par définition).
Et vu que la variable ne fait que passer de 0 à 1, il n'y a aucun risque de glitch. Ce n'est pas comme si 2 threads faisaient du read-modify-write dessus.

Les vrais naviguent en -42

Bien vu, merci de la remarque.

Je me doutais que le printf risquait de générer des bugs d'affichage dans la console (genre si ça arrive au milieu de l'écriture d'une séquence de commande ansi).
Par contre il faudra que je remplace mes exit() par _exit().

L'interception et la tentative de fermeture propre du programme restent par contre valables.

L'exemple devient donc:

#include <signal.h>

int please_exit = 0; // si marche pas avec optimiseur, ajouter "volatile", c'est moche mais ça marchera
void exitApp(int sig)
{
   please_exit = 1;
}

int main(int argc, char** argv)
{
    signal(SIGINT, exitApp);
    // programme principal
    // dès que la variable please_exit est non nulle, on quitte proprement le programme
    // par exemple
    while (!please_exit)
    {
        // ...
    }
}

Les vrais naviguent en -42

Personnellement j'utilise plutôt ce code :

#include <signal.h>
#define CTRL_C_LIM 3
int please_exit = 0;
void exitApp(int sig)
{
   if (please_exit < CTRL_C_LIM)
   {
      fprintf(stderr,"CTRL+C received");
      please_exit++;
   }
   else
   {
      fprintf(stderr,"CTRL+C received too many times, forcing exit");
      exit();
   }
}

int main(int argc, char** argv)
{
    signal(SIGINT, exitApp);
    // programme principal
    // dès que la variable please_exit est non nulle, on quitte proprement le programme
    // par exemple
    while (!please_exit)
    {
        // ...
    }
}

Ça permet au programme de balancer des "attend un peu que je finisse" tout en permettant à l'utilisateur de marteler Ctrl+C pour tuer violemment le programme.

Accessoirement ce bout de code fonctionne aussi bien sous windows que sous Linux.

Les vrais naviguent en -42

Au final le fonctionnement est le même pour eux, c'est comme si tu demandes à tes utilisateurs de démarrer une Clio et le lendemain tu leur demandes de démarrer une 308, ils sauront très bien que c'est avec la clé, peut importe de ce qui les entoure.
Mauvais exemple, pendant mon dernier déplacement on m'a filé une Skoda de location toute neuve (d'habitude je conduis une 308). Ça m'a bien pris 5 minutes pour la démarrer (surtout pour comprendre qu'il y avait pas besoin d'enfoncer la clef quelque part).

Donc non, un minimum de formation ne fait jamais de mal.

Les vrais naviguent en -42

Ça ne doit pas venir de ça car le single link permet d'envoyer du 1920*1200 à 60Hz (donc plus que le débit demandé).
D'ailleurs l'écran ne gère probablement pas le dual link (ça couterait plus cher à fabriquer).
Par contre, un faux-contact sur les fils qui gèrent le DDC est toujours possible.
Où alors un problème dans l'écran.

Les vrais naviguent en -42

ok, je comprend mieux,

C'est pas évident qu'il faille faire une requête via l'endpoint 0, peut-être qu'il donne les mesures dès qu'on fait une requête.
Selon la sortie lsusb que tu as fourni, il n'y a pas d'endpoint de type OUT, donc il n'y a pas à écrire dans les périphériques hidraw3 et hidraw4.

Pour moi le gros problème vient du plantage de libusb. Le seul cas où il peut crasher serait si tu tape sur un endpoint ou une interface qui n'existe pas. A ce niveau là, il faudrait voir le code complet.

Il vaut mieux éviter d'attaquer l'endpoint 0 sans savoir exactement ce qu'on fait, sinon tu risque de briquer ton appareil.

D'ailleurs, le mieux serait de le déconnecter totalement du driver, de lancer un Windows dans une machine virtuelle et de dumper les transferts via Wireshark. Bon courage…

Les vrais naviguent en -42

Il y avait un driver attaché à l'interface, donc ça ne risquait donc pas de marcher.

Pour info, la méthode "propre" serait de créer une règle UDEV pour empêcher le driver de prendre le périphérique comme ça il n'y aurait plus besoin d'être root pour lancer le programme. Par contre, je ne l'ai jamais fait donc je ne peut pas te donner la ligne.

Normalement, si le périphérique est conforme à la norme HID, le driver noyau devrait être suffisant.
Mais c'est quand même bizarre pour un lance-roquette USB d'avoir juste des endpoints de type IN. Est-ce qu'il n'y aurait pas un bouton dessus ? Sinon je ne vois pas l'intérêt d'être HID.

Il ne faut pas oublier que l'endpoint 0, qui est présent sur tous les périphériques USB, n'apparaît jamais dans le lsusb. C'est un endpoint de type "control" donc il faut utiliser les fonctions qui vont bien dans libusb.

Par contre tout ça n'explique pas le plantage.

Les vrais naviguent en -42

Qu'est-ce que renvoi libusb_claim_interface() ?

Car en général les périphériques type HID sont directement pris en charge par un driver noyau. Et comme une interface ne peut être utilisée que par un logiciel à la fois, ça risque de poser problème.

Dans ce cas, il faudrait tenter un libusb_detach_kernel_driver(deviceHandle,1) au démarrage du programme, qui renverra 0 ou LIBUSB_ERROR_NOT_FOUND si aucun driver n'utilisait l'interface en question.
S'il a renvoyé 0, tu sera prié de faire un libusb_attach_kernel_driver(deviceHandle,1) avant de fermer le programme.

Sinon concernant les bugs, j'ai déjà eu ça sur les transferts bulk avec la version fournie par la distribution (Ubuntu 8.04). Le bug avait été corrigé en upstream, mais la distribution n'a jamais distribué la mise à jours. Donc il faut toujours se méfier.

edit: pour détacher le driver, il faut bien évidement être root (donc programme à lancer avec sudo)

Les vrais naviguent en -42

C'est pas fiable à 100%, mais c'est simple à mettre en place.

Pour plus de fiabilité, il y a le haut-parleur. Là tu peux avoir une appli qui envoi du son quand tout fonctionne.

Les vrais naviguent en -42

Le lien montre comment faire avec les versions précédentes, je n'ai pas réussi à faire pareil avec la 34.
Je ré-essaierai dans la semaine, en attendant j'ai ré-installé la version 33.1 en copiant le binaire de Mozilla sans passer par le gestionnaire de paquets.
lien Mozilla

Les vrais naviguent en -42

Par contre, Flashblock n'est plus disponible (pour l'instant), il faut donc supporter toutes les applications Flash qui se lancent automatiquement lors de l'ouverture de pages.

Sinon le champs de recherche fonctionne bizarrement (ou alors j'ai rien compris), les moteurs de recherches ajoutés par l'utilisateur ont disparus et lorsqu'on veut en ajouter un, on est renvoyer sur la page d'ajout des greffons de Mozilla. C'est dommage, Opensearch fonctionnait bien.

Au final, j'ai du revenir à Firefox 28 (sur Ubuntu-Gnome 14.04).

(Les remarques ont bien entendu été envoyées à Mozilla)

Les vrais naviguent en -42

Bonjour à toi,

J'aurai de base conseillé une Ubuntu 10.04, mais malheureusement elle n'est plus vraiment maintenue (dommage…) car je pense qu'elle aurait parfaitement correspondu à ton besoin

L'information importante est que c'est un PC assez vieux. Donc il vaut mieux que tu commence par choisir le gestionnaire de fenêtre (le bureau quoi) :
- kde peut vite devenir assez lourd
- (pour ce que j'en ai vu) Unity utilise beaucoup la carte 3D
- gnome shell utilise aussi la carte 3D

ensuite vu que tu veux pas devenir (tout de suite) un gourou de la ligne de commande, il faut une distribution stable et facile d'accès
Donc perso, je te conseillerai plutôt d'essayer une Lubuntu, elle utilise le bureau LXDE, sans fioriture du genre 3D, elle devrait bien tourner. Après elle reste assez accessible.

Sinon le choix de Mint a aussi l'avantage d'être stable, la différence se fera au niveau des paquets disponibles.
Pour répondre à ta question sur les bureau Mint:
- Cinnamon est basé sur les technologies gnome-3, donc assez récentes,
- Mate est basé sur gnome-2, donc plus ancien, pour les nostalgiques de la 10.04 comme moi…
- KDE, j'en ai déjà parlé, ça risque vite de ramer avec ta configuration
- XFCE, très léger, ça vaudrait le coup de l'essayer.

je ne répondrait ni sur les d'émulation, ni sur la question de ta carte son vu que je n'y connaît rien.

Dans tous les cas, avant d'installer un dual-boot, je te conseille d'essayer avec un live-CD voire une clef USB si ton PC supporte (ce qui n'est pas gagné).

Les vrais naviguent en -42

En même temps ce n'est pas forcément très pertinent de défragmenter un SSD, à part si on veut l'user plus vite.

Les vrais naviguent en -42

Le répertoire /var/www appartient à www-data, tu n'as pas le droit d'écrire dedans.
tu pourrais tout faire en sudo, mais ce serait dangereux.

1. Ajouter ton utilisateur au groupe www-data

sudo useradd -G www-data diane

1. autoriser les membres du groupes www-data à modifier le contenu du répertoire

sudo chmod g+w /var/www

1. faire que tous les fichiers et répertoires créés ultérieurement appartiennent au groupe www-data (propagation du groupe dans les sous-dossiers

sudo chmod g+s /var/www

n'oublie pas de relancer la session (kde) pour que le point numéro 1 soit pris en compte.

avec ça, ton utilisateur devrait pouvoir accéder normalement (et proprement) au site web

Les vrais naviguent en -42

ça doit être le niveau -42

Les vrais naviguent en -42

Qu’apporte le sel différent pour chaque utilisateur, dans la mesure où si le code est leaké, le pirate peut avoir accès à la méthode aussi bien qu’à un sel global ?

Dans ce cas l'attaquant doit générer une rainbow-table par mot de passe.
Personnellement, plutôt que de générer le sel aléatoirement et devoir le stocker, je concatène une constante, le nom d'utilisateur et le mot de passe

SHA1($magic_key.$user_login.$password);

Comme il est dit dans l'article, il faut absolument éviter que 2 mots de passe identiques donnent le même résultat.

Sinon il faudrait aussi parler du niveau -3: on stocke les mots de passe cryptés par une constante planquée de le code (rigolez pas, je suis sûr que ça existe)

Les vrais naviguent en -42

désolé pour la réponse tardive (en vacances sans d'internet)
sous Fedora 19, en layout classique, pas de problème pour les AltGr+W et AltGr+X (« et »)
je ne connaissais pas ce raccourci, merci du tuyau.

Les vrais naviguent en -42

Ce bug est vraiment pénible on se demande comment les développeurs qui ont fait ça font un CTRL-PageSup (ou CTRL-PageInf).

Lors du passage Ubuntu 10.04 vers Fedora 19, j'avais choisi le layout french-alternate habituel (avec son symbole cube au dessus du carré) qui a donc ce problème.

Finalement je suis revenu au layout classique qui n'a pas ce problème (et qui n'a pas besoin de patch). Après il faudrait voir les autres différences.

Les vrais naviguent en -42

pour la partie CPU, ça fonctionne très bien : sous Fedora 19 on utilise cpupower.

Par contre je viens de me rendre compte qu'ils ont supprimé (cette semaine) des "régulateurs".
Donc jusqu'à la semaine dernière, mon quadcore i5 (qui monte a 3.6GHz) tournait en général à 800 MHz (régulateur ondemand).

[3615 mavie]
Avec la mise à jours, le système est passé en mode "powersave" donc il tourne à 3.6 GHz (?!?!?)
je vous laisse, je vais passer en mode "performance", avec un peu de chance le cpu ralentira à 800MHz…
[/3615 mavie]

Les vrais naviguent en -42

L'antivirus peut aussi faire rater le téléchargement car à la fin de celui-ci l'antivirus doit contrôler le fichier téléchargé.

Donc vérifie s'il y a un antivirus d'activer, si celui-ci fonctionne (ou crashe lamentablement) et si les fichiers téléchargés n'arrivent pas directement en quarantaine (dans ce cas pourquoi ?).

Les vrais naviguent en -42

surement, ça parait logique,
maintenant pourquoi pas (hardware,1,6) ?

Les vrais naviguent en -42

• les images sont directement intégrées au binaire, et dans ce cas comment fait-on (et pourquoi) ?

objcopy permet de générer un fichier objet (foo.o) a partir d'un fichier "binaire" (foo.bin, foo.bmp, foo.txt,…)

dans le Makefile :

%.o: %.bin
    objcopy -B i386 -I binary -O elf32-i386 $^ $@

dans les sources C ou C++

// defining variable contained in font.bin
// symbols created by linker, unusable as it is
// main program should only use their address
extern unsigned char _binary____src_font_bin_start;
extern unsigned char _binary____src_font_bin_end;
extern unsigned char _binary____src_font_bin_size;

Ces symboles doivent être exploités en tant que pointeur, donc par exemple dans le main on trouvera :

const unsigned char * DefaultFontArray = &_binary____src_font_bin_start;
const unsigned long DefaultFontArraySize = (unsigned long) &_binary____src_font_bin_size;

Par contre il y a quelques gros soucis de portabilité :
- le Makefile contient l'architecture visé, donc ce programme qui compilait (et fonctionnait) très bien sur une distribution 32bits ne compile plus sur n'importe quelle distrib 64 bit (en tout cas plus sur la mienne)
- sous windows mingw32 fait sauter la première underscore du symbole (à vérifier à coup de nm)

La plupart des libraries (que j'ai utilisé) ne permettent pas de lire un fichier depuis la RAM. Par exemple, les routines d'ouverture d'image de SDL_image prennent un nom de fichier en paramètre. L'intérêt est donc limité.

Les vrais naviguent en -42

juste par curiosité,
est-ce qu'il y avait un robot.txt sur le serveur ?

Les vrais naviguent en -42