ragoutoutou a écrit 1515 commentaires

... c'est pas ceux qui font la paystation?

ok, je ->[]

Dans un système de hosting partagé, l'hébergeur gère les comptes de ses clients, pas les softs qui y sont installés...

Bon, ce serait sympa si l'hébergeur pouvait fournir un diagnostique, mais il est probable qu'il se soit contenté de constater une anomalie dans l'utilisation des ressources réseau, un usage abusif du disque, un envoi massif de mails, un défaçage sauvage, et ait notifié le client pour ce problème en ayant éventuellement pris les mesures les plus rapides pour ne pas impacter les autres clients.

C'est à l'hébergé qu'incombe la responsabilité des applications qu'il met sur son compte, c'est à lui de déterminer ce qui ne va pas. De même, il est normal que l'hébergeur ne communique aucune info sur son client en dehors d'une procédure légale.

En quoi l'AGPL va t'il aider?

Faudrait un peu développer, il y aurait un intérêt a avoir l'AGPL dans le cas où un utilisateur est incapable de diagnostiquer un bug?

L'AGPL serait-il capable de contraindre l'hébergeur à analyser le problème?

Merde, mon complexe du "je me crois encore en avance sur mon temps" a encore frappé...

... après ça faudra pas s'étonner si je laisse encore cramer le repas...

Ben, euh... ils l'ont depuis un bout de temps le corps...

Et toi, que faisais-tu entre le 7 Juillet 2009 et le 26 août ?

http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2008/07/07/(...)

L'informaticien compétent et à fond dans son boulot en voit 11 dans ladite phrase...

il faudra alors que redhat change son contrat de maintenance, parceque pour le moment, il me semble que les utilisateurs s'engagent à ne pas utiliser des méthodes autres que les canaux officiels pour les updates...

bin franchement, je trouve débile d'avoir toutes les machines qui pointeraient vers un RHN sur Internet

Vu le prix du satellite, de nombreuses entreprises le font encore...
RedHat donne le choix entre une solution que tu qualifies toi-même de débile et une solution onéreuse pour un petit parc... même quand on veut juste pouvoir lancer des "yum install" localement, il faut passer par là si on veut avoir les mises à jour.

Plutôt que de tortiller vaniteusement sur les termes à utiliser... ce serait bien de débattre sur la plaque plutôt qu'à côté.

Mon propos concernait le risque lié au fait que RHN permet de pousser les mises à jour sur les machines inféodées à ce système... risque théoriquement mitigé par la signature cryptographique des paquets.

Le jour où un rigolo prend le contrôle de RHN ainsi que des mécanismes de signature, ça va faire très mal pour les clients qui auront laissé leurs machines inféodées à RHN.

Figures-toi que dans une entreprise avec un large parc, on essaye de garder le contrôle des mises à jour. On teste, et sur les éléments critiques on fait des tests de non régression avant de prendre le risque de mettre la production par terre.


Le truc amusant via RedHat Network et sa belle interface, c'est que tu peux pousser directement les mises à jour sur les serveurs que tu gères depuis cette interface qui se trouve sur un serveur web sur internet... un beau risque inutile.

Dans le cas où les signatures et le serveur RHN sont compromis, l'attaquant peut pousser lui-même les mises à jour sur les machines enregistrées... c'est pas beau ça?

Inféoder les serveurs de son lan à un serveur sur internet sur lequel on a pas de contrôle, c'est une mauvaise pratique de sécurité.

pour ne pas vouloir inféoder les serveurs RedHat de sont entreprise à des systèmes de gestion comme RedHat Network...

Déjà les mises à jour de sécurité compromises, c'est grave, mais imaginons que les serveurs de gestion RHN se fassent hacker, c'est la porte ouverte à combien d'entreprises pour le hacker s'il arrive à forcer la mise à jour sur les machines enregistrées...

Mon poste de travail sous ubuntu est à 3m d'un rs6000 et 5m d'une workstation sun :)

mais cela reste qu'il n'est pas "la victime" de la contrefaçon au sens de la loi

Donc au sens de la loi, si j'achète à mon insu une aspirine contrefaite et que du coup je ne guéris pas, c'est Bayer la victime et pas moi?

C'est pas une victime mais un "dommage collatéral" a mon sens : il a pas accepté le contrat de la gpl, donc il ne peut pas etre victime du non respect de ce contrat.

Il n'a pas accepté le contrat gpl parcequ'on ne lui a pas proposé, mais la licence GPL étant appliquée au produit initial et donc sur les dérivatifs, l'utilisateur est en droit de réclamer les droits inhérents à cette licence s'il peut prouver que c'est un dérivatif.

Pour le lossless en H.264, l'encodeur prend un gros bitrate, fait la différence entre l'image après compression et la source et compresse le résultat dernière avec un algo lossless de sorte qu'il est possible de reconstituer EXACTEMENT la source au pixel près.

C'est ce qui est le plus proche de l'optimal, h.264 est prévu pour ça, c'est dans la norme.

La majorité des compressions audio/vidéo lossless est basée sur cette méthode.

La victime d'une contrefaçon du logiciel ... c'est pas l'utilisateur mais l'auteur.

Il y a aussi préjudice pour l'utilisateur... c'est même la première victime du non respect de la licence. Un préjudice pour l'auteur serait beaucoup plus difficile à prouver vu les termes de la GPL...

La victime ici ce n'est PAS l'utilisateur

Si, car l'utilisateur ne peut jouir des droits et libertés qui lui sont conférés par la licence GPL.
L'utilisateur d'un logiciel sous GPL a des droits, si ces droits sont interceptés et supprimés par un intermédiaire, c'est bien l'utilisateur final qui est lésé, pas juste l'auteur initial du soft.

Euh, c'est un journal, pas une dépêche...

Il y a une liberté d'écriture et de publication différente entre journaux et dépêches, c'est pour ça qu'il y a des journaux et des dépêches et pas juste des dépêches.

Pinailler en brandissant les règles éditoriales des dépêches pour un journal, ce n'est pas pertinent.

mais non, reviens...

désolé, je voulais pas te vexer...

Bah, pas la peine de multiplier les licences, c'est un coup à en oublier une et à se sentir con le jour où on a une incompatibilité.

Une licence style BSD comme licence "intermédiaire" avant de dériver au cas par cas vers les licences adaptées à chaque projet, c'est pas plus mal.

Pour arriver à une solution globale de traduction/localisation, il vaut mieux une approche généraliste spécialisable au cas par cas plutôt qu'une solution multi-spécialisée qui tombera bien à un moment où l'autre sur une limitation.

Mwais... soit... on peut prendre un ton ironique, voir sarcastique, reste que jouer sur le "made in", c'est faire un appel un poil malhonnête à la fierté nationale , et ça fait la négation des dépendances et des communautés gravitant autour du produit...

Et made in France siouplait

Vu le nombre de personnes à travers le monde bossant sur ffmpeg ou des librairies dont il dépend, je trouve que c'est un argument un poil fallacieux...

D'ailleurs, le projet est hébergé sur un site d'extension .hu

Dans un écosystème libre avec des collaboration entre développeurs du monde entier, la notion "made in" n'est pas réaliste et va même un peu à l'encontre de cet esprit de collaboration.

Pour le moment, le meilleur codec proposé pour la vidéo par l'industrie est le h264, il est de mieux en mieux supporté, y compris par des projets libres comme x264... c'est lent à la compression, mais pour de l'archivage comme pour de la diffusion, c'est très efficace, et la qualité n'a rien à voir avec du xvid.

En plus, il n'est pas spécifié le nombre de niveaux de récursivité maximum à utiliser... donc la question peut faire planter celui qui y répond.

Trop fort, même quand on parle d'érosion des droits des individus, de confiscation abusive, il y en a qui arrivent à faire du "product placement"...

Ben oui... depuis la fin de la guerre froide, les services de renseignements US ont été utilisés largement pour aider les entreprises US face aux nôtres ...

Nous sommes l'ennemi...