Convention REST : le nom des ressources est au pluriel et puis c'est tout.
Pour GET et DELETE, c'est assez clair :
GET resources (accès à toutes les ressources)
GET resources/123 (accès à la ressource 123)
DELETE resources/123 (supprime la ressource 123)

Même en omettant la question du POST / PUT, ça reste bizarre pour la création /update :
POST resources (créé / modifie une ressource, ou une liste de ressources)

Moi j'aurai tendance à faire POST resources pour une liste, POST resources/123 pour une ressource.

Excellent petit outil pour browser des repo Git via le Web.

Pour lister les bibliothèques nécessaires à un exécutable
ldd <exec name>

Pour connaître le paquet contenant une bibliothèque :
dpkg -S <lib name.so.x>
Puis pour installer le paquet correspondant :
apt-get install <paquet name>

Eventuellement avec un suffixe pour du 64bit (amd64) du 32bit (i386), par exemple :
apt-get install <paquet name>:i386

En ayant au préalable ajouté cette ardchietcture :
dpkg --add-architecture i386

Une doc Autosar : " The use of a power of two for the number of failed verifications is only for obtaining a more succulent mathematical expression." !!!

TBR

Si cette information est véridique (ce qui n'est pas impossible vu le personnage), peut-être que les chrétiens ne seront plus les seuls à critique Creflo Dollar désormais !
Cela dit puisque l'article n'est pas daté (raf !) et que je n'ai pas envie d'écouter tous les prêches d'avril de mister Dollar, je ne peux en dire plus.

Cool ! Plus de détails sur le hack récent de la Jeep. Je me demandais comment ils avaient accéder au CAN à distance et je ne comprenais pas que Chrysler ait pu rendre le CAN accessible via le réseau même en le sécurisant. ça me semblait aberrant !
En fait c'est plus fourbe que ça ! C'est une suite de bugs et de failles. Ils peuvent passer par le WiFi du véhicule (un petit bug de sécurité sympa), mais ce n'est pas disponible sur toutes les Jeep. Alors ils accèdent plutôt à la Jeep directement via le réseau (3G ou autre ?) auquel elle se connecte. L'article n'expliquait pas de quelle manière. ça leur donne accès à la TCU (telecommunication unit) et donc à pas mal de trucs non critiques comme la musique, etc... (je pense qu'ils accèdent en fait aux même infos que si on se branche sur la prise OBD-II du véhicule) Jusqu'ici, l'attaque reste donc limité car ils n'accèdent pas véritablement au CAN. C'est quand même embêtant. Par contre, ils parviennent à accéder à une des machines qui lit des données sur le CAN. Ils sont parvenus à remplacer le firmware de cette machine et ils se sont rendus compte qu'ils pouvaient aussi écrire sur le CAN et donc potentiellement modifier le comportement du véhicule !! Reste à découvrir la messagerie CAN... et le tour est joué !

Je n'ose imaginer le temps nécessaire pour :

• réussir à trouver les failles pour rentrer dans le véhicule
• découvrir qu'une machine est connectée au CAN
• écrire le firmware qui va bien et réussir à l'installer
• peut-être le plus long : comprendre la messagerie CAN (qui est propre à chaque marque et généralement à chaque véhicule) pour savoir quoi correspond à quoi. Généralement le système est suffisamment intelligent pour détecter des comportements étranges et corriger les erreurs ou s'arrêter purement et simplement. Il faut donc bien comprendre le système pour parvenir à prendre le contrôle du véhicule.

(via http://shaarli.callmematthi.eu/?pLLZMQ)

Depuis qu'un serveur a été mis à jour sous Windows Server 2012, mon petit rdesktop sous Debian ne me permet plus d’accéder en remote desktop. Microsoft a modifié légèrement le protocole (sécurité différente).

Je suis donc passé à remmina qui fait parfaitement le job. L'interface est même plus intuitive.