Antoine a écrit 5722 commentaires

C'est quoi, un grumaux spermique ? Ça se mange ?

Il doit estimer que le sperme, c'est comme la béchamel : il faut un fouet pour le faire monter.
Remarque, dans un sens...

En tous cas c'est ce que la FSF dit :
http://www.fsf.org/about
(bla bla bla)

J'adore cette façon de sortir les tables de la loi quand on parle de logiciel libre.
Très crédible, surtout que c'est bien connu : le LL n'est qu'une abstraction, rien n'existe en-dehors des textes sacrés de la FSF.

Verdict : joli troll, mais lassant.

Je me contenterai de remarquer que Totem a plus de fonctions que Dragon Player

Cette bouse de Totem ? Tiens, je viens de le réessayer par curiosité, chargement d'un film puis des sous-titres : les sous-titres ne s'affichent pas (sans message d'erreur, bien sûr) alors que mplayer n'a aucun problème avec. Poubelle.

C'est comme Sound Juicer qui marche moins bien qu'un vieux grip non maintenu. Quand on redéveloppe tout de A à Z, vaudrait mieux s'assurer que le résultat est à la hauteur...

il semble bien que Canonical ne contribue pas du tout à la mesure de sa popularité parmi les GNU/Linuxiens

Mandriva, par contre, contribue bien à la mesure de sa popularité récente : 0.58% des commits :/

Je vais un peu dévier du sujet, mais en ce qui concerne le financement des FAI, pourquoi tant de monde (j'ai l'impression) est-il opposé à la facturation au débit utilisé ? Pour moi ce n'est pas un critère qui casse le principe de neutralité, et permettrait d'éviter que les FAI aient cet argument fallacieux du « ils abusent de l'illimité ! » (c'est écrit illimité, comment pourrais-je en abuser ?)

Un argument pratique est qu'autant il est facile de prévoir et maîtriser combien de temps on passe à utiliser un moyen de communication (cas du téléphone), autant il est difficile de prévoir et maîtriser quelle quantité de données va être transportée, vu que ça dépend de la façon dont le fournisseur de services (l'éditeur du site Web, par exemple) a implémenté son offre. Pour le particulier moyen, c'est probablement un cauchemar.

Sinon, dans l'idéal, ce serait une bonne chose, parce qu'en plus ça ferait revenir l'Internet vers une culture du texte (infiniment plus léger que les vidéos et autres kikoolol multimédia).

D'habitude les deux points forts sont la rapidité à l'écriture et la scalabilité.

Mais de façon systématique la rapidité à l'écriture est obtenue en ignorant les contraintes ACID. On doit pouvoir faire la même chose en changeant quelques attributs de configuration dans PostgreSQL (par exemple en désactivant fsync...).

Quant à la scalabilité, il faut vraiment y aller pour avoir besoin de plus d'un serveur de bases de données de nos jours (sachant que même des serveurs d'entrée de gamme peuvent avoir 8 ou 16 coeurs, et que les disques SSD sont de plus en plus abordables). Les architecture astronauts du Web 2.0 aiment bien s'imaginer que n'importe quel site Web va recevoir le même trafic qu'un Twitter, un SourceForge ou un Facebook.

- Il y a aussi pas mal d'applications qui profiteraient très bien d'arrêter d'utiliser HTTP comme protocole de transport universel et développer SCTP ce serait pas inintéressant

Il faudrait déjà savoir quelle est la répartition du trafic.
Il y a environ 5 ans, la moitié du trafic français était du peer-to-peer (source gros opérateur), si me je souviens bien.
Aujourd'hui, j'imagine que le peer-to-peer a peut-être un peu régressé, mais que Youtube & co ont explosé. Certes, c'est du HTTP, mais avec un overhead d'encapsulation théoriquement très faible vu que les fichiers sont énormes.

La saturation peut être éviter avec de l'investissement et donc pas besoin de QoS dans ce cas là.

Surtout que, je ne sais pas pour vous, mais de mon côté on ne la voit pas arriver, la saturation. Depuis la bulle Internet, les opérateurs ont tendance à provisionner beaucoup de bande passante, et les débits domestiques ont explosé.

C'est d'une part parce qu'il y a un bug dans LinuxFr qui empêche d'en mettre une après le guillemet ouvrant (il sort alors de l'UTF-8 invalide), et franchement y'a pas toujours le temps de passer en mettre partout ailleurs.

Suffirait que le moteur de Linuxfr applique automatiquement certaines règles de typographie française, ce que certains logiciels font depuis des années (SPIP depuis dix ans).

En demandant un "fait" concernant Dieu, tu demandes bien une preuve de son existence.

L'ironie passe assez mal par écrit

Heureusement que Voltaire a réalisé son oeuvre sous forme de vidéos Youtube.

On peut aisément te répondre que « le mécanisme de la science récompense le révolutionnaire qui remplace les théories imparfaites du passé par de meilleure théories explicatives » est en soi le dogme de la science.

Un peu comme, si tu veux, le changement perpétuel est ce qui fonde la stabilité du capitalisme moderne (qui s'effondrerait sans croissance, sans gains de productivité continus, sans foison de nouveaux produits, etc.).

Le fait est que j'attends toujours qu'on me présente Dieu. Il n'y pas le moindre "fait" concernant un Dieu quelconque.L'existence ou la non existence se prouve, elle est ou n'est pas. Et pour Dieu, il n'est pas.

Bah.... Prouver l'existence par les faits, sur le plan philosophique, c'est plus que tiré par les cheveux. Comment prouves-tu l'existence des idées ? Où sont-elles ?

N'importe quel croyant convaincu peut te répondre que le recours aux faits matériels est un argument matérialiste et scientiste, et il aura parfaitement raison de le faire. La science est un moyen (certes beaucoup plus efficace que la moyenne :-)) d'expliquer le monde, mais elle n'a jamais constitué l'alpha et l'oméga de toute la pensée humaine.

La plupart des implémentations nosql n'ont pas besoin d'outils de mapping

Mais mon coco ce n'est pas une question de besoin (on peut très bien accéder à une base SQL sans ORM), c'est une question de commodité.
Maintenant si tu penses que de simples correspondances clés / valeur, ou bien des documents JSON, permettent d'écrire des applications sans se fouler, je te souhaite bonne chance au pays des bisounours.

N'empêche qu'en termes de sémantique il y a suffisamment de convergence pour que des ORM existent et fassent abstraction de tout ça.

Oui mais a nuancer avec le fait que les gens ont aussi Windows chez eux

Ça ne veut pas dire qu'ils sachent s'en servir.

En même temps, si les gars faisaient de l'assistance personnalisée gratos pour tout le monde, ce seraient eux les pigeons.

Un peu comme une mailing-list de logiciel libre où on ne répond qu'aux gens qui ont payé un écot ? C'est ça ? Hum.

rpmdrake a toujours été relativement lent. Ceci dit quand on ne passe pas son temps à ajouter ou enlever des logiciels, ce n'est pas trop gênant.
C'est vrai que pour un premier contact ça peut être rebutant.

En C++, on peut gérer manuellement la mémoire si on a envi de faire le pro, on peut utiliser les pointeurs intelligents qui sont une alternative intéressante aux ramasses miettes (plus d'opérations, mais plus de constances et pas de consommation mémoire inutile), on peut utiliser un ramasse miettes, ou tout autre système.

Oui, on peut (« si on a envie de faire le pro », ce qui résume bien la motivation principale : je veux rejouer la bonne vieille légende du programmeur bas niveau qui maîtrise tout et écrit son gestionnaire mémoire à la main).
On peut aussi faire de l'assembleur pour s'affranchir de l'ABI imposée par le C, ou faire du passage de continuations, ou inventer sa propre représentation de nombres à virgule flottante.

La question, c'est de savoir pourquoi on aurait besoin de le faire (mis à part la motivation citée plus haut, toute psychologique). Et là, pour 99% des applications, il n'y a aucune réponse, parce qu'une gestion automatique conviendrait parfaitement et ferait de plus gagner énormément de temps d'écriture de code et de mise au point.

L'exemple typique, c'est les fichiers de config (.ini). Sémantiquement c'est un ensemble de clés / valeurs, mais si tu veux générer un .ini qui soit facile à reprendre par l'utilisateur, tu as aussi envie d'écrire les entrées dans un certain ordre.

Dans ce cas, c'est à se demander pourquoi si peu de projets C++ utilisent une telle bibliothèque, même ceux qui ne sont pas vraiment bas niveau. Bon, évidemment, aujourd'hui les projets qui n'ont pas d'exigences bas niveau sont codés en C#, Java ou Python, mais il y a 10 ans ce n'était pas le cas... Et quand j'ai fait du C++ je n'ai jamais entendu personne envisager l'utilisation de telles bibliothèques, alors même qu'il n'y a rien de plus chiant que de passer son temps à écrire des destructeurs.

Un problème culturel peut-être ?
Ou peut-être, vraiment, le fait que ce n'est pas supporté en standard est-il un gros frein à l'adoption... Ce qui apporterait de l'eau à mon moulin.

Si un logiciel équivalent est écrit avec un ramasse miettes de merde, il va consommer dés le début 120Mo de trop, sans amélioration possible.

Tout l'intérêt du ramasse-miettes intégré au langage, c'est qu'au lieu d'avoir un "ramasse-miettes de merde" spécifique à chaque logiciel un peu compliqué, tu as une plateforme commune qui est relativement mûrie et débuggée, et bien réglée (ou réglable, d'ailleurs).

C'est comme un compilateur : ça abstrait et mutualise un travail fastidieux (la traduction d'instructions haut niveau en code assembleur) au prix d'une petite perte potentielle d'efficacité par rapport à l'écriture d'une gestion bas niveau écrite à la main.

Après il y a toujours des inconditionnels de l'écriture d'ASM à la main mais, s'ils étaient encore nombreux dans les années 90, ils sont totalement marginaux aujourd'hui et font figure (fort compréhensiblement) de gentils zozos.

Les erreurs de corruption de la mémoire quant à elle sont plutôt rare, car si le logiciel est correctement testé, ça plante à la figure, et un débuggeur insulte assez correctement les developpeurs.

N'importe quoi. Correctement testé ne veut pas dire que tous les cas de figures sont prévisibles, et exhaustivement énumérables (sauf logiciel très simple). C'est d'autant plus le cas si le logiciel est multithreadé, d'ailleurs, à cause des problèmes très subtils que cela peut entraîner.

Dans le cas de Python, on trouve encore aujourd'hui des problèmes de gestion mémoire sur du code écrit parfois il y a 10 ou 15 ans. Je parle évidemment de l'interpréteur Python, plus précisément de la partie écrite en C... Après, libre à toi de penser qu'on fait de la merde et que tu es plus compétent.

Je ne vois pas le rapport. Je parle d'un ramasse-miettes en standard et intégré à la sémantique officielle du langage, pas d'une bibliothèque tierce partie avec sa propre API.
Sinon, C aussi dispose d'un ramasse-miettes si on ajoute les bonnes bibliothèques.

Peut-être, et alors ?
Le fait est que Java est un langage dont les allocations et désallocations sont gérées en standard par un ramasse-miette, ce qui rend la programmation Java fondalement différente de la programmation C++. Que ce soit lent ou pas n'est pas la question.

(ensuite, je ne connais pas les implémentations Java, mais j'imagine que 10 seconde pour une collection complète, c'est sur des jeux de données sacrément costauds, ou des applis complètement mal écrites)

Je ne comprends pas comment tu peux affirmer que Java est bien mieux que C++ puisque ces deux langages ont presque la même syntaxe, les mêmes paradigmes, etc.

Ah, oui, c'est bien connu: C++ fournit un ramasse-miettes.