khivapia a écrit 2562 commentaires

certains ont réussi à faire payer des gens qui ne souhaitent pas les regarder,
Ils ont réussi à te faire payer pour l'école (…), pour l'hôpital (…), pour des voies rapides et des aéroports (…)

Marrant de mettre sur le même point un pur loisir (regarder la télévision) et des infrastructures utiles et nécessaires à tous !

Qu'on ne ressorte pas l'argument de "s'il y a une guerre nucléaire, les enfants auront des cours à la télévision" : pas besoin de redevance télé pour ça, il suffit de réquisitionner les chaînes privées si nécessaire.

C'est un peu normal (et souhaitable) qu'une partie de l'impôt soit investi par l'état dans la culture.

C'est marrant d'ailleurs : prenons l'exemple de l'Opéra. Qui va voir de tels spectacles, sinon des gens plutôt aisés ? Du coup on subventionne les gens riches au travers de la culture, non ?

Ce n'est que très récemment que les certificats avec des clefs de cette taille sont bannis
Et dire que l'ANSSI française recommandait, pour le niveau de sécurité standard (le plus basique qui soit), de ne pas utiliser de clefs RSA de 1536 bits après 2010 !

Cf http://www.ssi.gouv.fr/site_documents/politiqueproduit/Mecanismes_cryptographiques_v1_10_standard.pdf

Ils en ont trafiqué, non ?

Marrant que la rhétorique US parle presque d'actes de guerre et visent la Corée du Nord, quand ils ont saboté volontairement le réseau d'un opérateur (d'importance vitale) d'un allié (la Belgique), dans un but d'espionnage. Si ça n'est pas un acte de guerre…

Oui.

https://www.google.fr/?gws_rd=ssl#q=baisse+du+prix+des+plaques+taxi

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.

Installe l'extension quickjava, et tu auras un bouton pour désactiver flash (mais seulement globalement). Tu pourras aussi désactiver java, javascript, etc. etc.

Concernant le prix, c'est visiblement top secret mais certains clins d'oeils échangés dont j'ai été témoin laissent penser que ça n'est pas donné.

Pourtant c'est un marché public, il y a dû avoir publication du résultat de l'appel d'offres et du montant financier de la proposition retenue !

Pas avec l'option "nosuid" (et "nodev" tant qu'à faire) dans les options de montage dans /etc/fstab

En reprenant un fichier de configuration 3.13 d'une distrib quelconque (Debian stocke les siens dans /boot/config*).
Éventuellement pour s'aider, utiliser un (vieux) paquet kernel-package ou make-kpkg, sans garantie qu'il soit adapté aux nouveaux noyaux;

Cela dit par curiosité quel est réellement l'intérêt de changer de noyau sans changer de distribution ?

… par exemple une image d'install de debian, ouvre une console sans reprendre l'install, normalement la racine de ton système installé est montée quelque part.
"chroot"e dedans, édite /etc/default/grub pour ajouter la commande de blacklist (le fichier est clair).
Ensuite il faut réinstaller grub à partir du système installé (et non pas du système d'installation, qui ne prendrait pas la modification en compte).
De mémoire c'est grub-install /dev/sdXXX (généralement /dev/sda ou sdb si tu n'as qu'un seul disque sur ton PC).
Il faut peut-être avoir monté le répertoire /dev du système d'install sur le système installé ton PC avec mount -o bind /dev/ /chemin/vers/racine/installee/dev

Guerre "totale" est peut-être abusif, mais en guerre économique contre le reste du monde, c'est clair.

Tu ne peux pas confondre comme ça les USA en tant que nation, que peuple, c'est à dire les américains, et l'administration américaine renforcée du complexe militaro-industriel — disons "le pouvoir".

Tu veux dire qu'il ne faut pas confondre la nation et l'État (US dans ce cas), c'est bien vrai.

Concernant l'espionnage par les américains (ou les autres), rappelons cette phrase de Henry John Temple, (L'Angleterre) [Un État] n'a pas d'amis ou d'ennemis (permanents), elle n'a que des intérêts (permanents).

En tous cas, la sécurité par la diversité ça aide ! (dans le logiciel libre, il y a une grande variabilité entre les versions des compilateurs utilisé par les différentes distributions, les versions des logiciels utilisés, etc. etc.). C'est plus difficile (quoique non impossible, loin de là) de faire un exploit portable sur plusieurs systèmes différents que d'en faire un pour un système particulier.

Une entrerpise est censée agir pour son bien à elle.
Pas tout à fait, n'est-ce pas le but de l'objet social que de dire à quoi sert l'entreprise pour la société ?

typedef union
{
__m128i trucmuche;
std::array<unsigned char, sizeof(__m128i) / sizeof(unsigned char)> chose
};

Ils ont monté la limite à 500 km je crois sur les versions récentes
Qui ne sont pas encore arrivées sur FDroid (qui en était hier soir à la 1.8.3 quand la 1.9 est sortie depuis au moins 2 semaines).
Cela dit ça s'améliore, ça fait plaisir à voir.

Oui ça paraît logique. Ma remarque est à côté de la plaque, je ne connais pas la façon de publier en physique.

+ onduleur + clim
Onduleur: ça dépend vraiment où tu habites, mon expérience est que l'arrivée électrique est très stable.

Clim: chez toi tu n'utilises pas ton ordinateur l'été ?

Il me semble que les développeurs d'OSMAnd recommandent de ne pas utiliser le planificateur de trajet pour des trajets qui dépassent 200 ou 300 km directs.

Le robot a étudié le magnétisme de la comète, ils ont dû trouver le pôle Nord local :-)

D'ailleurs l'ESA parle bien de l'est en commentaire de la photo.

car un travail effectué par un non-expert doit de toutes manières être refait par un expert avant de pouvoir être considéré comme fiable
C'est le rôle du reviewer dans une publication, mais n'importe qui peut soumettre normalement…

1 semaine (MS14-066) vs 24h(Heartbleed), ça change beaucoup de choses!!
Ça dépend de si MS14-066 connaissant les sources est aussi facile à exploiter qu'Heartbleed. Sinon ça veut juste dire qu'Heartbleed était une faille de plus grande importance.

Sauf que pendant ce temps là, t'es à pwal.
Honnêtement, c'est un choix.

Pour les systèmes les plus exposés, la priorité doit aller à la sécurité au détriment, le cas échéant, de la disponibilité (puisque de toutes façons, une fois compromis la disponibilité n'est plus assurée non plus, et c'est toujours plus compliqué pour s'en débarrasser). Donc la pratique saine est de déployer le correctif de sécurité, en parallèle des tests pour sa validation qui fournira peut-être un deuxième patch dans la foulée, de fonctionnalités cette fois là. Ou alors c'est un choix assumé de laisser une faille ouverte sur un système exposé. On ne peut pas tout avoir !

En pratique, ça veut aussi dire que quand si le système est très exposé et critique, il faut faire des tests élaborés supplémentaires avant de déployer pour réduire encore plus la probabilité de découverte de failles (OpenBSD n'a connu que 2 exploits distants en 10 ans, c'est donc possible !), et ajouter de la variabilité dans le code déployé pour limiter la portée d'un exploit développé en vitesse.

Au final, déployer des programmes bourrés de failles peu testés d'un point de vue sécurité sur des systèmes très exposés et critiques est un choix qui coûte moins cher au déploiement, mais qui a des conséquences.

révéler la faille quand le patch commence (donc pas encore fini de) à être distribué est problématique,
Oui, d'où ce que disait Jiehong justement, de ne "la révéler que quand elle est intégrée, et distribuée !"
je pense que "Tu devrais vraiment lire le journal le commentaire avant d'écrire un commentaire" auquel tu réponds…
Il est bien possible de ne révéler la faille qu'une fois que le correctif est largement déployé (ce qui doit pas prendre longtemps, comme pour tous les patches de sécurité). Après si déployer le patche lui-même donne (un peu) plus d'information sur la nature du correctif quand le code source est ouvert, sans détail supplémentaire il est noyé dans la masse des patches de sécurité du jour, dont la facilité d'exploitation est extrêmement variable. En outre de toutes façons l'exploitation dépend toujours du code assembleur réellement utilisé par la cible ; dans cette course, c'est une question d'heures (soit pour déployer le correctif, soit pour mettre au point et déployer une attaque). Les cibles les plus faciles (les plus exposés) pour l'attaquant sont celles qui, étant justement exposées, ont dû mettre en place un déploiement des correctifs rapide !

"mal standardisés et sujet à interprétation en fonction de l'outil utilisé."
Pardon ? Quand on connaît le prix de fonderie d'un composant, on a envie de dire que le langage qui permet de le concevoir doit être bien standardisé pour éviter la classe de bugs associée à des interprétations variables ! Ça veut dire que ce n'est pas vraiment le cas ?!?