298 private links
Tiens tiens, un avis intéressant sur le mode de développement MVC (Model View Controllers).
Pour qu'une désinfection sur un système soit efficace, il vaut mieux que le système en question ne sont pas celui qui fasse fonctionner l'antivirus ; en effet, certains virus ont la particularité de se charger avant le système d'exploitation, et ainsi d'être invisible, en modifiant le comportement de l'antivirus à la volée par exemple.
Via SebSauvage http://sebsauvage.net/links/?tH_64g
Dommage, je n'y crois plus...
détails de la fonctionnalité RNDC, liée à BIND.
@TODO:
TL;DR
(via Sebsauvage http://sebsauvage.net/links/?m4VrZw)
Oh yeah, un tuto complet pour installer son service Firefox Sync Server personnel.
Cool :-) (arf, Python 2.6, pô cool)
@TODO:
TL;DR
Un autre avis sur IR (voire un article descriptif ici http://links.thican.net/?LbsLIQ), avis plutôt négatif.
LLVM est un "cross-compiler" (compilateur multi-plateformes), donc un outil qui permet de traduire un langage de programmation (LLVM en a même plusieurs) en code "machine", sur plusieurs type d'architectures (d'où le terme "multi-plateformes").
En prime, il arrive à de meilleurs optimisations que les optimisations faites par un humain à travers son code.
Comme montré dans l'article, il se décompose en 2 étapes, qui se traduit par 3 représentations du même algorithme :
La première, avec son "frontend" ("front" en anglais pour "devant"), qui lui permet de "traduire" le code source dans un langage particulier en code intermédiaire LLVM, nommé IR ("Intermediate Representation", ou "Représentation Intermédiaire"). IR est ainsi le cœur de LLVM.
Puis, LLVM traduit son code IR (qui au passage est un code de bas niveau, comme l'est le code assembleur) en code machine avec son "backend" ("back" pour "derrière"). Et vu qu'il est un "cross"-compilateur, il peut donc traduire son code en code machine pour architecture x86 (la plus part des processeurs pour PC), PowerPC, ou ARM (ARM, l'architecture de grand nombre de smartphones).
Ainsi, grâce à LLVM, plus besoin d'écrire directement en langage assembleur, ce qui permet de l'exporter sur plusieurs architectures sans devoir le réécrire, et il serait même meilleur.
Si le résultat est réellement au rendez-vous de tout ce qui a été indiqué, je dis chapeau.
PS : pas contre, ne perdez pas de vu qu'un code a de meilleurs optimisations si on réfléchit à l'algorithme plutôt qu'à son code en lui-même, mais ça, c'est une autre histoire.
(via SebSauvage : http://sebsauvage.net/links/?9HLaMw)
EDIT: ici un avis divergeant sur la solution http://links.thican.net/?EyDTbA
Suite à mon petit article (https://links.thican.net/?OIlYuQ) sur le même principe (des requêtes HTTP), mais en utilisant telnet, voici donc une autre version bien plus propre, avec curl.
Pour rappel :
Utilisons donc quelques variables pour simplifier les envois (c'est du bash, au fait)
- host : c'est le nom de domaine du site web à contacter (pour utiliser avec la variable HOST),
- port : le port du serveur distant (port 80 très souvent, doit être un nombre entre 1 et 65 535 inclus),
- url : l'url de la page web à joindre, (sous la forme "/index.html", avec un '/' au début),
- getVars et postVars : la suite de variables qui vont être envoyées au serveur web, dans les requêtes GET et POST. (ces infos doivent être sous la forme "name=toto&code=2&update&field=text") ; dans une requête GET, postVars sera ignorée.
Attention : la variable "host" est obligatoire (le port est par défaut à "80" si la variable est vide).
Requête GET : curl --include http://${host}:{port:-80}/${url}?{getVars}
Requête POST : curl --include --data ${postVars} http://${host}:{port:-80}/${url}?{getVars}
That's it!
Concrètement, la différence entre telnet et curl, elle se réside uniquement dans votre démarche d'apprentissage et de compréhension.
Si vous voulez apprendre, modifier des données pour faire des tests, avoir un contrôle un peu plus poussé sur vos données, utilisez donc telnet.
Par contre, si vous voulez quelque chose qui fasse son boulot, simplement, avec le moins d'erreurs possible car maintenu à jour, sans prise de tête, tournez donc vers curl.
EDIT: une méthode, plus simple et plus "propre" à utiliser, avec curl : http://links.thican.net/?wGhHkw
Si vous avez besoin de tester un serveur web sans utiliser un navigateur web (pour ainsi mieux voir ce qui est concrètement reçu et envoyé), voici un début d'aide :
On va donc utiliser telnet, un logiciel qui permet simplement de se connecter à une machine distant, sur le port souhaité, et d'envoyer simplement des paquets TCP.
Utilisons donc quelques variables pour simplifier les envois (c'est du bash, au fait)
- host : c'est le nom de domaine du site web à contacter (pour utiliser avec la variable HOST),
- port : le port du serveur distant (port 80 très souvent, doit être un nombre entre 1 et 65 535 inclus),
- url : l'url de la page web à joindre, (sous la forme "/index.html", avec un '/' au début),
- getVars et postVars : la suite de variables qui vont être envoyées au serveur web, dans les requêtes GET et POST. (ces infos doivent être sous la forme "name=toto&code=2&update&field=text") ; dans une requête GET, postVars sera ignorée.
Attention : la variable "host" est obligatoire (le port est par défaut à "80" si la variable est vide).
Pour les requêtes GET, voici donc :
{ echo -n -e "GET /${url}?${getVars} HTTP/1.1\nHOST: ${host}:${port:-80}\n\n"; sleep 0.5 } | telnet ${host} ${port:-80}
Pour les requêtes POST, il faut rajouter l'info de la variable "Content-Type: application/x-www-form-urlencoded" (attention, d'après cette page http://stackoverflow.com/questions/4007969/application-x-www-form-urlencoded-or-multipart-form-data s'il s'agit d'autres formes de données, mieux vaut modifier le contenu de cette variable), voici donc :
{ length=$(echo -n ${postVars} | wc -c --); echo -n -e "POST /${url}?${getVars} HTTP/1.1\nHOST: ${host}:${port:-80}\nContent-Type: application/x-www-form-urlencoded\nContent-Length: ${length}\n\n${postVars}"; sleep 0.5 } | telnet ${host} ${port:-80}
Voilà, c'est tout, simple non ? ;-)
Remarques :
- "Pourquoi le temps de pause dans telnet (sleep 0.5) ?"
Pour des raisons qui m'échappent, telnet va semble-t-il trop vite, et il envoit donc un paquet TCP avec le flag "RST" (Reset), ce qui coupe court le serveur distant, ainsi que l'affichage (même si le serveur distant a envoyé les données, telnet ne les affichera pas). Du coup, il se peut que vous tomber sur ce problème, si le serveur distant est long à répondre (grosse requête, trop de trafic, etc.), il faut donc augmenter le temps de pause. - "Pourquoi mettre un '/' en plus au début dans l'URL ("GET /${url}") ?"
Les '/' en doublon ne sont normalement pas gênants pour accéder à une ressource (essayez donc des URL avec une suite de '/', ça ne devrait pas poser problème). Effectivement, si le serveur distant ne gère pas correctement ces '/' doublons, il risque de râler, mais en tout cas, si le premier '/' est manquant (exemple "GET index.html"), là, c'est sûr, la requête est mauvaise. Donc, autant en mettre trop que pas assez. ;-)
Petit lexique humouristique à l'attention des futurs informaticiens travaillant dans une ESN ("Entreprise de Service du Numérique", nouveau nom pour les SSII).
Les informations pour piloter un lecteur disque optique en langage C.
Et aussi http://www.teuniz.net/RS-232/ pour apprendre à utiliser le port RS-232 (le port série sur les anciens PC et équipement réseau).
Un peu de hardware, c'est toujours très bien. :-)
(via LeHollandaisVolant http://lehollandaisvolant.net/index.php?mode=links&id=20130613194557)
Guide de programmation sur les sockets, pour le language C, semble très complet.
Si vous avez besoin de sauvegarder des fichiers, en les mettant sur un serveur ftp distant, tout ça en tâche automatique, voici un script de mon cru (parmi tant d'autres, je n'ai pas cherché) qui peut rendre bien service :
(EDIT: Vu que les indentations ont sauté, voici une copie directe en téléchargement http://thican.net/~thican/backup-ftp.sh)
################################
!/bin/env bash
coding: utf-8
Script for saving files through FTP, to a remote host (for cron or CLI)
Thibaud CANALE
thican [at] thican [dot] net
2013-06-09
GPLv3
Parameters for FTP host (you only need to edit this 4 parameters)
hostFTP="" # "ftp.example.com"
userFTP="" # "foo"
passwordFTP="" # "bar"
remoteDir="./"; # remote directory, where to save files (like "backup")
you have to create the directory yourself.
tempIFS=${IFS};
IFS=$'\x0a\x00'; # useful to avoid problem with namefiles contening some
spaces (sic)
errorStatue=false;
Test if parameters for the connexion to the FTP host are all set.
if [ "x${hostFTP}" = "x" ] || [ "x${userFTP}" = "x" ] ||
[ "x${passwordFTP}" = "x" ]; then
echo "ERROR: at least one parameter for FTP connexion is not set. Exiting." >&2
exit 1;
fi
Test if at least one parameter is given.
if [ "x${1}" = "x" ]; then
echo "Missing arguments. Exiting." >&2
exit 2;
fi
Check if each ${args} is a regular file, to be upload to ftp server.
If yes, uploading it now.
If no, display a message error.
for args in ${@}; do
if [[ -f ${args} && ! -L ${args} ]]; then # symbolic files are ignored.
ftp -n ${hostFTP}<<END
user ${userFTP} ${passwordFTP}
put ${args} ${remoteDir:-"./"}/$(basename ${args})
bye
END
else
errorStatue=true;
echo "${args} is NOT a regular file. Skipping." >&2;
fi
done
#IFS=$'\x20\x09\x0a\x00'; # Reset of the default IFS (I don't care about the old one)
IFS=${tempIFS};
We check if ${errorStatue} containts some error.
if ${errorStatue}; then
exit 3;
fi
exit 0
################################
Ainsi, sauvegardez donc ce script dans /usr/local/bin/, par exemple, éditez donc les paramètres de connexion au serveur FTP dans le début du script, et utilisez-le avec cron, juste après vos tâches de sauvegardes automatisées.
Voilà, ce n'était pas plus compliqué que ça. :-)
Un outil pour fermer les connexions TCP…
Ohoh, tiens, enfin une bonne nouvelle contre les « Patent Trolls » :-)
Ohoh ! Le python entre dès la rentrée 2013 dans le cursus des étudiants en classes préparatoires, dans le cadre du programme de la matière informatique pour tous.
Bonne initiative. :-)
Voir ce livre pour apprendre : « UNIX : Programmation et communication » de RIFFLET et YUNÈS.
http://www.amazon.fr/UNIX-Programmation-communication-Jean-Marie-Rifflet/dp/2100079662/
Ce billet parle de 2 jeunes entrepreneurs, qui ont eu comme idée de proposer une météo locale, basée sur les informations de stations météorologiques installées chez Monsieur tout le monde et reliées à internet.
Ces stations météorologiques seront vendues à prix coûtant par eux-, justement, grâce à la technologie des imprimantes 3D, et ils créeront l'algorithme pour prendre en compte la position des données, fournis par ceux qui participent, ainsi que des données spécifiques à la région.
À la manière d'un réseau décentralisé, les données collectées seront ainsi analysée et rendues publique, seule l'algorithme sera secret pour pouvoir vendre d'autres données à des entreprises.
Bonne initiative.