Denis Rampnoux a écrit 35 commentaires

Une remarque concernant le CD : A ce que j'ai lu un peu plus haut, le pb avec le cd c surtout qu'il n'y a pas toujours les sources : le rpm, le deb, c très bien mais les sources, c à mon sens indispensable...
Bon courage pour la suite du magazine ! ;-)

En fait la bonne question a se poser est : qu'est-ce qu'un FAI a à gagner à fournir IPv6 ? Il ne pourra pas le vendre plus céher car en terme de débit et de qualité de service, IPv6 ne change rien... Ensuite, si on regarde un petit peut à qui appartiennent les plages IPv4 aujourd'hui, on se rend compte que env 70 % d'entre elles (c un chiffre très approximatif) sont au Etats-Unis, 20 % en Europe et le reste ailleurs... --> c'est en Asie que le problème est critique, or, il ne me semble pas aujourd'hui que les principaux acteurs des réseaux soient asiatiques... Enfin, dernière remarque, le problème de coùut dans les réseaux, ce n'est pas un problème d'équipement : le matériel, c 20 % du coùt, les 80 autres pourcents sont les salaires des gens qui les administrent... Donc l'argument consistant à dire qu'ils ont déjà le matos n'est pas très convaincant...

Si ca peut t'aider à te faire une opinion sur une puce java, un article m'a été conseillé :
Behavior of Efficient Virtual Machine Interpreters on Modern Architectures Anton Ertl et David Gregg European Conference on Parallel Processing, 2001
Je ne suis pas sûr qu'il soit autorisé de mettre un lien vers une copie du dit article (en fait, je ne sais pas donc je ne fais pas de bétises... ;-) ) mais google peut aider à le trouver ! ;-)
C'est assez intéressant même s'il faut un peu aprofondir pour se faire une idée à mon avis (avec les acrticles de la biblio par ex...)
Bon courage !

Pourtant celà a déjà été écrit dans des journaux dits "sérieux" !

Alors là, nous sommes complétement d'accord sur le sujet mais bon dans le cas qui nous occupent, ca doit être utile puisque tu bosses sur un projet similaire... le seul pb est que de mon côté, certaines erreurs stratégiques (choix de langage, d'architecture,...) et un manque de temps crucial (ca réprésentait un projet pour 1/4 de l'enseignement d'un trimestre en 2e année d'école d'ingé, nous étions 6 donc ct ingérable et j'avais aussi 2 autres projets prenants donc le résultat est... null !)
Je tiens également à rajouter que le prof en question, est à fond opensource, qu'il maintient des packages debian, est membre de l'april... et que les sujets qu'ils donnent sont en général utiles. Je ne peux malheureusement pas en dire autant de tous les projets que j'ai du mener jusque là
Enfin une dernière remarque : pour moi, il y a une différence majeure entre un projet d'école et un projet réel : le second doit être qqch de fini, d'utilisable, d'installable, de documenté sinon, les gens se découragent et c normal. Quand on est étudiant, le but premier est d'apprendre, quitte à ne pas documenter, à ne le faire tourner que sur une seule machine sans se soucier de version de libs... : on explique au prof le jour de la soutenance : un projet digne de ce nom ne peut (à mon avis) pas se permettre ce genre de choses
PS : pour les vérifs des liens : et bien c le feu alors ! ;-)

Bon c pas moi qui code donc c facile à dire mais je trouve que c une très bonne idée ! Le seul pb est pour l'export, il faudrait que le déchiffrement soit fait sur le serveur donc que le serveur ait des clés qu'il ne devrait pas avoir...
Ou alors, le déchiffrement se fait en local mais là, c bcq plus lourd en infrastructure...
Pour ceux qui développent : un petit truc sympa c un petit moteur qui vérifient que les liens sont toujours valables... ( c une idée d'un prof pour un projet similaire que g du faire il n'y a pas longtemps) Bon par contre c encore du boulot en plus...
En tout cas, merci à ceux qui développent ce truc, c super utile !

Hormis les suggestions qui te sont déjà arrivées, si tu as des problèmes lors de l'update de la 8.1 à la 8.2 en bootant sur le cd, une solution pour s'en tirer sans trop de boulot, consiste à garder sa partition /home voir /var et à installer la 8.2 sur le / puis à mettre les bons ppoint de montage quand il te le demande : Comme ca, tous tes réglages de user (qui sont dans les ~/.*), tu les récupères... par contre, tout les réglages dans /etc sont perdus... c dans ce genre de cas que l'on se rend compte que multiplier les partitions peut être utile...

Il y a aussi le fait que les industriels (pas de l'informatique) sont encore un peu réticents pour les clusters, souvent, ces gens préfèrent payer un peu plus cher pour avoir une techno plus connue déjà utilisée par d'autres

Comme toute nouveauté, il faut laisser aux gens le temps de tester... Mais à priori, le marché des clusters séduit de plus en plus...

C'est une des raisons qui me fait dire qu'il faut renouveller les méthodes de développement

Il est vrai que certains langages possèdent de nombreux atouts pour écrire des programmes corrects par construction

entre autres arrêter d'enseigner le C et le C++.

Là, c'est peut-être un peu radical, ces deux langages sont à mon avis indispensables mais pas forcément là où on les utilisent aujourd'hui. Personnellement, je pense que sur des parties où la vitesse est critique, ces deux langages sont très bon mais ils n'apportent pas la fiabilité lors du développement, je pense qu'il ne faut pas être radical mais seulement utiliser les instruments là où ils sont efficaces

Il est clair qu'un exploit demande toujours une mise à jour des softs de sécurités, sur ce point là, je suis d'accord.

Toutefois, concernant la 2e phrase, je pense qu'il faut moins être impressionné par les gens qui trouvent des failles dans des systèmes que par ceux qui concoivent des systèmes difficiles à pirater : programmer de manière fiable (par de débordement de buffer / architecture évolutive du code / ...) me semble beaucoup plus difficile que de trouver une faile sur un soft. Attention, je ne dis pas que trouver une faille est toujours trivial, qu'on ne me fasse pase dire ce que je n'ai pas dit.