298 private links
EDIT: hé bien non, je n'y suis pas allé, pas les moyens, trop de boulots.
@TODO:
TL;DR
Malgré les progrès dans vérification et l'attention aux erreurs possibles, la puissance des ordinateurs démultiplie aussi le nombre d'erreurs, du coup, elles sont plus nombreuses pour un laps de temps plus court.
TL;D(finish to)R;
Visite photos et commentaires dans un NRA (Nœud de Raccordement Abonnés) du PER92 dans le Levallois-Perret.
Là où c'est intéressant, c'est le déploiement des technologies fibres, la technologie pour le THD (Très Haut Débit).
Ce que j'aime bien les articles de Sam&Max, en général, lorsqu'ils parlent de programmation.
J'avoue, son côté trop permissif n'est pas un avantage, mais carrément un inconvénient, en tout cas à mon goût, car les premières fois où j'ai eu à toucher à du JavaScript, c'était erreur sur erreur, avec des erreurs absurdes, là où en C, il suffit simplement de savoir ce que doit contenir une variable pour comprendre ce qu'il va y être stocké.
Du coup, je suis en quelque sorte devenu allergique à JavaScript, et pourtant, avec PHP, les langages du web sont ceux qui rendent le plus rapidement un résultat visuel avec le minimum d'outils, contrairement aux autres, grâce aux navigateurs web.
Ah, ben voilà que je retrouve un article expliquant la différence entre le mode "big endian" et le mode "little endian" (en français respectueusement, "grand boutiste" et "petit boutiste").
En résumé, en "big endian", l'octet et le bit de poids fort sont en premier, notés de gauche à droite. En little endian, c'est le contraire (attention tout de même à la représentation en mode atomique de 2 octets, voir le paragraphe "Little endian" http://fr.wikipedia.org/wiki/Endianness#Little_endian)
Et pourtant, avec ses quelques désavantages (c'est mon avis personnel), le little endian est utilisé par l'architecture x86, l'architecture la plus utilisé pour les PC.
Pourtant, ça m'est arrivé d'utiliser le mode "little endian" pour l'écriture de polynômes dans les calculs formels, mais pour ce qui est de la représentation des octets, je ne trouve pas que ce soit une bonne idée, vu que par définition, un octet est un bloc de 8 bits.
Il me reste à savoir maintenant comment sont stockées les données sur les supports de stockage, ainsi que dans les systèmes de fichiers.
Bref, une vraie galère, Gulliver ne s'attendait pas à nous ramener un tel problème. :-)
Encore un autre article qui m'intéresse bien, j'irai m'y approfondir (j'ai l'impression de n'avoir rien appris à l'école …)
int setsockopt(int sockfd, int level, int optname,
const void *optval, socklen_t optlen);
v6only = false;
setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, (v6only ? &true_opt : &false_opt), sizeof(int));
TL;DR
sauvegarde ici : http://thican.net/~thican/cpumemory.pdf
Alors là, mais si la police australienne s'y mets, c'est du bonheur. :-D
Non, sérieusement, se retrouver en plein milieu d'un désert, à cause d'un mauvais itinéraire, ça devient vite dangereux, sans eau ni nourriture, comme le fait justement remarquer la police australienne et Numérama.
Voilà, de plus en plus, on fait confiance aveuglément à tous ces outils informatiques, mettant maintenant de plus en plus notre vie en danger.
Pour expliquer de façon plus simple les codes erreurs de HTTP :-D
Pour les infos concrètes ensuite :
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
Aahh, d'accord.
Même si on me l'avais déjà dit, ou l'avais déjà lu quelque part, c'est plus simple de retenir ainsi.