reno a écrit 3881 commentaires

>Je me suis toujours dis que Ruby faisait double emploi avec python.

Je suis plutôt d'accord: quand je recherchais un nouveau langage (dégoutté de Perl), apres avoir tenter et rejeter Ocaml, j'ai été bien perplexe pour choisir entre Python et Ruby car je trouve ces langages très semblable..

Mais au final je préfère la syntaxe de Ruby a celle de Python, donc pour moi c'est Python qui fait double emploi avec Ruby pas le contraire..
:-)

>>"Quand au fait que les linuxiens feraient mieux de regarder comment marche leur système", ça relève malheureusement du troll bas de plafond, con, mesquin et gratuit.<<

Je ne suis pas d'accord: c'est bien connu que les developpeurs du kernel Linux signent des NDA pour les specs dont ils ont besoin pour les drivers..

C'est d'ailleurs un point de discorde entre les dev OpenBSD et Linux..

Donc pourquoi utiliser Linux et s'inquieter quand les dev Samba font la même chose que les dev du kernel Linux???

Ca fait très '2 poids, 2 mesure'..

est prévu d'être --> est prévue pour être

Je n'ai pas bien compris si la 1.9.0 est une version de developpement juste utile pour les developpeurs de Ruby (comme le kernel Linux 2.5.) ou si cette branche est prévu d'être utilisé par tout le monde..

Non, ça n'existe pas, pas parce qu'ils sont contre mais parce que personne ne l'a fait: c'est dans la FAQ..

Ca ne doit pas être simple d'ailleurs d'ajouter un 'modèle de dégât' pour les avions et une AI intéressantes..

>>Je vois en Perl6 une solution toute en un qui remplacera aussi bien Sh que Python, PHP ou Ruby.<<

Amusant ça, moi je vois en Ruby la raison pour laquelle pas mal de monde ne s'intéresse pas a Perl6..
Après tout quitte à réapprendre un langage (Perl6 est suffisamment différent de Perl5 pour que ce soit quasiment un réapprentissage), pourquoi ne pas en utiliser un plus propre et qui existe maintenant?

Comme quoi, midi, la porte, tout ça.. :-)

>Et vous, quel utilisation de perl faites-vous ?

Le moins possible!

Merci pour la présentation.

Elle est bien faite, le seul reproche que je lui ferai est qu'elle ne parle que des points forts de Ruby.
Lister les points faibles/limitations est, je pense, nécessaire aussi lors d'une introduction.

Pour Ruby: les performances, Unicode, le threading.

Pour RoR: marche mieux si on construit une application avec le schéma qui va bien pour RoR plutôt que si on réutilise un schéma existant (possible aussi mais l'intéret de RoR en est diminué a ce moment).

[ Non, ce n'est pas un troll contre Ruby, j'aime bien ce langage. ]

>>Par contre, suprenant de voir Postfix inclut à la place de Sendmail !

Ce qui est surprenant, c'est que ça aurait deja du etre fait depuis longtemps..

>>Erlang est peut-être un vieux langage mais il évolue toujours actuellement (la R12 est sortie il y a une semaine).<<

Sais-tu ce qu'apporte quoi la R12?

Il y a eu une version avant qui était "majeur": elle apportait le support du SMP a Erlang de manière transparente: avant il fallait le programmer pour utiliser plusieurs CPU, maintenant les processus peuvent être sur des CPUs different de maniere transparente (je crois).

Erlang est un vieux langage.. C'est pour ça que sa syntaxe est très "différente".

L'avantage de Erlang c'est sa 'scalabilité' (aucune idée comment traduire ça correctement en Français): avec Erlang on peut exploiter des muti-processeurs "efficacement" dans le sens ou N processeur peut impliquer N fois plus rapide en Erlang (ce qui est *très* interressant vu l'évolution actuelle des CPUs) mais attention:
- sur un mono-processeur Erlang est beaucoup plus lent que le C donc même si c'est une application "Erlang-friendly" il faudra avoir 2-3 CPU pour atteindre les mêmes perf que le C sur un seul CPU!
- toutes les applications ne fonctionnent pas bien en multi-processeurs: certains ont leurs performances qui restent faible même quand on ajoute des processeurs..

Tu serais plus crédible si tu justifiais tes assertions..

Les seules méthodes que je connais pour contourner un captcha sont:
- un OCR, mais ça ne doit pas marcher terrible.
- mettre en place un site web de sexe et transférer les captchas pour que des utilisateurs les resolvent a la place du spammeur: compliqué!
- "casser" le site web en contournant la sécurité: encore faut-il que ce soit possible: c'est fini le temps des mots de passe codé en dur dans les pages web..

Bref rien de fiable, c'est quoi la méthode magique pour contourner les captchas?

Les DRM sont fondamentalement fragile, mais a priori ce n'est pas le cas des captchas..

>Linux à peu près aussi facile à installer qu'un Windows

Ca dépend beaucoup du matériel.. De toute manière la facilitié d'installation compte surtout pour les particuliers et t'en connais beaucoup des particuliers qui veulent changer leur OS?


>Objectivement, il n'y a aucune raison pour que nous soyons encore dans cette situation,

Hein? La vente liée, le monopole de Microsoft sur les formats de fichier Office, Active Directory, les jeux, etc ça fait plein de raisons qui expliquent que les utilisateurs restent avec Microsoft.


>je ne vois pas fondamentalement ce qui pourrait nous en tirer

Des applications 'clef' nettement supérieure a celle de MS (comme Office) *et* la fin de la vente liée pourrait peut-être permettre de sortir du cercle vicieux..

<<Au moins en RISC, les instructions font 32 ou 64 bits, et puis c'est tout. Idem sur les VLIW. Bref, CISC reste un gros boulet qu'on se traîne.>>

Les MIPS et ARM ont tous les deux une variante de leur jeux d'instruction sur 16bit, ce qui leur permet d'avoir des densité de code équivalente a celle des x86.

Je ne connais pas de RISC du commerce avec des instructions sur 64bit, ça me parait énorme.

Pour la fin: le gain de jusqu'à 20% de performances quand on est passé de 8 à 16 registre pour lors de la transition x86 au x86-64 a bien montré que le x86 c'est de la m.., mais on n'est pas près de l'abandonner..
Et comme Intel a prévu de s'attaquer au marché de l'embarqué, les x86 pourraient bien prends des parts de marché aux ARM/MIPS sur ce terrain.

AMD a embauché un deuxième programmeur pour faire les specs, donc ça ira 100% plus vite..

Est-ce que c'est possible maintenant de retirer un coeur d'un cluster 'à chaud' sans perturber le cluster?

Je crois me souvenir qu'il s'agissait d'une limitation de la version 1.0 ..

BLOB executé ou?
Sur le chip du périphérique ou du CPU?

Ca on verra bien ce que le tribunal dira la dessus: je ne me risquerai pas a faire un pronostique: cf l'affaire Mobilix ou ils ont perdu en appel (ce qui de mon point de vue est une honte).

>Ouaip, j'ai un peu confondu. GPL v3 résoud le problème de la tivolisation/FreeBoxisation etc.

Tu confonds toujours.. La tivolisation et la FreeBoxisation sont deux moyens différents pour contourner la GPL:
- dans le premier cas, il s'agit d'utiliser la crypto pour t'empêcher de remplacer un logiciel sur un équipement que tu as acheté.
- dans le deuxième cas, c'est prétendre que le matériel est loué et non acheté donc que c'est une distribution interne à l'entreprise ce qui ne te donne pas le droit d'accéder aux sources.

La GPLv3 est bien contre la tivolisation, mais autant que je sache n'a rien de modifié concernant la FreeBoxisation.

L'AGPL par contre fonctionnerait bien contre la FreeBoxisation.

C'est pas l'histoire du link statique ou dynamique?

>sans vouloir troller la FSF vient déjà de sortir une GPL v3 inacceptable

Tu t'auto-contredit: tu troll puisque tu dits que la GPLv3 est inacceptable..

Même si je ne suis pas un fan de la GPLv3, apparemment elle est tout a fait acceptable pour certains puisque Samba est sous GPLv3, par exemple.

Il y a quelque-chose?

Non parce que c'est toujours le même problème: la génération de code est toujours vendue comme quoi on va beaucoup plus vite pour produire du code, en oubliant commodément de mentionner qu'on va ensuite beaucoup lentement pour debugger le code généré..

Mouai la sérialisation 'par défaut' c'est pas forcément une idée géniale: dans Eros ils avaient ça comme fonctionnalité et ils en sont revenus..
Le problème c'est quand tu fais évoluer ton code, si tu n'as pas conçu les snapshot 'version N' et version 'N+1', passer d'une version à l'autre peut devenir un cauchemar..

Je me souviens avoir lu le papier et il est très intéressant.

Le top ce serait que ce soit intégré dans une distrib de developpement: Fedora, Cooker, ...
Bon après il faut avoir suffisamment de monde pour analyser les rapports d'erreurs, mais on peut rêver d'avoir alors une nette augmentation de la stabilité..

Et alors?
Quand tu utilise le serveur FTP, DHCP etc de la FreeBox, tu passe bien par un réseau: celui de ton PC a la FreeBox..

Donc avec l'AGPL, il me semble que tu pourrais demander le code de ces outils, voire de la libc utiliser dans ces produits si elle était sous AGPL.