Blackknight a écrit 1237 commentaires

Donc je raconte pas que des conneries.

N'empêche qu'il est sorti que peu de temps avant son remplacant Win XP Pro. Quelque part, il est mort né.

Si j'ai bien compris, le systéme anti-piratage peut se raprocher d'un cdr raté. Dans ce cas, ma chaine pourra-t-elle le lire?

Tiens, c'est marrant, je me rapelle que sur les Amstrad CPC 6128, il y avait des éditeurs qui s'étaient amusés à flasher certaines pistes des disquettes pour les rendre incopiables. C'était le soft qui pilotait les lectures en évitant les fameuses pistes incriminées. Comme quoi, y a des idées qu'on la peau dure ;-)

D'une part, tout cela est déjà passé dans les commentaires de la news précédente (http://linuxfr.org/topic/Microsoft/7761,0,0,2,1.php3(...) ) mais plus important, cela n'est plus vrai, le serveur ayant brusquement migré vers IIS (enfin, ils n'ont peut-être que changé les headers http, ça va plus vite).

J'ai toujours des doutes sur les bench issu du site intéressé. Le plus bel exemple est quand même la série de bench chez MySQL (http://www.mysql.org/information/benchmarks.html(...) et http://www.mysql.com/information/crash-me.php(...) ), je la trouve franchement exceptionnelle. Ils n'ont vraiment pas peur chez MySQL, comparer MySQL sur les insert dans les grandes tables avec un Oracle, c'est osé (surtout que quand on vérifie pas les contraintes d'intégrité de type clé étrangère).
Sinon, désolé mais j'ai pas de résultat à te fournir sur Prelude et Snort.

En plus, moi ch'sais même pas comment qu'on fait pour l'utiliser comme outil de cracking. Si c'est juste à cause du scan, y a pas de quoi s'exciter.

que ce soit seulement une introduction. Bien que l'on trouve tout plein de docs sur le web sur SNORT, les docs Linuxfrench sont généralement de bonne qualité (notamment l'article sur les BDD avec PostgreSQL http://www.linuxfrench.net/rubrique.php3?id_rubrique=102(...) ). Je trouve quand même que c'est un peu court.

A savoir quand même :
La quatrième édition de ce bouquin est pour bientôt, Greg l'ayant presque terminé. Le bouquin devrait être dans les bacs sous peu alors un peu de patience est de rigueur pour profiter de la mouture 2002 de cet excellent livre.
source : http://daily.daemonnews.org/view_story.php3?story_id=2783(...)

Tu peux aussi utiliser http://www.freenet6.net(...) . Ceci dit, tout ça, c'est encore du tunneling mais c'est vrai que c'est déjà pas mal.

Ben à première vue, non !! Je suis en train de télécharger les 11 Mo du source (juste pour regarder ce qu'il y a dedans hein , pas pour le compiler, je suis pas fou)

Tout à fait d'accord. L'IPSec n'est pas forcément quelque chose de très simple à mettre en oeuvre en IPv4. Par contre, cela fait partie de l'IPv6. Perso, je trouve que l'IPv6 a retenu quand même pas mal de leçons de l'IPv4 notamment en matière de sécurité et de routage.

Il me semble que l'IPv6 avait pour principal but de pallier aux problèmes d'adressage.
Dans ce cadre, il est logique que l'on ait gardé des fonctionnalités qui existaient dans l'IPv4 genre DHCP et qui ont été portées en IPv6. Mais quand on désire faire évoluer, on essaye de gérer une simili-compatibilité avec l'existant tout en ajoutant de nouvelles choses comme le neighbour discovery. De toutes façons, ce dernier qui te semble plus compliqué a été mis en place pour cacher en partie la complexité même des adresses en IPv6. De plus, il prend en compte le concept de portée réseau ce que le DHCP ne sait pas faire. En plus, le neighbour discovery ne sert en aucun cas à fournir des adresses comme DHCP mais à remettre à jour les tables de routage.
tout ça pour dire qu'IPv6 est une évolution d'IPv4 qui n'est pas forcément plus simple.

Pour ce qui est de ta remarque sur les routeurs Hardware vs Software, j'ai rien de particulier à dire si ce n'est que ça se défend et ça se discute :
Faut-il un hardware hautement spécialisé qui traitera les infos à fond les manettes qu'un petit PC à tout faire. On trouve le même genre de question entre les RAID Soft et Hard

Bien sûr, le tunneling, c'est une chose mais c'est pas encore de l'IPv6 pur. Des tunnels en règle générale, il y en a des tonnes (SLIP, PLIP). Ce qui serait intéressant, ce serait de pouvoir virer cette surcouche parce qu'après tout, cela ressemble plus à une encapsulation applicative qu'autre chose.
Pour ce qui est des applis, c'est quand même là que ça bouge le plus et c'est tant mieux. Mais faut quand même pas oublier que la migration sera surtout matérielle (routeurs entre autres).
Ce que je voulais dire dans mon commentaire précédent, c'est que la généralisation de l'IPv6 ne passe pas par les Geeks qui ont les compétences pour passer leur machine en hybride IPv6 mais pas l'ensemble du réseau.

Tiens c'est rare d'entendre parler d'IPv6 !! Alors dans le Monde qui n'est quand même pas un journal spécialisé, je trouve ça quand même assez intéressant.
Pour ce qui est d'IPv6 en lui-même, je trouve qu'il n'y a pas beaucoup de monde qui fait d'effort pour son déploiement. Les ISP ne proposent rien (à ce que je sache) et les points d'entrée pour le commun des mortels sont sporadiques.
Enfin, il faudra quand même bien s'y mettre !!

Quelque part, on a eu du bol parce qu'il y avait des potes à Georges Lucas qui lui avaient conseillé de faire une nouvelle religion basée sur la "force" ! Bonjour les dégats aujourd'hui, on aurait plein de petits Dark Vador (Darth Vader pour les anglophiles).
En plus, contrairement à Hubbard, c'est pas un ringard sans succès.

Sous NT même sans le while, ça part au tas donc, ça donne ça :
#include <stdio.h>

int main (void)
{
printf("\t\b\b\b ") ;
return EXIT_SUCCESS ;
}

Y a même moins de \b mais j'ai quand même laissé un EXIT_SUCCESS pour faire propre.

Ouais mais même en renseignant le champ MX, ça merdoyait.
Peut-être faut-il le renseigner avec l'IP plutôt que le nom ???

dyndns.org, par exemple, permet de faire (presque) tout ce qui est faisable avec un "vrai" nom de domaine
Et comment tu fais pour déclarer ton propre serveur de mails ? Perso, ça marche pas des masses.
Par contre, pour tout le reste (cvs, ssh, ftp et telnet (!? Non, je rigole)), c'est vrai que ça fonctionne sans pb.

Tout le monde aura compris que c'est "extensible à souhait".
Petit ajout tout de même :
La page PicoBSD précise qu'il s'agit d'un FB 3.0 ou 2.5. En fait, à chaque release du noyau, on trouve dans les sources du système, tout ce qu'il faut pour fabriquer un Pico donc la version n'est absolument pas figée en 2.5.

En fait, j'ai même pas lu l'article étant donné qu'il existe sous FreeBSD un projet qui s'appelle PicoBSD et dont le but est de faire tenir une passerelle firewall sur une ou plusieurs disquettes, on est loin du CD-ROM quand même.
Du coup, je vous file même le lien :
http://people.freebsd.org/~picobsd/(...)
Comme quoi, des fois, on fait beaucoup de bruit pour pas grand chose. Certes, la configuration n'est pas des plus aisées mais bon, ça se fait. En plus, c'est extensible à soit grâce aux fichiers de conf du crunchgen.
Voilà, c'est tout ce que j'ai à dire.

Et bah, ça m'a l'air assez complet. Certes, je ne suis pas comptable mais on peut gérer pas mal de trucs.

Il n'y avait pas qu'entre les sociétés que c'était la guerre. Les utilisateurs étaient tout aussi véhéments. Ceci dit, c'est effectivement le marché qui a détruit ces deux bécanes.

Je pense que le doux rêve, c'est d'arriver à unifier les deux communautés qui se sont formées autour de chacun de ses environnements. D'ailleurs, tu en es un parfait exemple en disant que RMS veut profiter de KDE pour remettre Gnome à niveau.
On dirait une vieille guerre qui avait sévi au début des années 90 entre Amiga et Atari. Résultat : les deux ont disparu.

Et Wine, ça utilise la SDL ???
Si oui tant mieux, si non, je dirai la même chose que d'habitude : wine, c'est pour copier Windows pas pour coder en natif sous Linux.

Je sens que tout le monde ne va pas m'aimer là-dessus.

C'est vrai que techniquement, il y a beaucoup de choses qui ont été refondues mais quelque part, c'est assez historique comme décision : tout ce qui avait amené au 4.4BSD-Lite, le procès, les années de recodage pour garder le système libre, tout ça pour libérer le code au bout du compte. Comme quoi, l'histoire est assez ironique : AT&T avait voulu garder une main mise sur le code BSD pour finir presque 20 ans plus tard par le libérer.
C'est surtout cet aspect là qui est interessant plus que l'aspect technique.