Antoine a écrit 5722 commentaires

Faut comparer au nombre de personnes impliquées. En divisant 14 par le nombre d'astronautes ayant emprunté une navette, on doit arriver à un taux de mortalité pas piqué des hannetons.

Ça dépend dans quels pays…

Parce que, sous Unix, c'est la seule manière de créer un nouveau processus ?

Ben non : http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn.html

comment implémenter une fonction aussi simple que fork() dans Windows ? C'est uniquement pour simplifier la portabilité de certains programmes (tous ceux écrit pour Unix) que je pose cette question

Justement, je ne pense pas que fork() soit simple à implémenter. C'est AMHA pour ça que POSIX s'est résolu aux limitations mentionnées plus haut. Et il n'est pas dit que le modèle du noyau NT soit adapté à fork().

Tant qu'à taper sur Windows et la portabilité, j'en voudrais plutôt au fait que des fonctions comme read(), write(), send() ou recv() prennent une longueur en int et non en size_t. Parce que là, il n'y a pas de difficulté technique.

Liberal est utilisé pour les defenseurs des seules libertés civiques (avec une opposition aux libertés économiques)

Non non, les liberals anglais et américains sont bien pour les libertés économiques. Suffit de voir la politique d'Obama, pas franchement anti-libérale.

En même temps, je serais étonné que beaucoup choisissent de lire Linuxfr via le flux RSS, plutôt que sur le pétulant site Web et ses fils de commentaires de haute qualité.

En même temps, pourquoi implémenter fork()?
fork() a l'air propre, mais ça devient un sac de noeuds quand il y a plusieurs threads. Comme le dit POSIX :

« If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. Fork handlers may be established by means of the pthread_atfork() function in order to maintain application invariants across fork() calls. »

Android a atteind 3,9% de parts de marché au bout d'un an ( http://www.metro.co.uk/tech/814489-iphone-and-android-use-surges-as-phone-fans-turn-to-apps ) là où Windows Phone n'était qu'à 2,3% au bout d'un an. Prétendre que l'un est un succès fulgurant là où l'autre est un gros bide comme tu le fais alors que les conditions de concurrence étaient et sont différents, c'est juste du foutage de gueule.

Ce qui est du « foutage de gueule », c'est de faire comme si Android était resté à 3.9% de parts de marché, ou comme si Windows Phone était automatiquement voué à suivre la même courbe de croissance qu'Androïd.

Hum, étonnant comme design. Le monochrome est à la mode ? Windows 3.1 est devenu totalement fashionable ?

A le libre, c'est plein de jolie licornes qui vomissent des arcs en ciel et tout y est parfait

Les arcs-en-ciel étaient buggés, ils ont été supprimés de la dernière version de GNOME (mais il y a toujours les licornes qui vomissent).

Dans 5 ans, probablement pas, je suis d'accord.

Tu es indulgent, il manque quand même la dénonciation de l'intégrisme, de l'intolérance, et les grands appels indignés à la Liberté™.

Si tu t'arrêtes dès la première chose, le premier obstacle, au final, tu sors pas de chez toi.

Zenitram ne doit pas sortir beaucoup de chez lui non plus, vu le temps qu'il passe à poster ici :)

Si je n'ai qu'un Core i5, vous croyez que je pourrai quand même jouer au démineur?

Essaie de l'overclocker pour voir.

Je suis pour l’ouverture d’esprits.

D'autres préfèreront ouvrir des bouteilles. Chacun son truc.

Il y a des processeurs Atom limités à 32 bits par politique commerciale (lire : le support x86-64 est désactivé).

Tout comme le compilateur t'empêche pas de compiler si tu décides de tout foutre dans des types 'object' et que tu mets des cast partout

Ah, drôle de compilateur. C'est un choix un peu étrange pour un langage de haut niveau.

c'est perdre un bel outil automatique qui ne coûte pas grand chose.

En l'occurrence, l'outil automatique t'oblige à utiliser un autre langage (Typescript) pour lequel l'expérience est beaucoup moins répandue que pour Javascript. Ce n'est pas un inconvénient mineur.

Du tout, tu fais tourner dans les navigateurs le resultat d'une compilation par TypeScript.

Ce serait bien de lire le fil de discussion avant de répondre.

C'est comme dire que la ceinture de sécurité ou le panneau "sens interdit" ne sert à rien : oui tu peux te mettre la ceinture autour de la gorge, tu peux ignorer le sens interdit, ca ne les rends pas moins utiles pour les gens normaux.

Ben justement, c'est une très mauvaise analogie : ta bagnole ne refuse pas de démarrer si tu ne mets pas ta ceinture de sécurité, et ne s'arrête pas de rouler si tu passes un sens interdit. En d'autres termes, la sécurité routière dépend du bon comportement des conducteurs, pas d'automatismes coercitifs.

Quand on est décidé à faire de la merde, je te le confirmes, on y arrivera toujours : on peut effectivement être un développeur complètement con, c'est un choix.

Désolé, mais la plupart du mauvais code ne l'est pas à cause de mauvaises intentions.

Tu ne réponds pas à mon objection, à savoir qu'un compilateur n'est pas ce qui te prémunit contre des bugs. Tes programmeurs qui produisent du mauvais Javascript, produisent-ils du bon C++ et du bon Java ? J'en doute fortement. Ils font le même genre d'erreurs, simplement ils « corrigent » à qui mieux-mieux quand le compilateur les envoie bouler.

C'était juste pour faire sourire : c'est bien entendu exagéré mais pas très loin de la vérité tout de même ;)

Eh bien, faut savoir : c'est exagéré ou c'est proche de la vérité ?
Pour ma part, je pense qu'il est tout à fait raisonnable de maîtriser du code qu'on n'a pas écrit (et même parfois mieux que le programmeur original), mais ce serait intéressant que tu assumes ton opinion, si elle est contraire.

Tu as dit que Typescript était « utilisable dans tous les navigateurs ». Être utilisable dans un navigateur implique que tu fasses tourner le compilateur Typescript (écrit en Javascript) à la volée lors du chargement d'une page Web, ce qui ne me paraît pas franchement désirable.

Oui, bien sûr, sauf que le compilateur n'est pas « très important » dans l'histoire : on peut très bien écrire du code buggé à mort, mais qui satisfait les exigences de typage du compilateur.

il faut bien qu'il fixe rapidement un bug remonté par le client

Vaudrait mieux qu'il le corrige.

avant de maîtriser ton code (traduction technique : tout réécrit)

Heu non, heureusement, on peut maîtriser un code sans l'avoir écrit soi-même (mais peut-être pas en Perl ou Javascript, je l'admets).

très important quand l'on modifie un code que l'on ne maîtrise pas

C'est une bonne idée, ça, de modifier un code que l'on ne maîtrise pas, et de compter sur le compilateur pour éviter de faire des conneries.

Avec ce genre de raisonnement, n'importe quel langage interprété en Javascript « est utilisable dans tous les navigateurs ». Par exemple Python : http://www.skulpt.org/ (je n'ai pas vérifié si l'implémentation était complète, mais on voit l'idée)

On admettra aisément que cette définition de « tourner dans un navigateur » n'est pas très utile en pratique.

Ça peut servir, par exemple si tu veux avoir plusieurs démons locaux écoutant sur le même port.

Ben non, Typescript n'est pas utilisable dans les navigateurs. Soyons précis.

Tu constates le même schema avec Java. C'est là, la VM est là personne ne veut lutter de manière frontale alors on vise l'existant comme plateforme cible.

$ cat /etc/debian_version 
6.0.5
$ java --version
-bash: java : commande introuvable
$ python --version
Python 2.6.6

Tu disais ?