Babou a écrit 179 commentaires

Rhoooooooo, comme ça dénonce !!!!!!

Mais c'est tellement bon !

L'IUT, c'est bien là où tu peux apprendre des choses en info (et pas que) si t'y connais rien, te perfectionner si tu connais déjà un peu, le tout en passant deux ans de vacances (j'ai fait le DUT Info à Bayonne, plage à 10mn du Dept. Info de l'IUT ;-).

Et c'est pas bien dur de finir dans les premiers en prime si tu bosses assez. Après, tu peux intégrer des écoles d'ingénieur, même de bonne réputation, comme ENSEEIHT, ENSEIRB (mon cas, comme d'hab, là je rabache :). Bon pour Centrale Paris ou X, là faudra ptêt repasser par contre.

Bref, cinq années d'études sup où je n'en ai finalement chié qu'en première année ENSEIRB (pas mal de théorie du signal (ouais, je sais, c pas de l'info ça) et autres trucs de matheux pour ceux venant de prépa).

On peut apprendre des trucs, tout en prenant des vacances, et ce pendant des années. C'est ch'ti pas beau la vie d'étudiant ?! //nostalgie

T'as d'autres écoles qui ont des filières informatiques. Exemple: quelques ENSI: ENSIMAG, ENSEEIHT et l'ENSEIRB (bah en plus j'en sors de cette dernière ;-).

Par contre, c'est vrai, ne rentre pas qui veut à l'ENSIMAG ou l'ENSEEIHT. L'ENSEIRB c'est déjà un peu plus commode. Faut bosser pour accéder à ces écoles. C'est pas en sortant le chéquier et en se payant se diplôme qu'on devient ingénieur. C'est en bossant.

Après, je suis convaincu qu'il a des personnes qui sorent de l'EPITA avec des réelles compétences d'ingénierie en informatique, mais bon, j'ai vu il y a quelques années (comme participant à Prologin), j'ai aussi entendu. Et je suis très content de pas y avoir remis les pieds.

Voilà mon opinion qui va se prendre des -1 dans pas longtemps, je le sens venir ... (pitié non, je cite des écoles d'info publique ... :)

Bon, j'suis un peu concerné donc pas tout à fait objectif, mais le thème sécu va vraiment être intéressant. De sacrés pointures seront présentes. Par contre, il faudrait que les autre thèmes se bouge le c.., ça donne pas envie pour le moment . . .

http://lsm.abul.org/organisation/practical.php3?langnew=es(...)

Dans le menu de la version espagnole, ya le nom de François, qqn s'est planté dans une balise XML on dirait.

MDR
PTDR
EDRPEDSLT ( <- Explosé De Rire Plié En Deux Sous La Table ;-)

T'as vu les ingés que t'as à l'UPPA aussi ? Avec Michel c'est clair que j'y vois mal des serveurs sous autre chose qu'un Unix ;-)

En plus ces ingés sont carrément abordables, comparés à d'autres facs/écoles :|

> Il se trouve qu'il est infiniment plus rentable d'accroître la puissance de calcul disponible (+100% en 18 mois ?) que de "perdre" son temps à optimiser (+10% en deux ans ?).

Tu y vas un peu fort avec tes 10%. Dans le domaine du calcul scientifique, il faut savoir que l'essentiel du code est écrit par des non-informaticiens (physiciens, météorologues, chimistes ...) qui n'ont pas souvent connaissance des techniques et technologies utilisables (par exemple les BLAS avec lesquels on peut réduire par 10 ou plus des temps d'exécution). Il y a effectivement des codes bien difficiles à améliorer pour un gain faible, mais il existe encore bon nombre de codes donc les performances restent faibles, par méconnaissance des outils, ce qu'on ne peut pas reprocher à des non-parallélistes, ce n'est pas leur job. Et vu le gain qu'on peut avoir en ayant cette connaissance, reconnaît que ça vaut la peine de s'y intéresser de très près.

Il y en a des chercheurs qui se penchent sur l'optimisation des algos, mais il est bien rare d'arriver à tirer plus de 60% de puissance de crête d'un processeur, car les volumes de données sont gigantesques (on compte en centaines de giga et en tera octets). La mémoire est encore "à la traine" derrière les processeurs, quant aux disques, n'en parlons même pas. D'ailleurs, concernant la mémoire, sur les gros calculs, ce n'est pas 2 ou 4Go ** par noeud ** qu'il faudrait, ce sont peut-être 100Go. Il y a de très fortes contraintes technologiques sur tout ce qui se trouve autour du processeur pour arriver à pleinement en tirer profit.

NB: quand je dis 60% de puissance de crête, aucun rapport quand avec top, vous voyez votre processeur à 0% d'idle.
re-NB: qu'est-ce qu'un noeud pour ceux que j'ai perdu en cours de route ? Et bien pour parler simplement, une carte mère avec de 1 à 16 processeurs grand max (couramment 4 ou 8 sur les gros calculateurs type SP3). Donc en réunissant tous les noeuds, on a nettement plus de mémoire, mais par noeud, on a toujours pas assez. Pourquoi pas plus de processeur par noeud ? Problème d'architecture, de bus mémoire, de cache, de ... c'est un tout. Et pas un simple.

Tu es un peu vache. Il arrive régulièrement que apt-get dist-upgrade nécessite intervention manuelle *** pour la version unstable ***, manip des scripts post-install, etc ... car petit bugs d'install, sans compter quelques packages avec des dépendances foireuses.

Par conséquent, même si personnellement je suis convaincu des bienfaits d'une Debian et que je préfère l'unstable (je ne dirais pas Sid vu qu'elle passera testing puis frozen puis ... à son tour) à n'importe quoi d'autre, il faut rester juste. La Debian en version de développement requiert certaines connaissances, un peu d'habitude dans la manip des scripts, etc ... pour être *efficace*, j'entends par là, ne pas passer plus de temps qu'il n'en faut lorsque les mises à jour nécessitent intervention de l'utilisateur car pb.

Restons justes en accordant à chacun ses atouts, mais aussi ses défauts.

Vrai, mais 80% des embrouilles viennent de l'intérieur du rézo.

A ceci un commentaire: ton switch, dessus tu peux avoir par exemple 2 fois 2 machines qui communiquent à plein pot, soit 200Mb de bande passante occupée (on suppose du half-duplex). Et ton port de sniff, il est en 100Mb. Donc tu ne pourras pas avoir plus de la moitié du traffic.

Prends maintenant un switch avec 48 ports, ça fait un traffic de fond de panier potentiel de 24*100Mb (en considérant que du half-duplex tjs), soit 2.4Gb, alors accroche-toi avec ton port sniffeur à 100Mb... et ça on y peut pas grand chose.

Donc il faut placer avec justesse les NIDS sur le réseau physique ainsi que des NIDS hardware (dans les switchs et routeurs ) qui soient capable de filtrer à ce débit (je ne crois pas que ça soit déjà possible). Bref, ce problème de surveillance est loin d'être réglé.

Un bench, je n'ai pas. Ce que je peux te dire, c'est qu'en effet le code de Snort est un gros tas de lignes parfois incompréhensibles. Ça ne donne pas très envie de travailler dessus.

Par contre, Prelude a dès le départ eu un soucis de design propre et efficace, d'où une rapidité accrue, et la différence se fera quand on voudra sniffer des réseaux très rapides (le gigabit par exemple ? :), là j'ai peur que Snort soit bien à la rue.

Aussi, bien que Prelude ne soit pas encore complet, ces derniers temps l'équipe des développeurs s'est etoffée et ça avance plus vite. Un point manquant à l'heure actuelle est la contre-mesure, mais les développeurs prennent le temps de bien concevoir la chose pour avoir juste du premier coup. D'ici peu, Prelude aura tout ce qu'il faut pour faire main-basse sur les IDS ;-)

D'ailleurs, l'équipe sera très probablement aux Rencontres Mondiales du Logiciel Libre en juillet (lsm.abul.org, mais le site est encore bien vide côté programme :( pour présenter et expliquer les avancées du projet et son avenir.

C'est bon, j'ai aussi mirroré. Toujours la même URL pour ma part: http://www.enseirb.fr/~malguy/brevets(...)

J'ai seulement copié le .ps et le .pdf, pas les sources, mais vu que dans la pratique c'est amplement suffisant: http://www.enseirb.fr/~malguy/brevets/(...)

Je crois que tu te méprends sur la fin de tes propos. On ne veut pas nous empêcher d'accéder à l'information (tout du moins pas dans le cas présent). Il s'agit d'en profiter pour amasser de l'argent (le mot magique) avec tout ce que ça induit (pouvoir, etc ...).
Mais un effet direct est effectivement de limiter l'accès à cette information.

Au contraire, je trouve ça un peu "crado". Je l'ai utilisé y a 2 ans avant de découvrir le patch bridge+filtre pour kernel 2.2 et je préfère nettement le bridge.

Anecdote: avise-toi d'inverser les ports (dont les cartes), et observe: tes machines vont crier au vol d'adresse MAC à tour de bras. Dans mon cas, j'ai retrouvé ma prise murale (donc le port du switch auquel ma machine avec proxy-arp était reliée) débranchée, puisque ma machine se faisait passée pour tout le monde sauf moi "de mon côté" et pour mes machines vers le reste du réseau (ceux qui maitrisent un minimum doivent déjà être pétés de rire). Et pourquoi cette conf ? Ben le multicast/broadcast ...

Ah non, du tout, c du filtrage assez basique: blocage de certains ports comme NFS, rsh ... Je ne suis pas direct sur le net, mais sur un intranet où je ne suis pas tout seul ...

C'est une question piège ?

Que ça soit documenté, ça c'est très bien, par contre, c'est pas complètement nouveau. Ca fait déjà de nombreuses semaines que je fais ça en usage perso, et je ne dois pas être le seul ;-)

du 386 au multiproc xeon, ça reste du x86 tout ça :)
Quid des (Ultra)SPARCs, MIPS, Power(PC), Alpha, HP-PA, etc ..., hé ?

Faut voir encore plus large ! :)

C'est comme ces vieux écrans Sun trinitron du début des années 90 17". Un petit fil à rajouter dedans, l'adaptateur Sun -> VGA, et hop, un écran de recyclé pour mon serveur ;-)

Par contre il est aussi volumineux voire plus profond que mon IIYama 19" :(

Sinon, SGI ils feraient pas un peu la gueule d'apprendre qu'Irix 6.5 est filé de particulier à particulier comme ça ? Parce que bon, c'est quand même proprio. A noter que c'est dans les 9 CDs Irix 6.5 (dont 1 de doc sur ISO9660 et tout le reste dans des formats proprio à souhait, j'ai jamais pu lire les CDs avec ma conf Linux et j'ai pas cherché beaucoup plus loin.

Sur du 10mb c bon en effet. Sur du 100mb, j'arrive à
peine à faire du 1.5~2Mo/s (100mb-> 11Mo/s maxi). via ssh (par scp, sur un gros fichier).
Je fais pas vraiment mieux par NFS. Par FTP c bon,
je fais 9~10Mo/s soit à peu près le maxi. A ce niveau, les CPU carburent pas mal et c presque les disques qui limitent.

NFS est pas gégé (selon moi) mais on pas encore vraiment mieux.

Il peut arriver que Linux ne soit pas en mesure de tirer pleinement parti des architectures hardwares, genre sur une IBM SP3 (processeurs Power3), c'est pas gagné de faire fonctionner avec un kernel Linux. Ca peut se comprendre, on a pas toujours les specs, et les constructeurs peuvent optimiser réellement à l'extrême les drivers et bibliothèques (genre l'usage des BLAS 3 sur une SP3, on gagne un facteur 20 en temps d'exécution sur des calculs matriciels, pas mal tout de même).

De mon point de vue, ce n'est pas un problème de qualité, mais plus un problème de support pas encore optimal (disons sur du non-x86). En trois ans, le kernel Linux est parvenu à un support quasi systématique pour les PC. On peut espérer qu'il en sera de même sur les architectures de noeuds SMP des constructeurs Sun et IBM d'ici peu. Pour les architectures Alpha et MIPS, je ne sais pas si c'est encore intéressant ;-) Reste l'IA64, et là, on est loin d'être à la bourre. J'ai oublié une architecture pour gros système ? (j'ai volontairement négligé l'HP-PA).

Hu hu hu, c'est toi qui dit ça, MDR ! :)

Plus que "phisophiquement" il aurait du être dit "déonthologiquement", je pense.
Jusqu'à l'an dernier, seules des entreprises ne faisant pas son business grâce à l'informatique étaient acceptés ou alors sans la possibilité de réclamer un logo ou autre.

Ceci était du à la volonté initiale de simplifier le choix des entreprises pour les critères. En effet, comment départager IBM qui fournit JFS en libre et Alcôve qui ne travaille qu'avec du libre ? Les organisateurs souhaitaient éviter tout problème/conflit à ce niveau. Bien entendu, une entreprise devait rester "réglo" (genre marchands d'armes, je suis pas sûr qu'ils auraient été acceptés :)

Après, le principe de sélection a pu changer pour cette année.