galactikboulay a écrit 620 commentaires

Tout à fait, la dictature c'est "Ferme ta gueule", tandis que dans notre
démocratie, c'est plutôt "cause toujours!"...

J'ai trouvé une intervention de Christian Paul ici qui montre sa connaissance du sujet et son bon sens:

http://www.defis-p2p.org/discours/discours5.phtml

Il est bien dommage que ce soit des guignols comme Donnedieu de Vabres qui soient au gouvernement et non des gens compétents comme lui.

France 2 ressemble de plus en plus à la chaîne du gouvernement, c'est inquiétant.

Et si ça peut te "rassurer", la compétition dans ce domaine est rude avec TF1 (insécurité, tout ça)...

J'avoue que j'ai du mal à voir la pertinence de citer Autocad, Freehand ou Dreamweaver par rapport à l'histoire... Ca n'apporte strictement rien si ce n'est un sentiment de publicité déguisée.

En quoi écrire qqch comme:

"Les plans de l'ambassade avaient été conçus à l'aide d'un logiciel de création 3D; j'appris par la suite avec surprise que le prophète avait tout fait lui-même. Quoique parfaitement ignorant dans à peu près tous les domaines, il se passionnait pour l'informatique, pas seulement les jeux vidéo, il avait acquis une bonne maîtrise des outils de création les plus élaborés, et avait par exemple réalisé lui-même l'ensemble du site web de la secte, allant jusqu'à écrire une centaine de pages de code HTML."

aurait été différent?

Effectivement hdparm mesure la vitesse brute du disque, sans passer
par le filesystem. Donc c'est totalement inadapté pour mesure la
perte de performance due à la fragmentation.

Si on reprend l'exemple de Floyd un peu plus à propos de la
dissipation de chaleur, on peut imaginer qu'il y ait une série
de ventilo qui soit défectueuse. Pendant la série de tests à la sortie
d'usine tout peut très bien se passer (surtout si ça ne dure que
quelques minutes), mais après un temps d'utilisation bcp plus long
le refroississement ne soit plus efficace et occasionne ces bugs.

Il faut voir aussi si il y a un test systématique de chaque console
produite ou si seulement 1 / n est vraiment testée.

L'auteur de la news a précisé que le chipset son ne fonctionne pas
(ça c'est pas encore trop trop grave) ainsi que le système de
ventilation (déjà bcp plus gênant) sous Linux.

Sauf que quand tu vois ce genre de message:

http://lkml.org/lkml/2005/9/16/178

et spécialement "Most of my customers remark that Namesys
code is head and shoulders above the rest of the kernel code.",
tu te dis que forcément il va y avoir des anicroches....

"En page 6 de l'assignation, il est marqué qu'AdVestigo déclare mettre
en oeuvre "plusieurs protocoles de réseau poste à poste à l'aide d'un
logiciel 'sous licence GPL normalement non commercialisable', appelé
MLDonkey"."

Il faut préciser qu'AdVestigo a le droit d'utiliser et de modifier
MLDonkey sans communiquer ses modifications si c'est juste pour
son usage propre. Par contre si elle distribue le logiciel à ses clients,
dans ce cas oui elle doit leur fournir les sources.

Pour la documentation, si ce sont des formats ouverts, au pire il y a
possibilité de réécrire un outil pour les lire et les convertir en un autre
format. A ce niveau, je pense qu'il faut privilégier qqch basé sur du
texte (style XML).

Pour tout ce qui est code, c'est sûr, il ne compilera/tournera sûrement
pas sur une plateforme future. Par contre, il y aura la possibiité de
faire un portage, ou de comprendre ce que le code fait. Avec du
propriétaire, il n'y a pas de marge.

Pour les outils comme tar, gzip et compagnie, le format est ouvert,
le code aussi donc on peut au pire réécrire les outils, ce n'est pas
quelquechose d'insurmontable. Et on peut supposer que comme ce
sont des outils libres, il y aura toujours quelqu'un pour effectuer des
portages sur de nouvelles plate-formes au fur et à mesure de leurs
apparitions. Avec des outils style Winzip, Word ou autre, si leur éditeur
disparait ou n'a pas envie de faire le portage, c'est foutu pour de bon.

Et si il y a des millions de lignes de code et que dans 10 ans il y a
impossibilité de transférer les données de l'ancienne machine à une
nouvelle ? Dans 10 ans, cela ne sera sûrement plus de l'ethernet
pour les connexion réseaux, et qui sait pour les protocoles ?

Non si je ne dis pas de bêtises, ça aurait très bien pu s'écrire
sous cette forme (ne pas oublier la ligne vide entre le content-type
et les données)

cat << EOF
Content-Type: text/html

<html>
<body>
Hello World
</body>
</html>
EOF

Si c'est un soft intégré au kit de connexion sous Windows, je pense
que ceux qui n'utilisent pas Windows ne seraient pas gênés.

Pour la connexion que fournit le FAI c'est de l'IP, donc toujours
utilisable en direct a priori.

Par défaut (sous Linux en tout cas), une application compilée sans
les options adéquates ne pourra pas utiliser des fichiers de plus de
2 Go. Les typedefs et compagnie pour représenter les offsets
et les tailles de fichiers sont par défaut sur 32-bits. Donc c'est
"normal".

Pour pouvoir compiler une application avec le support 64-bits des
fichiers, il faut utiliser ces flags avec gcc:

-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE

Si Apache n'a pas été compilé avec ces flags, c'est normal qu'il
ne puisse pas utiliser des fichiers de plus de 2 Go.

Apparemment le support des "large files" est dans Apache 2.1:

http://www.gossamer-threads.com/lists/apache/users/295588(...)

Sauf qu'il faut également re-situer ces brevets dans le temps. Ils n'ont pas été fait hier, mais il y a plusieurs années. Et à l'époque, on ne réfléchissait pas comme aujourd'hui et ont n'avait pas les mêmes connaissances.

Le 1er brevet a été déposé en 1995, les autres je n'ai pas regardé.
Ca aurait été déposé au début des années 1980, admettons. Mais là
le concept est quand même trivial, et les BDD et les interfaces
graphiques, ça existait depuis bien longtemps en 1995.

Sinon je suis d'accord sur le reste de ton argumentation. Le geste
de CA va dans le bon sens, espérons que d'autres suivront.

Donc, en gros, quelque chose qui se conçoit en même pas 10 secondes de réflexion...

Je n'ai lu que celui-là, je pense que la plupart (si ce n'est l'intégralité) sont du même accabit.

Je te rassure, il n'y a pas que toi que ça gonfle. De manière générale,
dès qu'on parle d'un WM qui ne gère pas "correctement" la
transparence, les ombres ou je ne sais quel gadget graphique à la
mode, c'est forcément de la daube.

Perso je préfère avoir un WM réactif qui me permette de bosser
correctement, et je suis désolé mais les ombres et compagnie,
je ne vois pas ce que ça apporte dans une utilisation de tous les
jours. Pour faire le kéké devant les copains, par contre, je ne nie
pas, ça doit aider à faire plus "in".

Tu as raison sur les exemples que tu cites, mais bon c'est tellement
gros et tellement ridicule qu'en cas de procès le possesseur du brevet
se ferait très probablement jeter d'emblée au tribunal (enfin faut
espérer).

Là c'est un poil plus subtil, l'idée est de bien gêner le concurrent
pour l'empêcher de développer un processeur compatible sans
license. C'est un exemple qui est moins spectaculaire, moins facile
à expliquer à des gens qui ne sont pas du métier, mais qui est tout
aussi dangereux.

Je suis d'accord, cela dit je pense que la remarque à l'origine était ironique :)

C'est IPv4 *et* IPv6* natifs.

Le fait de rajouter IPv6 en mode natif ne change rien pour tes paquets
IPv4. Donc, quand tu vas surfer en IPv4, il n'y a pas de paquet IPv6,
tout se fait en v4.

En attendant, bravo à ce Rani pour la brillante qualification d'IPv6 en
tant que "gadget".

C'est un peu malheureux qu'un FAI aussi connu que Free ne pousse
pas plus ce protocole qui n'est clairement pas un gadget et qui
permettrait d'en finir avec les nombreux problèmes d'IPv4 - rien
que la suppression du NAT serait une grande avancée (ceux qui
font de la visio-conférence avec H.323 savent pourquoi).

Si tous les FAI ont cette mentalité, IPv6 ne risque pas de se
démocratiser de si tôt.

L'ADSL, c'est plus souvent de l'IPv4 par dessus du PPPoA que de l'IPv4
directement sur la couche ATM.

Sinon là on parle d'offre native IPv6, donc pas de couche intermédiaire
IPv4. Il y a la couche IPv4 quand on monte des tunnels IPv6 over IPv4.

Pour la QoS, IPv6 n'a comparativement pas plus d'avantage qu'IPv4.

Non sûrement pas. Les 2 protocoles cohabitent nativement
sur les mêmes liens physiques.

Là où il y a encapsulation, c'est au niveau d'IPv4, qui est transporté
avec du MPLS dans le backbone.

Comme truc plus générique, je verrais bien un système permettant
de définir son propre jeu d'instruction, comme une reprogrammation
du microcode en somme.

Ca ne profiterait pas qu'à Java et .Net, ça permettrait également
de pouvoir émuler (au moins dans une certaine mesure) les jeux
d'instructions d'autres processeurs, style MIPS, PowerPC ou autre.

Attention on va essayer (c'est pas gagné) d'éviter que le troll ne se découvre une pilosité hors du commun.

Loin de moi l'intention de troller. J'essaie de comparer objectivement
2 solutions techniques.

Mon point est : a investissement égal on peut faire en OpenBSD/x86 a peu près tout ce que fait Cisco au niveau routeur/switch.

Je suis tout à fait d'accord avec toi sur les coûts: une solution Cisco,
c'est (très) cher. Ce qui fait que pour pas mal de routeurs d'entrée
de gamme ou firewall type PIX, une solution Linux / OpenBSD est
largement meilleure.

Pour de la commutation pure (ex des 48 ports 10/100/1000), rien
que pour la place, une solution Cisco (ou autre) est quand même
plus adaptée.

Au niveau routeur, là où Cisco garde une sacrée longueur d'avance,
c'est pour le MPLS. Sous Linux, il y a un début de pile MPLS, mais rien
de bien folichon (le protocole LDP n'est même pas géré). MPLS/VPN
ça n'est pas géré du tout (il faut du travail coté Quagga et coté
noyau avec support de tables de routage multiples - VRF).
Sur *BSD, à ma connaissance, il n'y a rien (ou alors des vieux
projets abandonnés).

Au niveau multicast, je pense que Cisco est plus complet, ou au
moins plus intégré (PIM DM/SM/SSM, mBGP, MSDP, IGMP/MLD).
Je me trompe peut-être sur ce point.

Au niveau firewall, n'importe qui qui a eu à gérer un grand nombre
d'ACL sous Cisco IOS ou PIX sait que c'est particulièrement pénible
à maintenir. Les systèmes libres ont un avantage indéniable de ce
coté là. Ils sont également beaucoup plus souples et évolués dans
les traitements (il suffit de voir ce qu'il est possible de faire avec
iptables).

Pour avoir une (très) grosse perf en filtrage chez Cisco, il faut
une FWSM, ce qui oblige à avoir le 6500 et tout le toutim, et à
qqch comme 20000$ la FWSM, sans compter le reste du châssis,
effectivement le calcul est vite fait. L'intérêt de la carte est que
c'est vraiment très performant (tout est fait en ASIC), et que ça
s'intègre très bien avec le 6500 (sur la gestion des VLANs).