nullisimo a écrit 173 commentaires

Il serait logique que tous les professionnels du web aient découvert l'intérêt des liens, pour être référencés par les moteurs de recherche, cités par leurs utilisateurs augmentant ainsi leur classement dans les algorithmes type Google PageRank, etc.

C'est pas aussi le concept du google bombing ? :-)

ouaip :) mon cerveau a fourche ;) merci de la correction :)

Comme quoi les idees recues ont une bonne esperance de vie ;-)

Grace a la magie de l'unicast on arrive a ca:
http://maps.google.com/maps/ms?ie=UTF8&hl=en&msa=0&a(...)

Oui,,, mais le blacklisting c'est encore un truc 100% vendor, un bon gros patch dans le code du serveur :-)

Pas de chance. Il/Ils est/sont belge/belges ;-)

http://fr.wikipedia.org/wiki/Benny_B

2 cas:
1er cas:

1. un mod_log_config patche pour le signal-free rotate + flags de compilation pour les logs > 2Go
2. ensuite gzip en background temporise pour eviter un pic I/O
3. rsync
4. zmergelog

2eme cas:
mod_log_spread + spreadlogd

Petite precision quand meme.Il n'y a pas que malloc(9) comme allocateur de memoire kernelland sous FreeBSD. Il y aussi uma(9). Au dela ca devient trop bas niveau et/ou custom.

Precisons Ivan Voras est committer et kernel developper.

Si il fait la distinction, c'est que contrairement a linux qui utilise kmalloc() pour l'allocation memoire kernelland, FreeBSD a aussi un malloc(9). La section '9' sous FreeBSD contient les page du developpeur kernel.

Dans son esprit la disctinction est naturelle, mais chez 99% des gens au moins ce n'est pas si evident ;-)

OK. Le nouveau jemalloc tourne en espace utilisateur et quand j'ai lu ça cela m'a assez surpris. Est-ce que l'ancien phkmalloc tournait en mode noyau ou en userland ? Est-ce que le fait que jemalloc tourne en userland n'induit pas des coûts lors des changements de contexte ?

malloc()a toujours ete userland. Ca se base historiquement sur (s)brk(), et de nos jours (s)brk() et mmap() ou seulement mmap().

Je ne savais pas qu'une simple constatation pouvait mener a une telle interpretation :)

C'est une relation de cause a effet. Aurait-il du dire
"A cause des entreprises qui ne respecte pas la GPL, le SFLC doit engager des poursuites qui decouragent ces entreprises d'utiliser linux. Helas, elles nous utiliserons plus souvent" ?

Faut pas deconner non plus.
Ne prete pas des intentions malhonnetes a 2 phrases.

Pour une fois je suis d'accord avec toi ;-)

La notion de faille de securite chez OpenBSD se reduit comme peau de chagrin avec le temps.
Ca commence avec les failles locales. puis remote (je vous invite a utiliser archive.org).
Ici commenca la lente descente aux enfers de la communication:
- Les failles ne sont que pour l'installation "par defaut" (OpenSSH sans separation de privileges, apache (chunked encoding qui sous OpenBSD uniquement permettait de chopper un acces root))
- La notion de "failles de stabilite" qui permet de ne pas comptabiliser les sources de DoS en failles de secu (headers IPv6)
- Et depuis peu les failles "probablement tres peu exploitable" (PNRG)

Le probleme de FreeBSD est different: fournir un kernel de base sous licence BSD (certes il reste pas mal de soft userland sous diverses licence, dont la GPL). La CDDL n'a pas les memes libertes que la licence BSD. Surtout la partie sur les brevets.

Source:
http://blogs.sun.com/dillon/entry/open_java#comment-11642487(...)

0 heures , c'est quoi ce chiffre ?
Ca voudrais dire que le correctif serait parru dans l'heure ? impressionnant.

Pour les failles critiques les "vendors" sont generalement prevenus a l'avance. Generalement, ca se passe en 3 temps (sans compter la premiere etape ou le projet apprend qu'il a un joli trou de secu ;))
1. Annnonce de la failles aux security officers/maintainers, avec souvent un correctif
2. Quand les principaux acteurs sont prevenus/prets, une date et une heure sont choisies pour l'annonce publique.
3. une fois annoncee, tout le monde applique le fix (commits dans les repos, mise a jour des packages, etc...)

Note: il peut s'ecouler plusieurs jours/semaines/mois entre la phase 1 et 3.

L'élection du projet debian est le premier exemple qui me viens à l'esprit.

Pour rentrer dans le troll bien baveux. Est-ce vraiment une reussite ? :-)

Ce que je ne comprends pas trop, c'est que la dernière l'explication de l'arret du dev était un probleme de license, je ne vois pas comment continuer a faire du dev peut résoudre un probleme de license, bah on verra bien..

On va faire simple ;-) Pour que dtrace fonctionne, il faut rajouter un peu partout du code sous CDDL, qui va "polluer" le code sous BSD du kernel. ZFS n'a pas ce probleme car c'est 1 module kernel. Pour Dtrace c'est la meme chose. Pour reprendre l'exemple de John Birrell. afin que drtace ait connaissance des etats internes au kernel, il faut rajouter un element dans la structure qui definit un thread. Et donc inclure du code CDDL dans du code 100% BSD. L'astuce du ifdef ne tient pas la ni pour des raisons legales, ni technique (ca casse l'ABI).
Toute l'astuce du port reside dans l'isolation du code sous CDDL et donc eviter le conflit de licence. Dans le cas de la structure d'un thread, c'est de rajouter un mecanisme (kernel-wide) qui permet d'avoir un element "opaque" qui sera exploite par dtrace, qui au final ne sera plus qu'un module a part.

Ce n'est pas de la journalisation de file system.
geom_journal (puisque c'est de lui qu'il s'agit) est une journalisation par block sur la couche geom (le device), La partie UFS a ete modifiee pour interagir avec gjournal. N'importe quel FS peut, en theorie, profiter de gjournal (sous reserve d'un patch),
La journalisation "gjournal" ignore donc les specifites du file system au dessus , les donnees et les meta-donnees, ce qui le penalise en terme de perfomance, surtout sur les transfert de gros fichiers (toutes les ecritures sont doublees).

C'est le projet BLUFFS qui est sense offrir a terme du FFS/UFS journalise.

> elle requiert de devoir redémarrer la machine, ce qui est potentiellement dangereux.

Mouaif... Un admin qui met en place quelque chose qui ne supporte pas un reboot est un mauvais admin.

ahahaha :) les joies du misquoting :)

Dans la plupart des Unix, comme dans FreeBSD et OpenBSD l'intégralité du contenu de /sbin et la majorité du contenu de /bin est linké en statique et est aussi light que possible (par exemple pas de dépendance à la libc).

Sous FreeBSD ce n'est plus le cas depuis qq annees deja (en juillet/aout 2003 IIRC. et pour la premiere fois dans FreeBSD 5.2). Tout simplement pour que les binaires dans /bin et /sbin puissent profiter des DSO pour PAM et NSS, seuls qq binaires restent statiques (genre init, devd).
L'astuce chez FreeBSD est d'avoir un /rescue avec un crunched binary (avec les hardlink qui vont avec) qui contient presque tout ce qui permet de fix l'OS au cas ou.

L'âge moyen de la retraite à la RATP est de 53 ans, 54 ans à la SNCF et 56 à EDF.

D'autres chiffres:
http://www.sauvegarde-retraites.org/article-retraite.php?n=3(...)

si parmi Xiti et tous les autres CyberNaziMonitor il y en avait qui étaient dignes de confiance et avec une politique claire par rapport aux données collectées (comme s'abstenir de chercher à établir même anonymement le parcours type d'internautes d'un site A à un site B puis à un site C)

C'est faux. Dans le cas des offres payantes, les donnees sont propres aux clients et les recoupements intersites n'appartenant pas au meme client ne sont pas effectues.

+1/0/-1 c'est aussi le systeme de vote apache et ca ne date pas d'hier.
http://mail-archives.apache.org/mod_mbox/httpd-dev/199504.mb(...)

Aujourd'hui d'ailleurs on entend plus tellement parler de virus diffusé à grand échelle sous Windows, car les grosses failles ont dues être corrigés.

Sur ?
http://www.schneier.com/blog/archives/2007/10/the_storm_worm(...)

Même avec un ZFS gplv2 il faudrait un montant colossal de travail pour peut-être pas grand chose au final.

Ci dessous une URL pointant sur la presentation de pjd@ sur ZFS sous FreeBSD. Avec quelques details sur le portage (et pour se faire une idee sur ce travail colossal)
http://misc.allbsd.de/Vortrag/EuroBSDCon_2007/Pawel_Jakub_Da(...)

La stabilite des API, c'est une catastrophe. Imagine un OS fige dans ses API depuis des decennies.

POSIX, une catastrophe ? :-)
(Note aux nerveux: c'est du second degres, je sais qu'on parle d'API kernel).

Sinon, entre "des decennies" et "chaque version majeure", il y a une difference. Pourquoi faut-il toujours en rajouter ?

Linus Torvalds est un "plouc" car il ne fait pas de "make word" ?

Je n'ai jamais dit ca. Mais la aussi ce n'est pas la meme contrainte kernel != OS
Mais on va prendre des exemples concrets.
geom_journal sous FreeBSD:
En plus du module geom pour la journalisation, il a fallu modifier pas mal d'outils userland (newfs, tunefs, mount, fsck etc...) a cause du changement de structures, ajouter BIO_FLUSH dans le VFS et d'autre. Pour cela il faut s'assurer que ca compile partout et correctement. Certes, on ne compile pas tout a chaque fois, mais a chaque changement important, il faut s'assurer que ca fonctionne.
Sans compter que dans ce cas la, l'endianness entre en jeu.

Idem pour le routing. Il faut modifier le code kernel + route + la libc + pf + ce qui en depend (opsfd et openbgpd par ex).