Moonz a écrit 3538 commentaires

Haaa, c'était pour ça que j'arrivais plus à avoir ce train ?

Je sais que je fait des fautes d'orthographe inexcusables, mais c'est pas une raison pour considérer mon post comme écrit dans une langue étrangère et de feindre de ne pas comprendre le conditionnel (doute)...

Après, si tu veux te rendre constructif, tu peux aussi me critiquer intelligement en m'expliquant rapidement, ainsi qu'à tous ceux ici qui n'ont pas silverlight (une énorme majorité je pense), ce qu'a ce site de techniquement plus complexe que Google Maps, qu'on puisse débattre avec plus de matière que "le libre sai nul sa sé pa fèr kom silverlight"

J'ai pas silverlight donc je sais pas ce qu'on doit remplacer. Mais je doutes qu'ils aient fait quelque chose de plus évolué que Google Maps, qui lui repose sur des technologies libres et ouvertes...

> La base du pb est sans doute que les API changent trop souvent
Lesquelles ?
Gnome/KDE ? stables sur les versions majeures
glibc ? standardisé (POSIX/SUS), au niveau stabilité on peut pas rêver mieux
les appels systèmes ? ils ont pas bougé depuis au moins Linux 2.0
Haaa, tu veux parler de "l'API" interne au noyau ? Franchement, un soft qui tape direct dans l'API du kernel, j'en veux pas :)

> Cela serait bien de pouvoir trouver une sorte de surcouche aux gestionnaires de paquets des distributions, qui permettrait d'utiliser un nom générique aux paquets

D'autant plus qu'il y a déjà les outils pour: http://www.packagekit.org/pk-faq.html#catalogs

> MAINTENANT vous pouvez moinsser !
Non, non, t'arrêtes pas, juste quand je commençais à te plusser :). C'est très divertissant...

Avidemux a un filtre pour faire ça. Maintenant, je connais pas l'algo d'interpolation utilisé, mais si ça t'interesse, le code source est ici: http://svn.berlios.de/wsvn/avidemux/trunk/avidemux/avidemux/(...)

> Un seul processus ne peut pas à lui tout seul mettre à genoux le système entier
:(){:|:};:

(bon, d'accord, c'est pas à strictement parler un seul processus)

Ça, ça marche aussi sous Linux.

> A mon avis, si on faisait un référendum pour déclencher une guerre avec dans les 3 mois qui précèdent celui ci
Et ceux en face vont tranquillement attendre le résultat du référendum ? \o/

> Sinon tu peux arreter de psycoter et de dire que 1 W.h = 3600 J
Je te rassure, cette question ne me pose pas de problème.
Ce qui me pose problème, c'est pourquoi diable aurais-je à me poser la question "bon, comment je convertis mes joules/seconde en watt, juste parce que le prof a trouvé amusant de mettre la moitié des données en joules/secondes et l'autre en watt" ? La conversion, je finis par réussir à la faire, merci bien. Mais pourquoi, pourquoi se trainer une unité aussi peu pratique alors que le kilojoule rend aussi bien service ?
J'ai beau chercher, je vois pas. À part peut être du sadisme de la part du corps enseignant...

Ce qui m'a toujours faire perdre mon latin en thermo/electro, c'est le Watt-heure... Joule-heure par seconde, faut chercher dans la RDM pour trouver des unités aussi pourries... Pourquoi pas mesurer des distances en kilomètre seconde par heure, tant qu'on y est ?

Ceci était un message de Front pour l'éliminiation du watt.heure

À l'époque où j'étais sous Gentoo (il y a moins d'un an), le système d'init était en bon vieux bash pas très maintenable...

> les gens achetant de la merde, il n'y en a pas beaucoup.
juste 90% des utilisateurs de PC
(pardon, c'était trop tentant ---->[])

> Fier de ses québécois qui serait assimilé à des extrémistes
> que la langue Française m'est belle.
C'est parce que tu la regardes de travers...

Par curiosité, qu'est que tu entends par "gerer une installation de VMWare" et comment tu fais ça avec PowerShell ?

Conseil d'État, plus haute instance juridique
J'espère bien que Sarkozy, chef de l'executif, n'a rien à voir dans cette décision, sinon, on pourrait réellement le traiter de dictateur...

2: va falloir m'expliquer la relation de cause "m$ détient toutes les clefs" à effet "il pourront ne pas intégrer des fonctionnalités qui seraient très utiles pour les applis libres et qui donc ne seraient pas disponible". Gtk# n'existe pas, on m'aurait menti ?
3: ça pourrait être des siècles que ce serait pas pour autant un "danger"
4: les "gens" dont on parle ici développent des applis libres pour un bureau libre, tu penses vraiment que des devs gnome seraient assez stupides pour se rendre incompatible avec Mono ? Oui, pour les industriels qui comptent sur Mono pour faire du multi plateforme, ça peut être génant. Mais ça tombe bien, ce n'est pas la question ici...

> exit GObject en C, et ça ne marche même pas sous Mac OS X
Sources ? Il me semble que Gtk marchouille pas trop mal sous OSX

Encore une fois: quelle différence avec un éventuel HTTP 2 ? Normal que la compatibilité soit cassée, c'est une nouvelle version. Et dans ce cas, on aurait jamais dû passer à IPv6: ça casse la compatibilité, et MS "aurait pu pourrir volontairement son implémentation", très dangeureux ça...

Je vois toujours pas la différence de la situation entre Mono et HTTP à ce niveau. HTTP actuel est utilisé un peu partout, il serait stupide de le boycotter sous le prétexte "que c'est dangeureux, MS pourrait éventullement pourrir les futures versions". Pourquoi ce serait différent pour le .NET actuel ?

MS peut volontairement mal implémenter n'importe quoi, .NET n'est pas un cas particulier à ce niveau. Abandonnons TCP/IP, HTTP & co, en les utilisant on court le risque que MS puisse l'implémenter de manière incompatible !

> Sinon, ils n'avaient qu'à améliorer GCJ.
Tu t'e pas dit qu'ils pouvaient préférer C# à Java sur le plan technique, tout simplement ?

> il ne faut pas baser des logiciels libre dessus si on veut les faire évoluer avec le langage
En même temps, quand tu développes un logiciel, tu le penses pour le langage actuel, pas une "éventuelle amélioration future du langage". Quand tu fais du Python, tu ne le penses pas "pour qu'il évolue avec Python 3k", quand tu fais du Perl, tu ne te dis pas "je vais le coder pour qu'il puisse éventuellement profiter des améliorations de Perl 6". Et ainsi de suite pour C++/C++0x, et... Mono/C# 4.
Le dev de tomboy qui a choisi le C#, il a choisit le C# de son époque, pas en soupirant après C# 4. C'est pour ça qu'on s'en fout un peu, au final, que Mono soit à la traine. Tomboy fonctionne, il évoluera indépendamment du langage. Aucun danger venant du "retard des devs Mono".

Pour flash, je vote plutôt pour "tumeur" :)