Faux. Si le logiciel sous AGPL est utilisé de façon interne (par exemple sous forme de batch lancé sur le serveur, de logiciel d'administration système, etc.), il s'agit d'une simple utilisation.
Effectivement, ce que j'ai dit n'est valide que pour une utilisation publique... toutefois, force est de constater que dans ce cas, il y a unbe altération des droits d'utilisation.
Oui et alors ? MySQL et Trolltech font de même avec la GPL, est-ce que ça fait de la GPL une licence « pas innocente » ?
Trolltech et Mysql jouent sur les limitations de redistribution, l'Agpl met des limitations sur l'utilisation et l'adaptation aux besoins, ouvrant un nouveau marché pour les doubles licences... au final on crée avec l'AGPL une sorte de sous-logiciel libre créant un monopole en faveur des propriétaires du code quand à toute adaptation en vue d'une intégration avec des technologies non agpl/gpl3 (ce qui est fréquent en entreprise).
Quelle serait la « bonne » réponse selon toi ?
Pas celle là en tout cas... ce n'est pas parcequ'on n'a pas la bonne réponse à un problème qu'il faut systématiquement en prendre une mauvaise pour donner l'impression qu'on veille au grain (en général on voit plutôt cette attitude chez des politiciens populistes comme Sarkozy)
Ce n'est pas au libre de s'adapter au « monde de l'entreprise », c'est au « monde de l'entreprise » de comprendre et de s'adapter, s'il en a envie, au libre.
Grosso modo je serais d'accord, mais le problème est que selon moi, l'AGPL est un mouvement pour inciter les entreprises de développement à passer leurs projets sous une licence vaguement libre mais leur garantissant une non-concurrence sur les adaptations critiques et l'intégration en entreprise. Une limitation sur les libertés d'utilisation et d'adaptation aux besoins est une grave atteinte au modèle libre.
Mon conseil en tout cas à l'attention de tout développeur amené à modifier un logiciel sous AGPL: ne JAMAIS rétrocéder les droits sur les modifications aux auteurs originaux de l'application. Puisqu'on force la main aux utilisateurs pour en faire des contributeurs, il ne faut pas hésiter à empêcher les propriétaires de l'application à faire de la licence proprio sur le dos des contributeurs.
Sans déconner, un logiciel libre qui te pause des problèmes pour l'intégrer dans des logiciels proprios et t'obliges à redistribuer les sources? C'est scandaleux, mais où est passé ce bon vieux esprit du logiciel libre?!
Absolument. Un logiciel libre sous GPL permet de modifier une applications, de l'adapter à mes besoins et de l'utiliser comme bon me semble sans la moindre restriction. C'est la redistribution de l'application qui est soumise à contrainte afin de ne pas me permettre d'endommager les libertés.
Avec l'AGPL, l'utilisation est soumise à contrainte, et la modification de l'application pour l'adapter à mes besoins est également entravée par les modalités de distribution. Si par exemple, je veux intégrer, dans une application AGPL, un framework de sécurité en GPL2 dont je ne suis pas le propriétaire (et que je ne peux donc pas relicencier en GPL3 ou AGPL), je n'ai pas le droit d'utiliser le résultat sur un serveur public car je ne peux satisfaire aux conditions de redistribution, redistribution qui m'est imposée en cas d'utilisation sur un serveur public.
Ah merde, moi qui croyais que c'était la FSF qui poussait l'AGPL
Le A d'AGPL prédate la prise en charge de cette licence par la FSF, en outre des licences similaires existent déjà depuis un bout de temps et font les choux gras d'entreprises vendant du logiciel proprio.
C'est clair qu'en AGPL, ça pourrait poser suffisamment de problèmes aux entreprises désireuses de l'implémenter pour qu'elles continuent sous des technologies bien plus proprio, genre Citrix Metaframe...
je suis ravi de voir l'AGPL donner aux développeurs le moyen d'imposer le partage des améliorations dans ce contexte.
Et oui, on passe d'une logique de liberté à une logique d'imposition.
En fait, avec l'AGPL, on en arrivé à un modèle "code source comme rétribution"... on est plus très loin d'une logique de shareware.
Tu ne dois pas fournir tes fichiers de configuration mais tes adaptations. Si par exemple tu écris un connecteur pour accéder à un backend, genre db, repository, ... tu dois pouvoir offrir tes modifications sous AGPL en même temps que le service... et si ton interface de connexion implique l'utilisation de librairies tierces non-agpl et non-gpl3 tant-pis, tu n'as pas le droit de les utiliser.
Dans le cas donc d'un site web, tu peux te retrouver dans la situation où tu as le droit de modifier et d'adapter à tes besoins, mais pas d'utiliser, ou alors d'utiliser mais pas d'adapter à tes besoins.
Pour moi, l'AGPL reste moins dans l'optique logiciel libre que la GPL car:
- dans l'AGPL on nie l'existence de l'utilisateur côté serveur: on en fait systématiquement un distributeur, ce qui change sérieusement la donne au niveau des libertés: on met des contraintes sur les libertés d'utilisation et de modification: plus moyen pour une entreprise de faire cohabiter des composants proprio (sur lesquels elle n'a pas les droits) avec du libre dans l'exercice de son activité si celle-ci implique une utilisation sur internet. En outre, la contrainte de redistribution crée une problématique supplémentaire dans la gestion des releases sur les systèmes de production et nuit gravement à l'agilité de la solution., voir à la sécurité.
- l'AGPL n'est pas une licence innocente, elle est poussée par des développeurs d'applications commerciales en tant que licence d'essai shareware pour pouvoir vendre ensuite des produits intégrables et proprio p.ex: funambol qui sous prétexte de préoccupations libristes s'est créé un monopole sur son application grâce à l'HPL.
Au final, l'AGPL est une MAUVAISE réponse à un problème réel, une sorte de Patriot Act qui sous prétexte de protéger les libertés des utilisateurs "navigateur" met à mal les libertés des utilisateurs "serveur".
Si le libre avait besoin d'un frein à son adoption dans le monde de l'entreprise, il en a trouvé un. D'un point de vue "utilisateur serveur", l'AGPL n'est pas une licence libre, juste une licence proprio un peu permissive.
Non, ce n'est pas une licence virale, c'est une licence qui va simplement raboter la liberté d'adaptation en lui adjoignant de grosses contraintes.
Pratiquement, cette licence va faire en sorte que les projet seront renforcés, par la contrainte, dans un cadre communautaire en forçant la redistribution de l'application modifiée dès que celle-ci est utilisée publiquement.
Pour le monde de l'entreprise, par contre, cette licence peut être vue comme une annulation des libertés consacrant la double licence AGPL+Proprio afin de permettre aux entreprises de modifier le logiciel et de l'adapter aux besoins si un des besoins concerne l'utilisation publique. En pratique donc, cette licence rend le pouvoir aux développeurs initiaux d'une application web au détriment de l'utilisateur côté serveur.
... voici une licence qui va faire chauffer les services juridiques dans les entreprises...
Un conseil pour les sociétés de service et les entreprises: n'utilisez surtout pas de logiciels AGPL avant d'avoir un avis légal sur cette licence et d'en avoir bien compris les implications, à fortiori pour un portail ou un service sur internet: "adapter l'application à ses besoins" devient une opération beaucoup plus contraignante qu'avec une licence libre comme la GPL3.
Pour le moment, pas vraiment, les n770, n800 et n810 étant des tablkettes internet faisant webphone, mais maemo a vraiment du potentiel quand on voit ce que ça fait.
Évidemment, quand j'accède depuis l'extérieur à l'adresse IP de mon modem/routeur, je tombe sur l'interface d'administration de celui-ci.
Si j'étais toi, je fearais très attention à ce point... c'est un risque de sécurité énorme et il faudrait désactiver l'accès à l'interface de gestion depuis l'extérieur en priorité absolue.
Sinon, OpenVPN, c'est pas mal, mais effectivement, comme mis plus haut un simple forwarding du port ssh peut suffir (et ssh permet de faire du port forwarding pour atteindre les autres ports, sur demande)
La meilleure solution reste de repackager la librairie boost AVEC les bonnes options et d'utiliser ce paquet en lieu et place de celui de la distribution...
Et ici on parle du format OOXML, pas de son implementation dans Office. C'est OOXML qui a ete standardise par ECMA, pas Office.
L'argument n°1 de OOXML est que c'est le format "supporté" par office, en l'absence de ce support office, l'OOXML est un gros "standard" inélégant de 6000 pages, non ISO (contrairement à son concurrent direct), et bourré de legacy office, bref sans grand intérêt.
Si tu peux le lire, qu'est-ce qui t'empeche techniquement de l'ecrire ?
Il suffit que la méthode de lecture soit triviale mais que celle d'écriture nécessite une connaissance particulière.
Tu peux facilement générer des documents OOXML qui, tout en étant conformes à la norme, ne seront pas lus par Office vu que celui-ci n'est pas conforme à cette norme et a des exigences différentes pour déclarer un document valide.
Ce qui me dérange, c'est que tu es prêt à dénoncer la « mauvaise » politique de mise à jour de RedHat avec RHN là où tu encenserais presque celle de Microsoft sous prétexte qu'avec « quelques wget », tu parviennes à récupérer les patchs...
Bon, faut pas tout mélanger, je ne critique pas la politique de mise à jour de RedHat mais bel et bien sa politique commerciale.
Le fait est que chaque fournisseur peut avoir son outil de mise à jour, adapté ou non aux besoins. Je peux parfaitement comprendre qu'une entreprise n'est pas l'autre et qu'une seule taille ne peut aller à tout le monde. Maintenant ce que je reproches c'est cette attitude qui vise à pousser le client vers cet outil de mise à jour, adapté ou pas, bloquant les méthodes plus traditionnelles, pourtant plus simples à adapter aux besoins, apparemment dans le but de maximiser leurs ventes.
Si encore RedHat offrait gratuitement le satellite pour tout achat de 100 licences, je dirais pas, mais là, c'est juste du forçage de main.
Microsoft propose pourtant un produit similaire à RHN, SUS et ne fournit rien pour un miroir très facilement. Et sa politique reste de passer par Windows Update, que ce soit via SUS ou non. Et là, curieusement, on ne t'entend pas.
La politique est certes de passer par windows update, mais elle aisément contournable si on lis la doc technet. Et les outils de patch management tels que SUS sont gratuits (si tu es en règle au niveau licence OS), contrairement au proxy et au satellite.
Oui, mais bon, Nokia bosse déjà depuis un bout de temps sur sa propre solution libre, il n'a pas attendu qu'un acteur comme Google vienne mâcher la tâche...
C'est pas parceque sous windows il faut utiliser des ActiveX pour lire le SVG que le format SVG nécessite des ActiveX pour être lu...
Oui, mais si un document CDF nécessite ou contient un activex pour lire des blobs binaires non documentés qui sont passés en paramètres par le document CDF, ça pose tout de même problème.
Maintenant, j'ose bien espérer que tu ne comptais pas mettre directement à jour tes serveurs en production, même avec les mises à jour de sécurité glanées sur les sites de tes chers éditeurs.
Bien sûr que non... on dirait que tu n'as pas lu tout ce que j'ai mis avant.
Si non, que RHN se fasse compromettre par un attaquant ne change rien au fait que si cela arrive également pour un autre éditeur, tu téléchargerais ses mises à jour sans te poser plus de questions que cela.
Un attaquant ne pourrait sans-doutes pas compromettre les paquets des dépôts, gâce au mécanisme de contrôle de signature. Par contre il pourrait envoyer des ordres dans la limite des fonctionnalités du client rhn.
Les offres de systèmes à base de Linux ne manquent pas. Si un client n'est pas d'accord avec la manière dont c'est géré, il peut également décider d'en changer. Ils ne sont pas non plus obligés de prendre RedHat.
RedHat Enterprise Linux est en sois un excellent produit, à un détail près: une politique de gestion des patchs pas très respectueuse des besoins de ses clients.
En outre, RedHat bénéficie d'un quasi-monopole dans le cadre du support de nombreuses applications tierces, ce qui le rend très difficile à remplacer.
Il n'y a pas de distribution parfaite à l'heure actuelle, et changer de distribution, en admettant qu'il existe une distribution avec autant de certifications tierces, n'améliorerait pas forcément le tableau.
Donc je compte continuer à utiliser encore longtemps RHEL (car c'est un bon produit) ET critiquer la politique d'accès aux patchs (car c'est une mauvaise politique).
Et franchement, ton attitude de "tout ce qui n'est pas fait dans le cadre de RHN est mauvais, les gens sont idiots de vouloir s'en passer quelques soient les besoins" n'est absolument pas à ton honneur. Je ne sais pas si tu bosses pour redhat (ce qui expliquerait cette défense agressive de la valeur du proxy et du satellite), mais si c'est le cas, franchement vous gagneriez à écouter un peu plus vos clients et leurs besoins.
Pour RHN, j'ai l'impression que vous ne l'avez jamais utilisé tellement il y a une idée préconçue à ce sujet.
Pour ma part, j'ai déjà utilisé RHN en long et en large, en passant par les fonctions d'installation, de gestion de config et tout et tout.
Que ce soit la liaison avec RHN soit directe ou via un Satellite, ce n'est pas RedHat qui décide de manière unilatérale des mises à jour mais le client
Si c'est avec RHN, c'est clairement un serveur sous le contrôle de redhat qui donne l'ordre, même si cet ordre est demandé par l'utilisateur. Le fait d'inféoder des machines d'un réseau d'entreprise à un serveur web sur internet est un risque de sécurité non négligeable: que se passerait-il par exemple si le serveur RHN se fait hacker et commence à envoyer des ordres malveillants?
Éventuellement, si la politique réseau le permet (p-ex, le serveur a accès à un proxy), on peut envisager de faire enregistrer les machines sur rhn au moment de l'installation et de couper le lien immédiatement après et à jamais, mais ça nécessite après d'aller gérer les licences à la main dans rhn, ce qui diminue le degré d'automatisation de la tâche).
Ensuite, ce lien entre les serveurs du lan et un serveur sur internet situé aux usa peut interdit dans certains pays comme par exemple le Luxembourg où les règles de confidentialité sont très strictes quand au risque d'avoir des données consultées depuis des personnes non autorisées, à fortiori depuis l'étranger.
Bon, maintenant, il y a le satellite qui adresse peut-être ce problème, mais quand on peut faire sans RHN, pourquoi payer le satellite, surtout que celui-ci rajoute une couche de complexité sans grande valeur ajoutée.
Sous Solaris, si tu n'es pas à jour au niveau des patchs, tu ne peux pas avoir un bon support.
Ceci n'est pas un scoop, et c'est valable pour tous les OS, pas juste pour solaris.
Maintenant je vais peut-être t'apprendre quelque-chose, mais en général dans une grande entreprise, on ne peut pas appliquer les patches sans passer par un processus de validation avec une escalade d'environnement de test à environnement de production (et parfois de niombreux environnements de validation entre les deux) histoire de ne pas faire courir un risque idiot aux systèmes de production.
Quoiqu'il en soit, ce n'est pas à RedHat d'imposer les méthodes de gestion ou les outils: une entreprise n'est pas l'autre et un besoin n'est pas l'autre. Que des clients de RedHat achètent le proxy ou le satellite parcequ'ils voient une valeur ajoutée dans le produit, c'est normal.
Que des clients de RedHat doivent acheter le Satellite ou le proxy parceque RadHat l'impose en rendant presque impossible le téléchargement des mises à jour dans le but de faire un miroir sois-même, c'est anormal.
Même Microsoft laisse un libre accès à ses mises à jour sécurité (il suffit de quelques wget et grep pour tout récupérer).
On ne peut pas non plus comparer une offre communautaire et gratuite à une offre clairement commerciale et payante
Ben on peut sinon comparer à SuSE, qui offre tout de même une flexibilité proche des debian et autres pour la récupération des mises à jour pour se faire un dépôt sur le lan.
Je pense que ta contrainte est ailleurs (comme aucun accès direct à Internet ?).
La contrainte est de pouvoir récupérer les fichiers simplement et de pouvoir les organiser comme on veut. Il est dommage que RedHat refuse cela à ses clients et essaye de leur fourguer un produit.
Des scripts et une intégration aux outils standards de l'entreprise...
Et as-tu étudié l'offre Satellite de RHN ?
Oui, et dans l'ensemble, elle est sans intérêt par rapport à nos besoins, spécialement vu le prix.
Si tu n'enregistres pas toutes tes machines, comment comptes-tu réaliser (si tu les réalises) les mises à jour ?
Dépôts yum, jobs de mise à jour en dehors des heures de production, et promotion des packages dans les canaux en fonction des environnements... rien de bien compliqué. Le seul truc un peu compliqué est la récupération des paquets pour créer les dépôts, vu que RedHat complique les choses pour pousser à l'achat de son satellite.
Non, debian a ses mises à jour facilement accessibles, faire un miroir est aisé et gratuit, alors que RedHat complique volontairement cette tâche afin de vendre des produits pour que l'utilisateur puisse l'accomplir (mais seulement de la façon dont RedHat a décidé qu'il peut l'accomplir)
En même temps, quand je vois le nombre de clients qui demandent du RedHat et ne veulent pas toujours enregistrer leurs machines sur le RHN, ça complique drôlement les mises à jour.
Enregistrer les machines sur RHN n'est pas forcément faisable avec les politiques de sécurité réseau en vigueur dans certaines entreprises ou certains vlans. De plus RHN est une plate-forme de gestion, et dans certaines entreprises on a pas forcément envie de voir des machines du lan interne communiquer avec un portail sur internet capable de donner des ordres.
Pourquoi ne pas acheter un proxy ?
Parceque ça n'a aucun intéret face aux besoins.
Quand il faut gérer des environnements différents avec des freeze des mises à jour et des mécanismes de workflow pour les validations et approbations, ainsi que des chaînes de prototypage qui réinstallent l'OS plusieurs fois far jour sur des machines de validation, ce proxy ne sert à rien, et l'interface rhn non-plus d'ailleurs.
Pourquoi RedHat ne fournit-il pas une possibilité d'aller chercher les mises à jour directement via rsync, ... (le tout authentifié par le userid et mot de passe et ne donnant accès qu'aux canaux pour lesquels on a une licence valide) ? C'est si difficile d'offrir la même flexibilité dans l'obtention des mise à jour que Fedora, Debian, voir même Microsoft?
[^] # Re: Aaahhh...
Posté par ragoutoutou . En réponse à la dépêche Publication de la licence « GNU Affero General Public Licence Version 3 ». Évalué à 1.
Effectivement, ce que j'ai dit n'est valide que pour une utilisation publique... toutefois, force est de constater que dans ce cas, il y a unbe altération des droits d'utilisation.
Trolltech et Mysql jouent sur les limitations de redistribution, l'Agpl met des limitations sur l'utilisation et l'adaptation aux besoins, ouvrant un nouveau marché pour les doubles licences... au final on crée avec l'AGPL une sorte de sous-logiciel libre créant un monopole en faveur des propriétaires du code quand à toute adaptation en vue d'une intégration avec des technologies non agpl/gpl3 (ce qui est fréquent en entreprise).
Pas celle là en tout cas... ce n'est pas parcequ'on n'a pas la bonne réponse à un problème qu'il faut systématiquement en prendre une mauvaise pour donner l'impression qu'on veille au grain (en général on voit plutôt cette attitude chez des politiciens populistes comme Sarkozy)
Grosso modo je serais d'accord, mais le problème est que selon moi, l'AGPL est un mouvement pour inciter les entreprises de développement à passer leurs projets sous une licence vaguement libre mais leur garantissant une non-concurrence sur les adaptations critiques et l'intégration en entreprise. Une limitation sur les libertés d'utilisation et d'adaptation aux besoins est une grave atteinte au modèle libre.
Mon conseil en tout cas à l'attention de tout développeur amené à modifier un logiciel sous AGPL: ne JAMAIS rétrocéder les droits sur les modifications aux auteurs originaux de l'application. Puisqu'on force la main aux utilisateurs pour en faire des contributeurs, il ne faut pas hésiter à empêcher les propriétaires de l'application à faire de la licence proprio sur le dos des contributeurs.
[^] # Re: Aaahhh...
Posté par ragoutoutou . En réponse à la dépêche Publication de la licence « GNU Affero General Public Licence Version 3 ». Évalué à 0.
Absolument. Un logiciel libre sous GPL permet de modifier une applications, de l'adapter à mes besoins et de l'utiliser comme bon me semble sans la moindre restriction. C'est la redistribution de l'application qui est soumise à contrainte afin de ne pas me permettre d'endommager les libertés.
Avec l'AGPL, l'utilisation est soumise à contrainte, et la modification de l'application pour l'adapter à mes besoins est également entravée par les modalités de distribution. Si par exemple, je veux intégrer, dans une application AGPL, un framework de sécurité en GPL2 dont je ne suis pas le propriétaire (et que je ne peux donc pas relicencier en GPL3 ou AGPL), je n'ai pas le droit d'utiliser le résultat sur un serveur public car je ne peux satisfaire aux conditions de redistribution, redistribution qui m'est imposée en cas d'utilisation sur un serveur public.
Le A d'AGPL prédate la prise en charge de cette licence par la FSF, en outre des licences similaires existent déjà depuis un bout de temps et font les choux gras d'entreprises vendant du logiciel proprio.
[^] # Re: not a comment
Posté par ragoutoutou . En réponse à la dépêche Publication de la licence « GNU Affero General Public Licence Version 3 ». Évalué à 1.
[^] # Re: Bonne nouvelle
Posté par ragoutoutou . En réponse à la dépêche Publication de la licence « GNU Affero General Public Licence Version 3 ». Évalué à 0.
Et oui, on passe d'une logique de liberté à une logique d'imposition.
En fait, avec l'AGPL, on en arrivé à un modèle "code source comme rétribution"... on est plus très loin d'une logique de shareware.
[^] # Re: Utile
Posté par ragoutoutou . En réponse à la dépêche Publication de la licence « GNU Affero General Public Licence Version 3 ». Évalué à 3.
On peut parfaitement utiliser une librairie GPL dans un logiciel proprio, il suffit de ne pas les distribuer (ni l'un ni l'autre).
Il faut bien faire la distinction entre distribuer et utiliser.
[^] # Re: Mise en oeuvre
Posté par ragoutoutou . En réponse à la dépêche Publication de la licence « GNU Affero General Public Licence Version 3 ». Évalué à 2.
Dans le cas donc d'un site web, tu peux te retrouver dans la situation où tu as le droit de modifier et d'adapter à tes besoins, mais pas d'utiliser, ou alors d'utiliser mais pas d'adapter à tes besoins.
[^] # Re: Aaahhh...
Posté par ragoutoutou . En réponse à la dépêche Publication de la licence « GNU Affero General Public Licence Version 3 ». Évalué à 7.
- dans l'AGPL on nie l'existence de l'utilisateur côté serveur: on en fait systématiquement un distributeur, ce qui change sérieusement la donne au niveau des libertés: on met des contraintes sur les libertés d'utilisation et de modification: plus moyen pour une entreprise de faire cohabiter des composants proprio (sur lesquels elle n'a pas les droits) avec du libre dans l'exercice de son activité si celle-ci implique une utilisation sur internet. En outre, la contrainte de redistribution crée une problématique supplémentaire dans la gestion des releases sur les systèmes de production et nuit gravement à l'agilité de la solution., voir à la sécurité.
- l'AGPL n'est pas une licence innocente, elle est poussée par des développeurs d'applications commerciales en tant que licence d'essai shareware pour pouvoir vendre ensuite des produits intégrables et proprio p.ex: funambol qui sous prétexte de préoccupations libristes s'est créé un monopole sur son application grâce à l'HPL.
Au final, l'AGPL est une MAUVAISE réponse à un problème réel, une sorte de Patriot Act qui sous prétexte de protéger les libertés des utilisateurs "navigateur" met à mal les libertés des utilisateurs "serveur".
Si le libre avait besoin d'un frein à son adoption dans le monde de l'entreprise, il en a trouvé un. D'un point de vue "utilisateur serveur", l'AGPL n'est pas une licence libre, juste une licence proprio un peu permissive.
[^] # Re: Utile
Posté par ragoutoutou . En réponse à la dépêche Publication de la licence « GNU Affero General Public Licence Version 3 ». Évalué à 10.
Pratiquement, cette licence va faire en sorte que les projet seront renforcés, par la contrainte, dans un cadre communautaire en forçant la redistribution de l'application modifiée dès que celle-ci est utilisée publiquement.
Pour le monde de l'entreprise, par contre, cette licence peut être vue comme une annulation des libertés consacrant la double licence AGPL+Proprio afin de permettre aux entreprises de modifier le logiciel et de l'adapter aux besoins si un des besoins concerne l'utilisation publique. En pratique donc, cette licence rend le pouvoir aux développeurs initiaux d'une application web au détriment de l'utilisateur côté serveur.
# Aaahhh...
Posté par ragoutoutou . En réponse à la dépêche Publication de la licence « GNU Affero General Public Licence Version 3 ». Évalué à 6.
Un conseil pour les sociétés de service et les entreprises: n'utilisez surtout pas de logiciels AGPL avant d'avoir un avis légal sur cette licence et d'en avoir bien compris les implications, à fortiori pour un portail ou un service sur internet: "adapter l'application à ses besoins" devient une opération beaucoup plus contraignante qu'avec une licence libre comme la GPL3.
[^] # Re: Et Maemo
Posté par ragoutoutou . En réponse au journal android, openmoko, vendredi .... Évalué à 4.
# interface d'administration...
Posté par ragoutoutou . En réponse au message Réseau local accessible depuis l'extérieur. Évalué à 4.
Si j'étais toi, je fearais très attention à ce point... c'est un risque de sécurité énorme et il faudrait désactiver l'accès à l'interface de gestion depuis l'extérieur en priorité absolue.
Sinon, OpenVPN, c'est pas mal, mais effectivement, comme mis plus haut un simple forwarding du port ssh peut suffir (et ssh permet de faire du port forwarding pour atteindre les autres ports, sur demande)
[^] # Re: Pas extraordinaire
Posté par ragoutoutou . En réponse au journal Theora, the push for the 1.0 update. Évalué à 10.
Seulement si on croit en la force des brevets sur le logiciel... ou qu'on implémente une solution matérielle.
# Repackager...
Posté par ragoutoutou . En réponse au message intégrer une librairie directement dans un executable. Évalué à 2.
[^] # Re: OOXML, indépendant de la plate-forme... en lecture
Posté par ragoutoutou . En réponse au journal La pseudo fondation opendocument est dissoute!. Évalué à 8.
L'argument n°1 de OOXML est que c'est le format "supporté" par office, en l'absence de ce support office, l'OOXML est un gros "standard" inélégant de 6000 pages, non ISO (contrairement à son concurrent direct), et bourré de legacy office, bref sans grand intérêt.
[^] # Re: OOXML, indépendant de la plate-forme... en lecture
Posté par ragoutoutou . En réponse au journal La pseudo fondation opendocument est dissoute!. Évalué à 3.
Il suffit que la méthode de lecture soit triviale mais que celle d'écriture nécessite une connaissance particulière.
Tu peux facilement générer des documents OOXML qui, tout en étant conformes à la norme, ne seront pas lus par Office vu que celui-ci n'est pas conforme à cette norme et a des exigences différentes pour déclarer un document valide.
[^] # Re: Ah, toujours ces problèmes...
Posté par ragoutoutou . En réponse au message Recuperer tous les updates security. Évalué à 2.
Bon, faut pas tout mélanger, je ne critique pas la politique de mise à jour de RedHat mais bel et bien sa politique commerciale.
Le fait est que chaque fournisseur peut avoir son outil de mise à jour, adapté ou non aux besoins. Je peux parfaitement comprendre qu'une entreprise n'est pas l'autre et qu'une seule taille ne peut aller à tout le monde. Maintenant ce que je reproches c'est cette attitude qui vise à pousser le client vers cet outil de mise à jour, adapté ou pas, bloquant les méthodes plus traditionnelles, pourtant plus simples à adapter aux besoins, apparemment dans le but de maximiser leurs ventes.
Si encore RedHat offrait gratuitement le satellite pour tout achat de 100 licences, je dirais pas, mais là, c'est juste du forçage de main.
La politique est certes de passer par windows update, mais elle aisément contournable si on lis la doc technet. Et les outils de patch management tels que SUS sont gratuits (si tu es en règle au niveau licence OS), contrairement au proxy et au satellite.
[^] # Re: in other news...
Posté par ragoutoutou . En réponse au journal Google Android. Évalué à 2.
cfr www.maemo.org
[^] # Re: Support de MS office...
Posté par ragoutoutou . En réponse au journal La pseudo fondation opendocument est dissoute!. Évalué à 5.
Oui, mais si un document CDF nécessite ou contient un activex pour lire des blobs binaires non documentés qui sont passés en paramètres par le document CDF, ça pose tout de même problème.
# Support de MS office...
Posté par ragoutoutou . En réponse au journal La pseudo fondation opendocument est dissoute!. Évalué à 3.
Via ActiveX il me semble... une élégance folle.
[^] # Re: Ah, toujours ces problèmes...
Posté par ragoutoutou . En réponse au message Recuperer tous les updates security. Évalué à 2.
Bien sûr que non... on dirait que tu n'as pas lu tout ce que j'ai mis avant.
Un attaquant ne pourrait sans-doutes pas compromettre les paquets des dépôts, gâce au mécanisme de contrôle de signature. Par contre il pourrait envoyer des ordres dans la limite des fonctionnalités du client rhn.
RedHat Enterprise Linux est en sois un excellent produit, à un détail près: une politique de gestion des patchs pas très respectueuse des besoins de ses clients.
En outre, RedHat bénéficie d'un quasi-monopole dans le cadre du support de nombreuses applications tierces, ce qui le rend très difficile à remplacer.
Il n'y a pas de distribution parfaite à l'heure actuelle, et changer de distribution, en admettant qu'il existe une distribution avec autant de certifications tierces, n'améliorerait pas forcément le tableau.
Donc je compte continuer à utiliser encore longtemps RHEL (car c'est un bon produit) ET critiquer la politique d'accès aux patchs (car c'est une mauvaise politique).
Et franchement, ton attitude de "tout ce qui n'est pas fait dans le cadre de RHN est mauvais, les gens sont idiots de vouloir s'en passer quelques soient les besoins" n'est absolument pas à ton honneur. Je ne sais pas si tu bosses pour redhat (ce qui expliquerait cette défense agressive de la valeur du proxy et du satellite), mais si c'est le cas, franchement vous gagneriez à écouter un peu plus vos clients et leurs besoins.
[^] # Re: Ah, toujours ces problèmes...
Posté par ragoutoutou . En réponse au message Recuperer tous les updates security. Évalué à 2.
Pour ma part, j'ai déjà utilisé RHN en long et en large, en passant par les fonctions d'installation, de gestion de config et tout et tout.
Si c'est avec RHN, c'est clairement un serveur sous le contrôle de redhat qui donne l'ordre, même si cet ordre est demandé par l'utilisateur. Le fait d'inféoder des machines d'un réseau d'entreprise à un serveur web sur internet est un risque de sécurité non négligeable: que se passerait-il par exemple si le serveur RHN se fait hacker et commence à envoyer des ordres malveillants?
Éventuellement, si la politique réseau le permet (p-ex, le serveur a accès à un proxy), on peut envisager de faire enregistrer les machines sur rhn au moment de l'installation et de couper le lien immédiatement après et à jamais, mais ça nécessite après d'aller gérer les licences à la main dans rhn, ce qui diminue le degré d'automatisation de la tâche).
Ensuite, ce lien entre les serveurs du lan et un serveur sur internet situé aux usa peut interdit dans certains pays comme par exemple le Luxembourg où les règles de confidentialité sont très strictes quand au risque d'avoir des données consultées depuis des personnes non autorisées, à fortiori depuis l'étranger.
Bon, maintenant, il y a le satellite qui adresse peut-être ce problème, mais quand on peut faire sans RHN, pourquoi payer le satellite, surtout que celui-ci rajoute une couche de complexité sans grande valeur ajoutée.
Ceci n'est pas un scoop, et c'est valable pour tous les OS, pas juste pour solaris.
Maintenant je vais peut-être t'apprendre quelque-chose, mais en général dans une grande entreprise, on ne peut pas appliquer les patches sans passer par un processus de validation avec une escalade d'environnement de test à environnement de production (et parfois de niombreux environnements de validation entre les deux) histoire de ne pas faire courir un risque idiot aux systèmes de production.
Quoiqu'il en soit, ce n'est pas à RedHat d'imposer les méthodes de gestion ou les outils: une entreprise n'est pas l'autre et un besoin n'est pas l'autre. Que des clients de RedHat achètent le proxy ou le satellite parcequ'ils voient une valeur ajoutée dans le produit, c'est normal.
Que des clients de RedHat doivent acheter le Satellite ou le proxy parceque RadHat l'impose en rendant presque impossible le téléchargement des mises à jour dans le but de faire un miroir sois-même, c'est anormal.
Même Microsoft laisse un libre accès à ses mises à jour sécurité (il suffit de quelques wget et grep pour tout récupérer).
[^] # Re: Sans parler de la debian
Posté par ragoutoutou . En réponse au message Recuperer tous les updates security. Évalué à 2.
Ben on peut sinon comparer à SuSE, qui offre tout de même une flexibilité proche des debian et autres pour la récupération des mises à jour pour se faire un dépôt sur le lan.
La contrainte est de pouvoir récupérer les fichiers simplement et de pouvoir les organiser comme on veut. Il est dommage que RedHat refuse cela à ses clients et essaye de leur fourguer un produit.
[^] # Re: Ah, toujours ces problèmes...
Posté par ragoutoutou . En réponse au message Recuperer tous les updates security. Évalué à 2.
Des scripts et une intégration aux outils standards de l'entreprise...
Oui, et dans l'ensemble, elle est sans intérêt par rapport à nos besoins, spécialement vu le prix.
Dépôts yum, jobs de mise à jour en dehors des heures de production, et promotion des packages dans les canaux en fonction des environnements... rien de bien compliqué. Le seul truc un peu compliqué est la récupération des paquets pour créer les dépôts, vu que RedHat complique les choses pour pousser à l'achat de son satellite.
[^] # Re: Sans parler de la debian
Posté par ragoutoutou . En réponse au message Recuperer tous les updates security. Évalué à 2.
[^] # Re: Ah, toujours ces problèmes...
Posté par ragoutoutou . En réponse au message Recuperer tous les updates security. Évalué à 3.
Enregistrer les machines sur RHN n'est pas forcément faisable avec les politiques de sécurité réseau en vigueur dans certaines entreprises ou certains vlans. De plus RHN est une plate-forme de gestion, et dans certaines entreprises on a pas forcément envie de voir des machines du lan interne communiquer avec un portail sur internet capable de donner des ordres.
Parceque ça n'a aucun intéret face aux besoins.
Quand il faut gérer des environnements différents avec des freeze des mises à jour et des mécanismes de workflow pour les validations et approbations, ainsi que des chaînes de prototypage qui réinstallent l'OS plusieurs fois far jour sur des machines de validation, ce proxy ne sert à rien, et l'interface rhn non-plus d'ailleurs.
Pourquoi RedHat ne fournit-il pas une possibilité d'aller chercher les mises à jour directement via rsync, ... (le tout authentifié par le userid et mot de passe et ne donnant accès qu'aux canaux pour lesquels on a une licence valide) ? C'est si difficile d'offrir la même flexibilité dans l'obtention des mise à jour que Fedora, Debian, voir même Microsoft?