JaguarWan a écrit 331 commentaires

Ailleurs, le PDG du groupe Choco-BN a annoncé devant une assistance enthousiaste qu'il comptait mettre des puces RFID dans ses célèbres biscuits afin de "traquer les jeunes pirates qui partagent leurs goûters".

Ce comportement irresponsable engendrerait d'après les experts plusieurs millions d'euros de manque à gagner chaque année pour l'industrie du biscuit, contraignant les industriels à délocaliser.

"Chaque fois que vous partagez un Choco-BN, vous volez le travail du papa ou de la maman d'une de nos chères têtes blondes" a conclus le PDG.

Un projet de loi est à l'étude afin d'étendre les dispositifs de traçabilité déjà mis en place pour les viandes à l'ensemble des produits alimentaires.

Ce nouveau suivi amélioré, "de l'usine à l'estomac", devrait permettre de sanctionner les consommateurs indélicats, tout en garantissant un meilleur respect des normes sanitaires pour la sécurité de tous.

La nuit porte conseil... Il s'agissait d'un problème de locales. En lançant une konsole avec LC_ALL=de_DE.UTF-8 et LANG=de_DE.UTF-8, et avec un setlocale(LC_CTYPE, ""), j'ai une sortie conforme à ce que j'attendais:

jaguarwan@Jaguar:~/Projects/MammouthServer-0.3$ LC_ALL=de_DE.UTF-8 LANG=de_DE.UTF-8 ./a.out
Schöne Grüße
* allocating bouga
-> Multibyte conversion: bouga
* testing string_cpy
-> bouga is a copy of bouga
* allocating coin
* testing string_pre
-> bougacoin was prepended bouga
* testing string_cat
-> bougacoinbouga was appended bouga
* testing string_del
* testing string creation with string_cmov
Sch�e Gr� <--- affichage brut du contenu de la chaine avec putwchar()
-> Multibyte conversion: Schöne Grüße
-> Schöne Grüße was created using string_cpre
* testing string_upper
-> SCHÖNE GRÜßE was converted to upper case
* testing string_lower
-> schöne grüße was converted to lower case

M'enfin, maintenant reste à faire cohabiter ça avec des chaines binaires :]

La glib fait bien plus que gérer des chaînes de caractères, c'est un peu un lance roquette pour tuer une mouche (et une dépendance en plus) dans mon cas. "Réinventer la roue" présente deux avantage : ça me permet d'apprendre comment coder une application gérant UTF8 proprement (j'espère ^_^'), et de ne dépendre que d'un compilo compatible ISO C au final.

Pour wprintf, j'y ais pensé mais apparemment la seul différence avec le printf de base c'est qu'il accepte un format en wchar_t -- printf("%ls", bidule); et wprintf(L"%ls", bidule); font exactement la même chose :)

Hmm, je te trouve injuste avec ce logiciel...

Sous KDE, on a quoi comme visionneuses ?

* ShowImg, qui n'arrive pas à ouvrir les images dans les archives en utilisant zip:/, qui fait des zooms pas terrible et qui n'est pas vraiment un foudre de guerre. (KSquirrel fait de beaux zooms et gère zip:/)

* Kuickshow, qui n'est pas foutu de faire du fullscreen et qui redimensionne la fenêtre à chaque image... Impossible de lire une BD/un manga scannée avec "ça". En plus il fait un zoom très sale.

Par contre, il y a effectivement pas mal de bonnes visionneuses pour GNOME, comme gThumb qui est excellent ou GQview.

Je suis passé à KSquirrel, et franchement pour lire une BD il est vraiment bien.
Il adapte directement l'image à la taille de l'écran
Il est rapide
Il zoome très proprement
Pas un seul plantage sur ma Slackware.

En plus il n'est qu'en (pre)version 0.6, je trouve que pour un projet aussi jeune c'est vraiment prometteur.

Arf, il est peut être un peu tard pour répondre, m'enfin au pire ça pourra peut être servir à quelqu'un d'autre ?

Une fois que tu as installé sleuthkit et autopsy, il faut lancer autopsy en root. Après, tout se fait dans le browser.

http://localhost:9999/autopsy

L'aide fournie est très bien faite, et l'utilisation des outils du sleuthkit rendue vraiment très simple.

J'espère que tu pourras récupérer tes fichiers.

des magazines

Je propose une publication qui aurait pour mascotte le lapin Plan9, dans lequel de vraies stars comme Linus Torvalds, Richard Stallman ou encore Theo de Raadt poseraient en sous-vêtements affriolants. Le premier numéro comporterait un poster central dévoilant un diablotin et un manchot entièrement nus se livrant à des activités prenantes avec un tournevis, une nappe ronde et une chèvre.

Salut, j'ai fait un petit script assez similaire pour ma Slack, et qui marche expérimentalement bien. Bon, par contre je ne l'ai pas automatisé avec cron, pour éviter de remplir mon disque dur...

En gros, il fait un gros tarball pour chaque répertoire dans le tableau $BACKUP_DATA et les range tous dans un dossier YYYY-MM-DD à l'intérieur de $BACKUP_PATH.

Si ça peut t'être utile, voilà le code:

root@Jaguar:~/Admin# cat backup-o-matic
#! /bin/sh

BACKUP_PATH="/root/backup"
BACKUP_DATE=`date --iso-8601=date`

# The directory/files to compress and save
BACKUP_NUM=4
BACKUP_DATA[0]="/etc"
BACKUP_DATA[1]="/home"
BACKUP_DATA[2]="/root"
BACKUP_DATA[3]="/boot"


if [ ! -d $BACKUP_PATH/$BACKUP_DATE ]; then
    # Create the directory
    mkdir -p $BACKUP_PATH/$BACKUP_DATE

    # Archive the data
    for ((i=0;i<$BACKUP_NUM;i++)); do
        echo "Compressing ${BACKUP_DATA[i]}..."
         nice -n 10 tar czfP $BACKUP_PATH/$BACKUP_DATE/`echo "backup${BACKUP_DATA[i]}" | sed s/"\/"/"-"/g | cut -f1 -d\ `.tgz --exclude-from ./exclude-list ${BACKUP_DATA[i]}
    done
fi

Ce script ne doit marcher qu'avec bash (boucle for spécifique entre autres) et n'est pas élégant (voire carrément brut de décoffrage), mais il fait son boulot. Le fichier exclude-list est une simple liste de fichiers, comme ça:

root@Jaguar:~/Admin# cat exclude-list
/home/jaguarwan/.wine/drive_c/*
/home/jaguarwan/Download/*
/home/jaguarwan/Playground/*
/home/jaguarwan/.pearpc/*
/home/jaguarwan/.aMule/Incoming/*
/home/jaguarwan/.aMule/Temp/*
/home/invite/*
/root/backup/*

J'ai eu le problème il y a quelques temps, et j'avais essayé le couple Sleuthkit/Autopsy. Je ne peux que te le recommander chaudement, ça marche vraiment *très* bien.

Je ne sais pas quelle est ta distribution, mais le package net-snmp est nécessaire pour utiliser l'imprimante en ethernet.

Comme il n'est pas trouvé, le ./configure foire, donc le Makefile n'est pas généré, et donc le make échoue aussi :)

M'enfin, je pense qu'en claquant un ./configure --disable-network-build --prefix=/usr, le make devrait marcher, mais tu devras utiliser l'imprimante en USB.

J'ai fait un mini tutorial récemment pour installer une imprimante HP combo scanner qui utilise les même drivers dans la section Slackware, il pourra peut-être t'être utile:
https://linuxfr.org/forums/23/11870.html

Je pense que tu n'as pas tout à fait compris les liens entre chaînes de caractères, pointeurs, et mémoire physique.

En C, les chaînes de caractères sont définies en mémoire comme une suite de caractères contigus terminée par le caractère NUL, '\0'.

Par exemple, en imaginant la mémoire physique comme un tableau:
[ 'H' | 'e' | 'l' | 'l' | 'o' | '\0' ]

Maintenant, comment représente-t-on, ou accède-t-on à un espace mémoire en C ?

* Un pointeur contient l'adresse d'une zone mémoire quelconque. On peut donc l'associer avec n'importe quel espace mémoire (à ses risques et périls).
* Le tableau définit entièrement un espace mémoire; il pointe implicitement vers l'emplacement mémoire de son premier élément.

donc :
char *pointeur = NULL; n'est pas une chaine de caractère, il n'a pas de mémoire associée
char tableau[6] = { 'H', 'e', 'l', 'l', 'o' }; est une chaine de caractère; le nom 'tableau' renvoie directement à la mémoire contenant "Hello";

Pour avoir une 'chaîne de caractère' avec un pointeur, il faut donc lui associer de la mémoire.

pointeur = tableau;

On associe l'espace mémoire contenant la chaîne "Hello" du tableau à notre pointeur. Attention, le pointeur et le tableau référencent par conséquent la même mémoire 'physique'. Donc changer la chaîne avec pointeur[0] = 'h'; par exemple modifiera le tableau aussi ;)

A noter: dès qu'un pointeur est associé à un espace mémoire, on peut le manipuler comme un tableau. On peut aussi jouer sur l'adresse enregistrée pour se "déplacer" dans la zone. Par exemple, pointeur ++ positionnera le pointeur sur le 'e' de "Hello".

On peut aussi demander un nouvel espace mémoire au système en utilisant malloc, qui renvoie un pointeur.

Pour copier "Hello", on peut donc faire:
pointeur = malloc( (strlen(tableau) + 1) * sizeof(*pointeur));
                               ^ taille de la chaine    ^ taille du type de tableau

Attention au '+1', il ne faut pas oublier le zero final !
A ce stade, on a une nouvelle zone mémoire vierge de la même taille que "Hello". On va donc copier le tableau dans la nouvelle zone mémoire.

strncpy(pointeur, tableau, sizeof(tableau));

Voilà, on dispose d'une copie de la chaîne "Hello".

Si je n'ai pas été trop confus dans mes explications, tu devrais donc voir que ton programme plante, car tu utilises le pointeur temp sans lui avoir associé un espace mémoire.

Dans ce cas, strncpy() écrit n'importe où, et strstr() lit on ne sait où...

Ce désordre met Linux en colère, qui abat alors froidement ton programme d'un SIGSEGV dans la nuque, ce qui se résume souvent par un pauvre "Segmentation fault" dans ton terminal.

usleep(useconds_t usec) est une des fonctions les plus simples pour faire une pause inférieure à une seconde; elle s'utilise comme sleep, mais avec des microsecondes.

Toutefois, cette fonction ne fait pas partie de la bibliothèque standard et est déclarée obsolète.

Le terme 'polling' n'est pas limité à la programmation réseau, il désigne en gros l'action de surveiller une ressource (souvent un descripteur de fichier) pour déterminer si elle est prête à être utilisée.

Après, il y a plein de méthodes différentes pour ce faire :)

http://www.atnf.csiro.au/people/rgooch/linux/docs/io-events.html(...)

Héhé, certes select() retournera avant le timeout s'il y a de l'activité sur les sockets... Mais sur un grand nombre de sockets, elle est quand même pénalisante car:

- le kernel scanne tous les sockets du FD_SET avant de retourner, il ne retourne pas dès qu'un socket a été trouvé prêt.

- select() retourne certes le nombre de socket prêts, mais il faut scanner tout le tableau de fds pour les retrouver.

- le nombre de fds enregistrable dans un set varie suivant l'OS et est parfois très limité (64 fds sous Windows...). L'implémentation des macros FD_* varie aussi suivant l'OS: sous GNU/Linux, c'est effectivement une affaire de bitmask, donc c'est rapide, mais sous Windows, chaque appel à FD_ISSET() scanne tout le tableau...

Le gros avantage de l'API epoll, c'est qu'on enregistre son fd et sa structure associée avec epoll_ctl, et qu'on reçoit ensuite directement un (ou plusieurs) fd prêt et sa structure avec epoll_wait. Donc pas de scans, pas de limitation de nombre de fds, et une notification immédiate. Dommage que ça ne soit pas portable !

J'ai regardé à quoi correspondait les proactor patterns, en diagonale, et ça ressemble furieusement au principe des I/Os asynchrones couplées avec un mécanisme de notification à la completion... Genre le hack SIGIO pour GNU/Linux ou les I/O completion ports sous Windows NT. C'est très puissant, mais pas portable non plus :) Quant au reactor, ça semble plus proche du principe d'epoll, select ou poll, avec des I/Os synchrones.

Donc en fait, j'aimerais arriver à avoir un truc proche de epoll en utilisant select() (ou autre chose de portable), mais je me demande si c'est très faisable...

Effectivement, ça mettra le même temps dans l'absolu (voire plus, avec l'overhead dû aux push()/pop() et aux context switches), mais en "fragmentant" le select() j'espère gagner en "répondant". En gros, au lieu d'attendre le résultat d'un gros select() pendant n secondes et de le dispatcher aux travailleurs, là les évènements devraient être distribués aux travailleurs en flux continu tout au long de ces n secondes.

Cependant, j'ai l'impression que ma démarche est un peu naïve, et j'aimerais avoir des avis sur une utilisation de select() qui soit "scalable". En interrogeant google, j'ai vu par exemple que le très performant serveur Zeus (closed source) utilise select() d'une manière optimisée. Mais vu que les sources ne sont pas disponibles, pas moyen de voir comment il procède...

Bien sûr, "ce qui entoure l'appel à select()" est également sur l'établi, mais j'ai particulièrement besoin de conseils pour l'écriture d'une méthode de polling portable...

En fait, j'utilisais select() sur un tableau de sockets précédemment... la méthode classique. Donc plus j'avais de connections, plus l'appel lui-même (et ensuite le scan avec FD_ISSET()) était long.

Là en fait, select() est utilisé sur un seul socket (et pourrait parfaitement être remplacé par ioctl(FIONREAD) et un équivalent en écriture, malheureusement non portable).

Tes CFLAGS sont trop restrictifs.

Généralement, le warning "storage size of XXX isn't known" apparaît quand on manipule un (void *) ou un type incomplet.

Or la définition de la structure ifreq est entre #ifdef __USE_MISC dans le header, donc elle n'est pas déclarée. Idem pour inet_aton(), qui est une fonction BSD.

Essayes donc d'ajouter -D_BSD_SOURCE à tes CFLAGS.

... dans la bibliothèque standard, mais si tu ne travailles que sur des chaînes ANSI, ceci devrait faire l'affaire :

#include <ctype.h>

void strlwr(char *string)
{
while ( (*string = tolower(*string ++)) );
}

L'avantage par de tolower() par rapport à un bidouillage des valeurs ASCII c'est qu'il gère la locale.

Si tu utilises des wchar_t, remplace ctype.h par wctype.h et utilises towlower().

Pour lancer le client dhcp sur une interface réseau, il suffit de taper:
dhcpcd nom_de_l'interface.

Après, on peut ajouter quelques paramètres sympathiques, genre -d pour qu'il écrive ses messages d'erreur dans syslog (ça te permettra de voir si tout marche bien), -t pour fixer un timeout, ou encore -R pour éviter qu'il n'écrase resolv.conf (les adresses DNS).

Personnellement, sur ma Slackware, j'ai la commande suivante pour me connecter au démarrage:
dhcpcd -d -t 60 -R /dev/eth1

La crise de germanisme de ta machine est peut être due à un changement en fourbe des variables d'environnement LC_ALL ou LANG... Essaye de voir si un export LC_ALL=fr_FR ne résout pas le problème.

C'est pas souvent que ça parle d'animation ici :)

Personnellement, j'ai bien aimé Shingetsutan Tsukihime, Berserk, Monster, NaruTaru, Full Metal Alchemist et Noir...

Pour avoir un aperçu, le site http://www.animeka.com(...) propose de courts résumés sur toute sortes de séries d'animation, celles-ci devraient s'y trouver :)

Pas de problème, avec full il t'a installé tout ce qu'il faut ;)

Et tu as bien raison :)

Bon, la compilation noyau c'est pas aussi dur que ça en a l'air :) En gros, si tu sais ce que tu fais pendant la configuration, ça se résume à ça pour un 2.6:


make xconfig (si tu fais ça sous X, make menuconfig autrement)
(modification de la config)
make (boire un café)
make install
make modules_install


Ensuite, pour les bonnes options à mettre, il y a entre autre un tutorial ici: http://www.linux-usb.org/SpeedTouch/slack/index.html(...)

La compilation du kernel c'est pas difficile, ça prend juste un peu temps et il faut savoir ce qu'on fait... :)

Essaye une Slackware, là il n'y aura rien qui se mettra sur ton chemin si tu veux modifier ton système :) Par contre, si tu n'aimes pas bidouiller tes fichiers de conf à la main, tu seras peut être insensible à son charme...

C'est une distribution stable, rapide, une des plus ancienne mais néanmoins très à jour (là, en current, je tourne avec un KDE 3.4.1, Xorg 6.8.2, dernier Koffice, toussa). Par contre si tu préfères GNOME, passe ton chemin. Si tu es adepte d'autre WM, Slack fournit entre autre XFCE, WindowMaker, Blackbox et Fluxbox. A noter, la version current est extrêmement stable...

Le système de paquet est très agréable à utiliser: il ne gère pas les dépendances, et est basé sur de simples tgz :) De ce fait, il est très rare que l'installation d'un nouveau programme soit problématique : pas de paquets à moitié supprimés qui empêchent l'installation d'une mise à jour, ou d'un autre paquet :þ, et les dépendances manquantes sont rares.

L'installation de base de la Slackware étant assez fournie, si tu veux installer quelque chose à partir des sources, tu pourras compiler à peu près ce que tu veux sans te faire jeter au ./configure, sans avoir à installer X paquets devel...

Tu peux installer de nouveaux paquets ou mettre à jour les existants très simplement en utilisant le petit outil en ligne de commande slackpkg et créer tes propres paquets en utilisant checkinstall (à la place du make install final).

Slackware utilise le plus possible les versions standard de chaque application, donc ça simplifie énormément la résolution des éventuels problème : pas de patches spécifiques à la distribution qui complique le tout.

Tu peux trouver plein de bonne documentation sur Slackware sur http://trustonme.net,(...) et des paquets non officiels à profusion sur http://linuxpackages.net.(...)

Voilà voilà, moi j'aime bien ma Slackware justement car elle ne me met pas de bâton dans les roues en essayant de m'aider. Si ça t'a convaincu, fonce sur www.slackware.com récupérer les ISOs ;)

Le tiens a l'air plus fiable, il est resté disponible tout du long :) En plus apparemment tu peux utiliser du php avec, c'est déjà bien avancé pour une alpha :)

Par contre j'ai voulu faire un telnet dessus et il ne répond pas quand je lance un bête GET / HTTP/1.1...

Héhé, le TCP_FIN est parti, le Mammouth est relancé :)
J'espère que cette erreur bizarre ne se reproduira pas...

J'ai été maladroit, j'ai tué le serveur pour voir s'il était en deadlock mais je ne peux plus le relancer à cause d'une erreur de bind...

A la lumière de netstat, on peut voit que le socket d'écoute est coincé en FIN_WAIT1...

pingouin@MICHOKO:~/MammouthServer-0.2/Mammouth$ netstat -t
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 MICHOKO.ma:microsoft-ds 192.168.0.4:32770 ESTABLISHED
tcp 0 16362 126.20.97-84.rev.g:8080 dhcp-83-219-107-17:3920 FIN_WAIT1
tcp 0 48 126.20.97-84.rev.ga:ssh AAmiens-152-1-38-:57363 ESTABLISHED

En attendant (cependant je ne crois pas que FIN_WAIT1 ait un timeout), je pense qu'on peut déclarer le Mammouth écrasé...

Les sources sont disponibles sur http://mammouth.tuxfamily.org(...)