Firwen a écrit 562 commentaires

Y compris pypy, je n'ai plus les nombres exactes en tête mais luaJIT mettait un facteur 10 à pypy environ…

ça doit être possible de se refaire un benchmark maison en fouillant un peu sur le shootaut ;)

Tiens une news sur luaJIT, surprise du jour

J'ai toujours trouvé le gain de performance de LuaJIT simplement hallucinant..

Sur les tests du shootout, LuaJIT avait des perfs qui rivalisait avec "java -server", c'est à ma connaissance le seul langage à typage dynamique/prototype qui peut se permettre ce genre de fantaisie, tous les autres sont loin, trés loin derrière ( d'un facteur 20 environ.. )

Ça n'a rien avoir. Tu peut très bien avoir des logiciels compilés en statique dans les dépôt des distributions et donc mis à jour comme ça l'est actuellement sous Linux et BSD.

Et comme ça, à chaque mise à jour de sécu d'openSSL, tu as 300 mise à jour triggered car tous les paquets compilés en statiques doivent être mise à jour. J'aime la compilation statique ( ou pas )

La communauté BSD est moins centralisée que celle de Linux. Et je n'ai pas le souvenir d'en avoir spécialement vu cracher sur d'autres modèles de développement (UN exemple ne compte pas, il faut que ce soit une attitude générale).

OpenBSD ?

C'est que fait Windows, c'est ce que font la majorité des installs .dmg sous OS X, etc… C'est pas pour autant que c'est propre….

Exactement, développé en "Bazaar" ça veut dire avec un modèle de développement horizontale, ça ne veut pas dire accepter la première merde venu dans ton code.

Oui et c'est justement sur ça que ça sent le troll.

S'adapter à de multiple cas ou autrement dit: être aussi portable que possible a été un choix de design de autotools/libtool.
ça n'a rien à voir avec le modèle de développement collaboratif, un modèle de type "cathédrale" ayant fait les même choix de design que les GNU/autotools auraient les même problèmes…

Ahh, Le meilleur sujet à troll dés Vendredi Matin : Cathédrale vs Bazaar ! félicitations

Quelqu'un de la communauté BSD, communauté qui a toujours prôné le developpement à la "Apache", controlé, centralisé, etc… crache sur le développement de style bazaar, vraiement étonnant :D

J'ai par ailleurs un peu de mal à voir le rapprochement entre un développement de style bazaar : c'est à dire, "git-style" avec des branches partout, où tout le monde contribue et soumet ses modifications… cad réellement communautaire quoi et … autotools….

Le fait que autotools soit une usine à gaz avec des horreurs comme libtool tient à son architecture et à ses choix de design… qu'est-ce que son modèle de développement vient faire là dedans ?

Une jolie license BSD :)

Vade Retro Satana !! Que la Segfault celeste RMS s'abbatte sur toi  !

Execepté ça, trés trés bon projet, pkg-config est le seul moyen valable pour fournir ses flags de compilations proprement… et de manière portable indépendament du build système( autotools, cmake, scons, waf…).

Mais il faut bien avouer qu'il vieillit, la gestion des dépendances est lentes comme pas possible ( essayer d'utiliser les globus .pc, vous comprendrez… ), il est passablement bugggué lorsque'on l'utilise avec des paths non standards et ça ne ferait pas de mal de pouvoir étendre un peu les flags disponible à autre chose que --libs et --cflags.

Ce qui est surtout ridicule, c'est que si tu choisis bien ton assurance Suisse, tu es couvert en France ( ce qui ne coûte pas un denier à la sécu mais rapporte de l'argents aux hopitaux français… ) MAIS si tu choisis la sécu française, tu peux te brosser pour te faire soigner en Suisse.
Si les frontaliers prennent des assurances Suisse, c'est pas juste pour le plaisir de payer plus à une compagnie privée :D

Donc le choix est vite fait.

PS : Je précise que je fais parti des 10% d'idiots comme moi qui ont la sécu ET une assurance Suisse…

Que la Sécu veuille que les frontaliers contribuent, pourquoi pas ? mais en échange qu'elle fournisse au moins une couverture correcte à l'étranger… quitte à cotiser plus….

Tu es sur que ton routeur gère correctement le V6 ? la majorité des boites noir chinoises ne le font pas.

Si tu lances Wireshark sur ta carte ethernet, tu dois avoir des trames de type "router avertisement" toutes les X secondes.

Si ce n'est pas le cas, tu as un problème de topologie.

Merci cet article.
ça fait plaisir de voir l'ESIAL, Nancy et lothaire cité sur DLFP au passage.

(un ex-nancéen)

+1

Pour Miguel de Icaza, Linux (sur le Desktop) est mort !

Pour Miguel de Icaza, Linux (sur le Desktop) est mort !

de rien

Par exemple, une fonction transformant un fichier en une liste de chaînes peut s'écrire :

Sinon, pour les gens qui ne sont pas nazi du typage, y a
def read_file(filename):
return open(filename).readlines()

( Godwin point +=1 )

Ce qui m'a toujours étonné dans le milieu industriel, c'est le coté excessivement fermé/propriétaire de la chose.

On déploie des solutions siemens/téléméca manipulables que par le soft éditeur, dans un language souvent pas portable (ST, ladder)
sur des bus proprio ( profibus << ), supervisé par encore un/des soft proprio bien souvent avec un PC sur Windows 2000/XP proprio….

Il n'est pas très étonnant de voir le milieu effrayé par les mise à jour dans une magnifique usine à gaz pareil:
- la marge de manœuvre des techniciens en cas de mise à jour foireuse est quasiment null et le risque n'en vaut pas la chandelle.
- la portabilité du code d'une solution à l'autre est un cauchemar pour 20k raisons : bus pas compatible, supervision par compatible, code tout simplement pas portable.
- le 3/4 du temps dans les "GROS" milieu industrielle le code a été généré par un générateur,… et patché 20 x depuis : résultat plus personne n'ose y toucher car PERSONNE ne le comprend.
- le coté souvent périmé des technos, fait que si tu veux changer 2% de l'installation, tu dois finalement changer 60% de l'installation.

Ce qui me désespère encore plus, c'est que rien mais strictement RIEN niveau technique dans ce secteure st impossible à faire avec un ensemble driver / OS / languages OSS….

Comme pour un pool de thread, il est possible de faire un pre-fork.

Un pré-fork impose d'avoir un context "out-of-date" au moment de ou le processus forké va être utilisé, donc impose une transmission du context "courant/maitre", donc impose encore un overhead supplémentaire.

Si on a inventé les processus légers, ce n'est pas juste pour emmerder les gens qui font de la preuve logiciel et de la sécurité logiciel.
Et fait est que OCaml a un support relativemement mauvais du multi-thread comparé à ses principaux concurrents ( Scala, Erlang et F# pour ne pas les citer ).

Sauf qu'un fork est peut être parfait et "sûr" en théorie, mais il a un coût de création élevé en pratique, spécialement comparé à une pool de threads.
Le cout qu'impose une creation de processus rend la parallélisation de petite portion de code complémentement inutile en pratique….
Et je ne parle même pas du cout du "messaging" par pipe…

Ce n'est pas pour rien que des langages orienté "concurrency" avec des routines "light" fleurissent sur la toile….

A titre de comparaison, Erlang support le SMP dans son threading léger depuis les années 2000 si ma mémoire est bonne….
En OCaml, on a l'immutabilité par défaut, sans aucun avantage de l'immutabilité par défaut…

On peut se demander si le shootout est basé sur la vm ou du code natif?

Les lignes de commandes utilisées sont affichés dans le shootout.

Une chose particulièrement "crade" dans le shootout OCaml est l'utilisation de grand coup forks pour compenser le mauvais support multi-core d'OCaml….

Pour rajouter une couche,un code qui marche en ocaml est très proche d'un code fini, pas > besoin de rajouter une grosse couche de gestion d'erreur. En C, une fois qu'une maquette > marche, il faut rajouter toutes la gestion d'erreur pour éviter les "core dump", il faut > revoir toutes les allocations mémoire pour éviter les buffer overflowx, etc…

Ton pavé ne veut strictement rien dire, un programmeur C qui n'anticipe pas la gestion des erreurs est un néophyte ( et je reste poli ) . Ta phrase donne juste l'impression que tu n'as pas l'air de connaître grand chose à la prog système.

Ce n'est pas parce que le C n'implémente pas nativement les exceptions qu'il n'y a pas de méchanisme "propre" pour faire de l'error report : GError, errcode, ou un errbuff dans le context courant….

Quand aux problèmes d'allocation mémoire, C++ et la RIAA apporte des réponses à tous les problèmes les plus courant… Et valgrind associé aux tests fonctionnels font le reste.

désolé pour le piètre orthographe de mon précédent commentaire, j'implore l'excuse netbook + hotel + connexion pourrie :D

Je ne suis pas si sur que la faible popularité d'OCaml soit imputable à l'enseignemen, il y a pas mal d'université enseignany Ocaml en france, particulièrement dans l'Est.

OCaml est un langage qui par design impose de fortes limitations à l'utilisateur en échange d'une fiabilité élevée, voir même trés élevée.
Il y a des tas de situations ou subir ces limitations est gênant, rébarbatif et souvent une perte de temps, il n'est pas trés étonnant que pour des domaines ou la fiabilité est secondaire, l'enseignement d'un autre langage est plébiscité par les entreprises….

Développer en OCaml, c'est aussi facile qu'écrire du Python, mais avec deux différences:
La passion pour un language c'est bien mais l'objectivité c'est mieux :p

OCaml est certes un language qui a des qualités, mais le niveau d'entrée d'OCaml est bien plus élevé que pour python ou que tout language de script :).

Justement car le compilateur est strict, trés strict même.

C'est possible d'héberger un service ocsigen derrière un apache ou autre en fastCGI / CGI / modX ou autre ?

Deployer son propre serveur web peut être une grosse limitation sur certains environnements, voir peut provoquer un ulcère gastrique à certaines team sécu.

Des gens qui renouvellent leur PC tous les deux ans, à part des geeks, je sais pas si on en trouve beaucoup.

Les PC portables ont en leur autonomie de batteries lithium-ion réduite à néant aprés 3 ans, donc oui même le commun de mortel doit changer son PC tout les 2-3 ans.