TImaniac a écrit 6420 commentaires

Ah oui j'oubliai, ils sont en parfait accord avec la GPL, ils diffusent eux même le kernel :
ftp://ftp.free.fr/mirrors/ftp.kernel.org/linux/kernel/v2.6/(...)

Pour te rendre compte qu'ils ne diffuse que du libre :
ftp://ftp.free.fr/mirrors/(...)

Enfin franchement tu nous as toujours pas dis chez quel FAI tu étais, qu'on voie à quel point ton choix a été éthique, voir si tu vas jusqu'au bout de tes idées, ou si cela relevait juste de la réaction primaire "débile".

C'est cela que j'aime bien avec toi, ce avec quoi tu n'es pas d'accord, passe très vite dans le débile.
Ta réaction étant extrémiste, la mienne l'est d'autant :)

en téléchargeant de sourceforge, ou rmpfind ou rpmbone ou autres.)
Forcement, ils font pas mirror de ces sites là. Ils font pas mirror de toute la planète non plus. Mais ils font pas mirror de telecharger.com par exemple. Ils ne font que dans le libre. Et ca y'a peu de boite qui le font.

ouais limite limite avec le kernel linux.
Et d'un : t'es même pas censé savoir ce qu'il y a dedans, donc t'es même pas censé pouvoir juger de ce qu'ils respectent ou pas.
En attendant t'as les sources :
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/(...)

ils contribuent à VLC ?
Oui. Toutes les améliorations ont été ramené dans la branche officielle de VLC. Bref, c'est pas un VLC modifié à l'arrivée, et tout le monde est gagnant.

de base qui fait oublier "relativiser" les choses.
ta réaction me paraît pas très relative : refuser toute sorte de transaction avec cette société relève plutôt de la réaction primaire, que j'ai qualifié, non sans réflexion, de "débile".

On s'en fou que ca soit crackable. Ce qui importe c'est que cela suffise à rassurer les majors et suffisant pour concurrencer les offres de MS et autre Real. Suffisant pour que le format associé (au pif ogg) continue sa route chez les fabriquants de hardware.

Oué bon t'as rien compris à ce que je voulais dire. Mon objectif est le même que le tiens, je m'interroge juste sur la manière : n'est-t-il pas préférable de commencer par "imposer" (ou tout du moins introduire) une techno libre et en parrallèle promouvoir les oeuvres libres ?
Pour moi il va être difficile de réaliser la 2ème partie sans avoir le support technique de la première partie. Alors maintenant explique moi comment tu compte imposer le support technique libre si tu ne veux pas te mettre au même niveau que la concurrence. Combien ont dû se battre pour avoir la paix ? (à méditer)

Tu oublies plein de choses:
Je n'oublies rien : je pense qu'il faut effectivement promouvoir les oeuvre libres, les oeuvres sans DRM, etc. Mais pour cela il faut commencer par avoir une techno implémenter chez les consommateur : pour cela il faut proposer ce que propose le concurrent, cad des DRM. Comme je l'ai déjà dis, après chacun est libre de les utiliser ou non.
Refuser d'intégrer les DRM, c'est aussi se fermer la porte de nombreux constructeur, et donc voir la plupart des supports physiques utiliser des formats non libres, bourrés de DRM. Je préfèrerai voir apparaître des DRM sur les bases d'un format libre (déjà une victoire), tout en promouvant les artistes qui ne les utilisent pas (mais qui peuvent être diffusé, le support technique ogg étant alors diffusé).
Je sais aps si tu vois ce que je veux dire.

En fait pour moi je me fou pas mal de la sortie TV, c'est plutôt l'acquisition vidéo et tuner sur ma radon AIW que j'aimerai faire marcher sur X.org :-/

Tu n'as rien n'a craindre : tu as signés. Si jamais quelqu'un d'autre à fait la manipulation à ta place (ede manière frauduleuse), tu peux toujours te retourner contre ta banque : il sera alors facile de démontrer que la signature a été falsifiée, auquel cas tu pourras être remboursé intégralement.

Le plus genânt en fait c'est si tu te fais piquer ton code secret : celui-ci fait office de signature, et tu es bien dans la merde si quelqu'un l'utilise avec ta carte bleue : tu ne peux rien prouver.

Free participe au libre :
- ils fournissent des serveurs mirroir (même si cela leur fait de la bande passante, ils ne sont pas obligés)
- ils contribuent à VLC (Free Player)
- ils font confiance et respectent les licences libres
Même si leur service commercial (concernant annu) est limite, il ne faut pas rejeter en bloque toute une société qui n'a pas que des comportements anti-éthique.

Maintenant je donne mon avis personnel :
je trouve ta réaction complètement débile, à moins que tu sois un ermite qui a une connection internet par médiation au fond d'une grotte. Comment peux-tu trouver un FAI qui n'a rien n'a se reprocher ? Qui n'a aucune pratique commerciale douteuse ? Qui n'attaque pas son concurrent ? Qui ne tente pas de préserver sa propriété intellectuelle ?

Tu m'appelles si t'as trouvé ce super FAI éthique.

Effectivement, que vas-tu dire si les FAI doivent doubler, trippler, décupler ou centupler leurs serveurs smtp pour envoyer le même nombre de mails de leurs clients NORMAUX ?
Mais arrêtez de fumer la moquette ! Pourquoi faudrait-il plus de machines ? Il n'est pas question de rajouter des for(inti=0;i<10000000;i++)nop(); entre chaque envoi, il est question de refuser toute tentative d'envoi de mail trop "fréquente". Cela n'influerai en rien sur la capacité du serveur smtp à traiter des envoi d'émetteur différent. Au contraire : le serveur concerné ne serait pas "submergé" par les demandes des spammeurs.

Mmmmh je vois que tu n'as pas changé d'un poil ton document. C'était bien la peine de faire appel à la communauté à travers un journal pour le faire évoluer. La remarque concernant l'obligation de MS de "clarifier" ses conditions de licence concernant d'éventuel brevet avant normalisation auprès de l'ECMA aurait par exemple été interessante à ajouté. Mais visiblement ca va pas dans le sens de ta conclusion.

Il me semble que la seule solution soit d'utiliser les drivers Gatos. Malheuresement sur leur site officielle seule des versions pour le serveur XFree86 sont disponibles, alors que la plupart des distributiions (dont mandriva) sont passés à X.Org.
Je crois que sur le serveur Subversion de Gatos il y a une branche X.Org, tu peux peut être explorer cette voie...
Bon je sais ca t'aide pas beaucoup mais bon :-/

multithreader ne changera rien : le serveur t'imposera un temps "d'attente" entre 2 envois, que tu es un ou plusieurs thread, une ou plusieurs machines.

En tout cas il est clair qu'il faut établir une relation de confiance entre l'expéditeur et le FAI, les FAIs étant actuellement le principal vecteur technique permettant ces envois simultanés, une gestion plus "indivivudelle" et basé sur une whiteliste permettrait d'assurer une certaine "sécurité.

Le risque est de voir apparaître ce genre de service "+" (l'envoi de mails en masse) comme un service payant.

Enfin dans tous les cas il est clair que les solutions techniques sont dans les mains des FAIs, qui sont les seuls intermédiaires de "confiance" (ou tout du moins facilement blacklistable) qui peuvent intervenir facilement.

Vi mais il faut se rendre à l'évidence que les DRMs gagnent du terrain, Apple en étant le principal vecteur avec son iPod.

Je ne cherches pas de compromis, en soit les DRMs n'ont rien de mal, c'est l'utilisation qui en est fait qui peut être mauvaise (et/ou discutable). Proposer une techno à base DRM libre, autour du format ogg par exemple, est une manière "d'inflitrer" le milieu industriel sans se laisser distancer et marginaliser par les concurrents. Après à nous de convaincre les artistes et consommateurs d'utiliser les versions sans DRM de ogg. Mais il sera toujours plus facile d'imposer le format ogg s'il est présent sur les périphériques (et pour cela il faut se battre contre la concurrence et donc proposer des DRM), ca sera déjà un match de gagner.
Le format ogg a peu à peu gagné en notoriété et se voit même intégré dans certains périphériques portables. Il serait dommage de perdre cet avantage par refus d'intégration d'une techno, tout cela parcqu'elle peut être mal utilisée. Il me semble qu'il y a déjà eu une tentative d'introduction de protection du style DRM dans Ogg, je suppose que c'était dans cet objectif. En tout cas les "opposants" à la libre circulation des reproductions d'oeuvres culturelles l'on bien compris, même si les ayants droits l'on compris : les réseaux P2P ont des avantages, et peuvent être utilisés de manière différentes. A nous de ne pas ratter un train, quitte à détourner la ligne.

. Si ca n'est pas arrive en Qt, c'est que celui de KDE satisfait bien les gens.
ou que Qt ne satisfait pas. Chacun sa conclusion hein ;)

houlà je dis pas DRM = populaire, je dis DRM = inéluctable. Les majors sont en train de bourrer le crâne des consommateurs qu'il n'y a pas d'alternative à leur modèle commercial, et que dans tous les cas il faudra les payer. La malheurese décision de la cour suprême va dans ce sens en autorisant la poursuite des "alternatives". Alors j'en arrive à me poser une question : doit-on continuer à se battre contre les DRM en les boycottant, ou doit-on les adopter ?
J'ai un net penchant dans la première solution, mais d'un autre côté, connaissant la force de frappe de ces multinationales, je me dis qu'il serait peut être judicieux de proposer en parallèle un concurrent aux DRM proprio, basé sur un standard libre : si jamais on doit se coltiner ces formats par la force des choses, autant qu'il y en ai un que l'on puisse lire. Même si c'est regrétable d'en arriver là, les formats comme ogg n'y gagneraient-t-ils pas en adoptions auprès des constructeurs/fournisseurs s'ils proposaient des fonctionnalités similaires aux DRM proprio mais dans un esprit libre ?
Je suis conscient que c'est contradictoire avec l'esprit du libre, mais devons-nous prendre le risque d'être marginaliser, et de ne pas avoir d'alternative dans leur vision économique ?

Ce ne sont que des questions que je me pose, dans un monde idéal je prônerait effectivement l'abandon des DRMs... mais d'un autre côté le meilleur moyen de changer les mentalités n'est peut être pas de se braquer entièrement contre les idées reçues, il faut parfois savoir adpoter pour mieux noyer.

C'est exactement le genre de problèmatique auxquelles je voulais arriver :)

En quoi mon commentaire est inutile ? Vous ne croyez pas au fait que les DRM "risquent" de s'imposer ? Et que nous n'avons aucune alternative libre à proposer et donc à supporter ?

Tant que VLC ne gérera pas les formats DRM ca risque pas malheuresement :-/

il soit nécessaire de changer la signature de la classe...
Justement c'est là le problème : les clauses "throw machinException" ne font pas parti de la signature. Le runtime ne détectera donc pas d'incohérence et acceptera d'utiliser cette lib au même titre que l'ancienne. Et on se retrouve avec une exception non checkée. Quel va être le comportement de l'appelant qui va se bouffer cette nouvelle exception ?

lors de l'installation chez le client t'es obligé d'utiliser le class path
C'est bien ce que je dis : c'est pas terrible :) C'est quand même plus simple d'avoir un système de versioning avec la possibilité de faire coexister plusieurs classes "identiques" au niveau de la signature, mais pas au niveau des versions.

L'exemple des méthodes virtuelle dans les liens que j'ai cité sont également un on bon exemple de choses "dangereuses" en Java lors de maj/déploiement/utilisation.

Non justement corriger un bug ne veux pas dire modifier le comportement à l'extérieur de la classe
Quel est l'intérêt de corriger ce bug s'il n'a aucun inpact sur l'utilisation de la lib ? J'ai du mal à cerner quand même... Quand on corrige un bug c'est bien qu'il y a un inpact extérieur, sinon c'est pas vraiment un bug... un bug c'est un comportement inatendu. Si tu veux le corriger, tu dois bien modifier le comportement :)

le cas où celà serait suffisement critique pour qu'on doivent redéfinir la classe, c'est qu'il vaut mieux mettre l'ensemble des programme à jour et en attendant utiliser la variable classpath.
D'où l'intérêt d'avoir un système de versionning fin, pour éviter d'avoir à définir une nouvelle classe, sans avoir à mettre à jour l'ensemble des programmes, sans avoir à modifier de variables.

Quand à dire que le classpath relève de la bidouille
Au sens c'est pour contourner l'absence de gestion de version par la plateforme.

j'espére simplement que tu n'es pas chef de projet parceque si les malheureux doivent réécrire chaque classe qui implémente ou appel la class que tu corriges
Ben justement c'est ce que je veux éviter. T'as jamais eu de problème de déploiement avec des conflits entre plusieurs libs ?

Un autre exemple avec les méthodes virtuelles (toujours à propos de versioning) :
http://genamics.com/developer/csharp_comparative.htm#13(...)
Quelques explications :
http://artima.com/intv/nonvirtual.html(...)

Mmmmh peut être un début d'explication glané dans un commentaire de linuxfr :
"Zope est exclusivement utilisable comme plate-forme web (site internet/intranet , administration, back-end). Je ne crois pas qu'on puisse en faire autre chose.

J2EE ne se limite pas à cela, en fait je ne vois pas trop l'intérêt de comparer les deux. A la limite comparer Zope et les serveurs applicatifs JSP/Servlet aurait une utilité, et encore..."

C'est quoi toi ton explication au relatif "flop" de Zope ?

Qu'es-ce qui rend impossible d'appliquer le modèle pour les serveurs d'applications ?
Peut être parcqu'on n'utilise pas un tracteur pour faire une course formule1, et inversement.

Pour la partie 2 je parler du rapprochement de zope et IBM pas de sun :
J'ai bien compris, je voulais juste indiquer que c'était également un objectif de Sun, Sun et IBM qui viennent d'ailleur de signer un nouvel accord pour prolonger leur partenariat pour 10 ans autour de Java.

Qui parle d'utiliser les technologies php 5 pour les serveurs d'applications après c'est toi qui parle de les utilisés uniquement comme facade.
Moi je parle surtout du présent, de ce que je vois actuellement. PHP 5 n'a aucun modèle de composant, il faudra donc le définir. Bref, en l'état actuel PHP n'est pas un serveur d'application.

ça ne facilite pas forcément la maintenance ça permet surtout de ce retrouver avec des martaux-piqueurs pour enfoncer des clous.
Tout à fait, il n'est pas forcement pertinent d'utiliser une usine à gaz pour tout.

on sait toujours pas avec quoi vu que la plus grosse partie des API ne le sont pas
Oué enfin les 3/4 sont portables (et portés : http://mono.ximian.com/class-status/mono-HEAD-vs-fx-1-1/index.html)(...) quand même faut pas abuser. Il y a en gros qu'un truc qui n'est pas porté : la partie COM+ (et donc tout ce qui est lié aux serveurs d'application), empêchant Mono d'être une solution d'entreprise concurrente de J2EE. Enfin il reste tout de même un fossé énorme entre ASP.NET et PHP par exemple. Enfin là on sort du débat initial quand même ;)

alors que tu sous entends deux lignes au dessus que c'est pas possible...
Ben je t'ai dis, je veux pas trop me tenter à donner des explications sur le relatif "flop" de Zope (faut dire ce qui est, le soufflé est retombé). Perf ? Fonctionnalités ? Si c'est un serveur d'application au même titre que Rails dans ta tête c'est un début d'explication ;)
Enfin je vais fouiller un peu Zope pour voir ce qu'il y a dedans, par curiosité.

Oué mais y'a pas de censure, et tu sens qu'il y a des passionnés derrière, des gens qui postent des news à 3h du mat' le dimanche matin ;)

Oué bah la news pointe justement ce journal :) (D'ailleur il est marrant de constater que le site OSNews anglophone réagit officiellement à des réactions sur LinuxFR :) )

Il y a une réplique officielle sur OSNews avec un pointeur sur le journal de linuxfr avec des explications. Elles me parraissent tout aussi pertinentes que le commentaire que tu cites.
Je ne cherche pas à crédibiliser ce sondage, je cherches juste à montrer que les sondages, voilà quoi :)