wismerhill a écrit 2605 commentaires

Quand je vois aussi qu'on parle de /dev/random, au bout d'un moment, c'est un bête générateur congruentiel linéaire (qui se casse presque à la main), /dev/urandom est un peu mieux.

Heu, c'est le contraire, /dev/urandom c'est la version rapide et /dev/random c'est la version qui attend de récupérer suffisamment d'entropie pour générer les octets suivants.

Il est vrai que pour qlq'un qui recherche un générateur de nombre aléatoire, le premier réflexe est d'utiliser Rand() qu'on a par défaut sous c (et C++) dans différentes bibliothèques (glibc entre autres).

J'ai pas l'habitude de coder en C, mais pour de grand volumes de données mon premier réflexe aurait plutôt été /dev/random (pas urandom dans ton cas puisque tu parle de données non corrélée). Un petit coup de dd et tu as la quantité de données que tu veux.

Pour ceux qui ont raté la phase de transition de ce début d'après-midi
http://peach.blender.org/wp-content/themes/bunny/graphics/ee(...)

Hihi
Regardez le site juste maintenant
http://peach.blender.org/

someting's happening
:-)

Normal, seul root peut ouvrir des ports <1024, essaie de le démarrer sur un port non privilégié (et non bloqué par l'hébergeur).

C'est ridicule comme test, la seule chose qui distingue deux dispositions de clavier, c'est justement un placement plus ou moins optimum des touches suivant l'usage, et là il nous testent des lettres différentes pour que la position des touches soit la même?

C'est sur des tests sur des vrai textes après un apprentissage réel d'utilisation des dispositions de clavier qu'une comparaison aura de la valeur. Et dans ce genre de cas j'ai plutôt vu (pas d'expérience personnelle) des gens parler d'une accélération de la frappe et une moins grande fatigue des mains après quelques semaines d'apprentissage du dvorak.

C'est dommage qu'il n'y en ai pas (encore?) un de référence pour le français (à ma connaissance il y a plusieurs dispositions légèrement différentes).

Je confirme je l'ai déjà fait plusieurs fois aussi, je vérifie juste que je peux encore me connecter avant de fermer la session encore ouverte.

Mais pour le problème d'Erwann, c'est peut-être simplement parce que la clé du serveur a été regénérée suite à la mise à jour (j'ai eu le cas sur tous mes serveurs debian) et que ton client ssh (local) a encore l'ancienne clé publique et croit que c'est une tentative de hack (suivant la configuration il peu juste avertir ou complètement refuser la connection).
Regarde dans le fichier ~/.ssh/known_hosts et supprime la ligne correspondant à ton serveur (si tu ne trouve pas tu peux supprimer tout le fichier, mais tu perdra les éventuelles configuration d'autres serveurs), il devrait ensuite te redemander d'accepter la nouvelle clé.

Bien dit!

La version 0.7 était déjà bien jouable, j'ai pas encore testé cette nouvelle version mais ça a l'air vraiment bien.
Ils se sont placé la barre très haut avec un mégahit comme worms, ce qui amène des critiques mitigées de toutes les personnes qui vont comparer (quoique je vois surtout ici des critiques constructives et des gens impatients que ce soit encore meilleur), mais ça les motives d'autant plus à faire un jeu formidable.

Bravo aux développeurs!

J'ai déjà fait une installation distante (Même réseau du dournisseur d'accès, mais depuis nos bureaux à quelques dizaines de km du datacenter) avec un lecteur CD virtuel monté depuis ma machine via ilo, ce n'était qu'un CD net-boot debian, mais ça a pris une plombe pour en arriver au moment où il n'a plus besoin du CD, parce qu'il simule le périphérique en mode block et c'est contre-opmimal pour des accès réseau distant sur un réseau pas très rapide avec une latence relativement élevée.
Et il est arrivé plusieurs fois que ça ne marche pas sans raison apparente avec une image ISO pourtant bonne.

Donc c'est pratique pour ne pas devoir se déplacer, mais t'y gagne pas beaucoup de temps, juste du confort ;-)

Juste pour ce point en particulier:
(il y a de la doc, mais c'est la théorie du "bazaar" : elle est disséminée un peu partout sur la toile, non cohérente etc...)

http://fr.wikipedia.org/wiki/Distribution_linux
c'est un concept super innovant où des volontaires regroupent plein de trucs intéressants pour un système Linux.


La seule programmation que j'ai fait sous windows (du temps où je l'utilisais encore), c'était avec du visual basic, donc je suis un peu traumatisé et forcément pas objectif.

Hum, mais s'il faut une license MSDN (ou autre, j'en ai aucune idée) pour comprendre ce que font les fonctions noyau (qui sont forcément utilisées par le driver) ben t'es pas très avancé avec les source du driver.

L'API interne du noyau windows est-elle "librement" accessible?
Et si oui, qu'est-ce qui me prouve qu'elle est complète?

Le problème du C++ ce ne sont pas les fonctionnalités Objet de haut niveau, mais plutôt qu'il faut absolument continuer de supporter toutes les fonctionnalités de bas niveau du C et (essayer de) s'arranger pour que cela s'agence correctement pour les programmeurs pervers qui s'amusent à mélanger les deux dans un même projet.

Si personne n'a fait de drivers pour le super-matos-dernier-cri, que tu aide ou pas, ça ne changera rien : ça ne marchera pas.

Parfois si, parce beaucoup de matos lowcost intègre en fait un composant très commun et déjà supporté, et il suffit parfois d'ajouter un identifiant de constructeur/produit (pour le PCI ou l'USB) et de recompiler le driver (générique!) pour que ça marche (c'est du vécu pour un appareil photo canon et un récepteur dvb-t, tous deux USB).

Si tu veux faire pareil sou windows, par exemple parce que ton matos à un driver win98 mais pas XP, tu as éventuellement la possibilité de décompiler le vieux driver et l'adapter (et il faut plus qu'un geek pour ça), ou dans la même idée, prendre un driver récent d'un autres constructeur (pas générique) dont tu sais qu'il utilise le même composant en interne et essayer de le bluffer pour qu'il marche avec le tien (probablement décompilation aussi).

Ta théorie est jolie, mais le gars s'en fout de la théorie :

Je ne parlais pas de théorie, mais bien de concret justement.

il veut que ça marche, et il voit que ça marche sous Windows, et pas sous Linux, bien que tu y passes 1, 10, 100 heures dessus.

Tu biaise le débat, moi je comparais le cas d'un truc qui marche pas sous Linux à un truc qui marche pas sous windows (par désintérêt du constructeur/éditeur dans les deux cas) et je dis que la situation dans ce cas-là est plus favorable sous linux, même si tu n'est pas développeur.

Sans aide du vendeur du matos, point de salut,

Faux, et insultant pour tous les développeurs du libre qui développent des drivers par reverse engeneering du matos pour lequel le constructeur n'en a rien à faire (cf mes deux exemples plus haut).

et pour cette aide il faut être nombreux, le nombre fait la force.

Exact, et il y a beaucoup plus de développeurs motivés pour faire des driver de matériel du côté du libre. Tu en connais toi, des développeurs windows qui vont aller développer un driver windows pour du matos pas/plus supporté par le constructeur?

C'est un argument qui se tient, j'en conviens.
Mais 99.999% des gens te répondront "Rien à foutre, je veux juste que ça marche".

Ce à quoi moi je répond: Si t'es sous Linux et que ça marche pas je t'aiderai à le faire fonctionner (je l'ai fait de nombreuses fois à des install parties), sous windows tu pourra toujours attendre que microsoft (ou autre éditeur proprio, faut pas toujours taper sur les mêmes) veuille bien se soucier de ton problème.

Tu peux installer du X11 dans MacOSX, ce n'est pas pour autant que tu aura le focus qui suit la souris, puisque c'est une fonctionnalité du gestionnaire de fenêtres.

Petite correction: ubuntu est la distribution et canonical la société commerciale.

Je réfléchis.

Si je trouve une grosse faille dans wuftpd (ok, l'exemple est facile), je vais surement en informer les développeurs, mais je vais aussi prévenir les gens que je connais de ne pas utiliser ça parce qu'il y a une faille dedans (pas besoin de dire laquelle).

Et comment écrirais-tu un test case qui vérifierait que les clé générées sont bien aléatoires?
Tu en génère 1e15 et tu vérifie qu'il n'en a pas généré plus d'une ou deux d'identiques?

Personne ici n'explique ce qu'il faut faire, nos arguments sont justement qu'il n'y a pas une bonne façon de faire mais qu'il faut réfléchir à la meilleure chose à faire au cas par cas suivant la faille en question.

(but you can leave your hat on)

Tout à fait d'accord avec toi.
Mais moi je suis développeur (et accessoirement administrateur de serveurs par la force des choses (PME bis)) et on ne me consulte pas pour les évaluations de budget (au-delà de simplement me demander combien de temps prendrait tel développement).

Ça dépend des cas, parfois il y a un workaround simple pour éviter la faille en attendant une vraie correction.

Par exemple pour un serveur ftp (qui est une faille en lui-même), tu peux tout simplement le couper, en installant éventuellement un autre si le service est critique.

Pour une faille du sous-système sftp de openssh tu pourrais simplement désactiver celui-ci le temps de la correction, scp (et fish) est toujours là pour les transferts de fichiers.

Il y a probablement beaucoup d'autres exemples où quelques mesures simples peuvent rendre une faille de sécurité sans gravité en attendant une vraie solution.

> Comme il connait cette faille si elle n'est pas public ?

Tout simplement parce qu'il l'a constatée par hasard (ça arrive) ou suite à un audit de sécurité interne (ça arrive aussi) ou encore parce qu'il a constaté une intrusion/utilisation abusive de son serveur par un cracker qui aura découvert la faille à sa façon (ancien employé qui a introduit en douce une backdoor, vol de code).

Et là je ne parle que de logiciels fermés.

Pour du libre, tu peux faire un vrai audit du code (il y a des boîtes qui font ça) et tomber sur des trucs dont l'upstream ne s'était pas rendu compte.

Je parle d'hébergement d'entreprise, où on loue un rack avec de la bande passante pour aller mettre nos propres serveurs. On aurait pu prendre des serveurs avec ce genre d'interface, mais c'est plus cher (PME inside) e tça demande deux fois plus d'IP par machine.

Non, je parle d'avoir une console directe sur le serveur, il faut avoir du matériel et une connection réseau en plus pour gérer ça.

Tout le monde n'a pas les moyens de se payer ce genre de service (la bande passante est déjà assez chère)