ragoutoutou a écrit 1515 commentaires

Cela dit, côté base de données, c'est pas forcément mieux, sauf que pour accéder au blob, il faut obligatoirement passer par une requete sql, donc par une requete au serveur www via CGI ou script

si un hacker arrive à contourner la sécurité apache pour récupérer des fichiers protégés correctement par un .htaccess ou placés hors de la racine du serveur web, je ne vois pas pourquoi il n'arriverait pas à récupérer tes requêtes...

et dans le cas ou tu veux gérer des droits d'accesa ax photos ?

tu peux parfaitement avoir tes photos dans un répertoire non accessible directement et avoir un script ou cgi les envoyant au client quand nécessaire, après vérification des droits, de la même manière que tu aurais fait ça en les stockant dans des blobs, mais en plus simple.

Un autre argument en faveur du stockage en base, c'est les sauvegardes : tu sauves juste ta base de données, et en cas de crash, ça remarche rapidement. Pas besoin de préciser à l'admin qu'il faut penser à sauvegarder tel répertoire en plus pour telle appli. Bref, en exploitation, c'est plus simple.

mwais... tu présentes donc l'utilisation de la SGBD comme solution pour pallier à un éventuel problème de coordination avec l'administrateur... pas génial... En plus, faudra tout de même le prévenir de l'explosion de taille de ta base de données (ou alors tu vas te chopper des problèmes de quotas)... De toutes façons, si tu ne fait pas confiance à l'admin pour faire des backups de fichiers, tu devrais faire encore moins confiance pour les DB, a fortiori avec des blobs...

Pour accéder à tes images, tu dois impérativement les réextraire de la DB, alors que si elles sont stockées sur le disque sous forme de fichiers, tu peux directement les ouvrir avec n'importe quelle application.

Les images dans un SGBD, c'est rajouter une couche de complexité pour pas grand-chose.

Par contre, indexer les images dans un sgbd, ça, ça a un sens (tu ne mets pas les images dans la db, juste les méta données, genre headers exif si ce sont des photos).

Pour paraphraser Bruxelles, tout ça viole la "concurrence libre et non faussée" entre les projets libres d'interopérabilité avec M$.

Cela fausserait la concurrence si il y avait des accords d'exclusivité, genre seul samba peut acquérir les docs... mais ce n'est heureusement pas le cas: Microsoft ne peut plus que prendre le blé, la signature de NDA et fermer sa gueule pour un de ses secrets et leviers de monopole les mieux gardés.

Si d'autres OS Libres (*BSD, AROS, Haiku, ...) veulent coder leur client CIFS Libre (pour le VFS) ils doivent lire les sources de samba

Ils peuvent aussi payer Microsoft pour avoir la doc, s'ils en on tant besoin, ou pomper dans les différentes docs officieuses sur les protocoles concernés, surtout que ces dernières vont être mises à jour sur base des changements de Samba.

Je ne vois pas en quoi ces projets sont pénalisés. Ils ne payent pas et ils récupéreront quand-même l'information via les mécanismes de transfert de connaissance du logiciel libre. A part si tu considères que les mécanismes du logiciel libre sont inefficaces, tu devrais plutôt te réjouir de l'injection de cette connaissance nouvelle dans l'écosystème.

Certes, je trouves que ceux qui se plaignent ici du NDA vont un peu vite en besogne, je ne suis pas non-plus un grand fan de Samba, mono, et autres contorsions de la communauté libre pour essayer d'être compatibles avec Microsoft (c'est une course en avant dans laquelle ce dernier gagne toujours), mais ça ne me fait pas "marrer"...

"Quand au fait que les linuxiens feraient mieux de regarder comment marche leur système", ça relève malheureusement du troll bas de plafond, con, mesquin et gratuit.

Si tu n'aimes pas les NDA, n'utilise pas Samba (il n'y a rien qui t'y oblige, après tout)

à ce prix là c'est du racket, pas un accord.

Ce prix est certes élevé pour un étudiant, mais pour une entreprise, c'est des cacahouètes. C'est certes moins sympa que d'avoir la doc publiée ubi et orbi par Microsoft, mais c'est tout de même une avancée phénoménale.

De toutes façons, ceux qui ne sont pas d'accord n'ont qu'à ne pas utiliser samba et boycotter Windows.

Pour faire court, il n'est interdit à personne, en dehors des développeurs impliqués dans l'accord avec MS, de réécrire une doc sur base des sources de Samba.

De même, il est certain que seul un nombre réduit de développeurs à accès au document et que cet accès ne sera étendu qu'aux personnes membres du projet et dignes de confiance pour éviter une diffusion sur internet (ce qui déclencherait un assaut armé et immédiat de la part de Microsoft).

La bécane semble être un ancêtre, est-ce que les ventilateurs et radiateurs ont été dépoussiérés récemment? C'est un classique dans la surchauffe des portables.

Donc selon toi, quand les mêmes personnes font exactement la même chose au détail près qu'ils ne publient même pas leur modifications (integration, backport, whatever), c'est mieux ?

Je dis juste, qu'en forçant la redistribution des forks "privés", on va peut-être récupérer des choses intéressantes, mais on va singulièrement détériorer le rapport signal/bruit.

Pour ma part, je ne suis pas absolument contre l'idée de forcer à un moment donné la redistribution du code, mais à forcer la redistribution de tout et n'importe quoi, on va se retrouver avec tout et n'importe quoi.

Si le client n'a pas un peu d'esprit critique, il se retrouve face à n'importe quel genre de vendeur et se fait refiler n'importe quoi, et au final les mauvais professionnels font leur beurre au détriment de ceux qui ont une approche honnête et qui n'arrivent plus à nouer les deux bouts.

Dans le monde de la presse, il n'y a qu'à voir les ventes de la presse à scandale ...
Tant que les gens auront de la merde entre les oreilles et blâmeront le marché, la presse, le coût de la vie et le chien du voisin pour leur propre médiocrité intellectuelle, on ne risque pas de faire progresser les choses. Chacun est responsable de sa propre médiocrité, citoyen comme professionnel.

En général, il y a une personne à qui ça ne fait pas plaisir: ton banquier.

Par contre, en général les huissiers sont ravis...

Et les clients étant paresseux, n'incitent-ils pas les vendeurs à prendre la voie de la facilité et du moindre effort?

C'est l'œuf et la poule, blâmer l'un sans blâmer l'autre est un nonsens.

l'utilisateur va continuer à le modifier à chaque fois mais va en plus rendre accessible à qui veut ses modifications

Ou il va camper sur sa version en ne backportant que les éléments qu'il juge important en provenance des nouvelles versions...

A la longue il va s'éloigner de l'original et ses modifs seront de moins en moins faciles à intégrer dans la version "officielle"

tu veux dire que ça va obliger à travailler plus proprement et soumettre ses changements upstream au préalable pour bénéficier de nouvelles fonctionnalités sympathiques, qui bénéficieront ainsi à tout le monde ?

Drôle mais peu réaliste...

Dans la majorité des cas, les utilisateurs contraints de devenir distributeurs vont le faire en se foutant de la qualité de ce qu'ils redistribuent. L'AGPL va forcer la redistribution, pas la qualité, pas la méthodologie.

Et si en upstream une modif n'est pas intégrée, ça fera effectivement et irrémédiablement un fork (parce que l'utilisateur en bas qui a besoin d'une fonction/modif, même légère, ne va pas attendre qu'on réagisse en haut)

Le libre, ce n'est pas modifier une application, renvoyer ses modifs et attendre la bénédiction de l'auteur et l'intégration dans le code "canonique" pour les utiliser.

Qu'est-ce que l'AGPL change par rapport à la GPL pour les forks?

vu que l'AGPL oblige à publier ses modifications (dans le cas ô combien rarissime où on les utilise sur internet), ça va dans les faits pousser chaque utilisateur ayant fait une modif à mettre à disposition sa propre cuvée... rapidement, on va se retrouver avec des dizaines de versions pas tout à fait équivalentes de chaque application AGPL, avec des écarts de version par rapport au code de base, des changements rendant incompatibles, ...

le risque est de se retrouver avec une jungle maintenue à bout de bras par des gens pas forcément motivés.

Si tu l'utilises sur l'intranet de l'entreprise, tu dois fournir le code source aux employés de l'entreprise qui utilisent ton soft.

Ben ça aussi c'est une affirmation avec des relents de fud Microsoft... Si tu utilises une application AGPL dans ton entreprise et que les employés y accèdent dans le cadre de leur activité professionnelle, c'est une seule et même personne morale qui utilise l'application, et il est peu probable que l'obligation de redistribuer soit applicable dans ce cas.

L'esprit de l'AGPL est une caricature de l'esprit de la licence GPL, une forme exagérée ou on renforce les devoirs et où on réduit les droits de la personne ayant fait le choix d'utiliser l'application au profit de celle ayant décidé d'utiliser le service offert par la première...

L'effet de bord amusant sera la multiplication des forks.

Mais je vois pas le rapport.

Non, mais c'est pas grave... c'est vrai qu'entre maintenir son fork en interne et devoir en plus le publier (ce qui est un cas fréquent avec l'AGPL), il n'y a pas des masses de différences...

Car si tout le monde doit maintenir un fork pour chaque petite modification, ça va pas aller.

Tu vas adorer l'AGPL toi :)

Il lui suffit d'y créer un nouveau compte en IMAP

Tout le monde n'a pas accès à un compte imap ou les compétences pour faire un serveur imap local pour faire l'opération... Et si on peut faire la conversion localement, sans avoir besoin d'une infrastructure serveur et réseau, c'est tout de même plus efficace.

Une conversion de fichier à fichier reste préférable, surtout quand tu n'as plus outlook mais que tu as encore des vieux pst dont tu voudrais récupérer les contenus.

Et aussi, comment ca se programme? Faut-il adapter les programmes pour utiliser le parallelisme (avec MPI par exemple?)

ça se programme comme du multithread classique, c'est tout l'intérêt de ce type de technologie. Si ça utilisait du MPI, ce serait juste du beowulf.

L'utilisation telle quelle, "out of the box" (modulo la configuration" n'a aucune barrière.

Il y a beaucoup de licences open-source non-libres qui permettent ça...

Certes, c'est simplement dû à une incompatibilité des deux licences. Mais la faute n'est pas plus sur l'AGPL que sur la GPL.

La GPL n'empêche pas d'utiliser ces deux éléments conjointement tant qu'il n'y a pas redistribution.

L'AGPL force cette distribution et crée le contexte où l'utilisateur perd son droit d'utilisation.

Les libertés sont les même, les conditions sont différente. ça a des implications sur les libertés, oui, mais faible.

Les libertés ne sont pas les mêmes puisqu'il y a un "mais" avec des conditions sur l'usage et la modification.

C'est la différence entre "tu es libre" et "tu es libre d'aller où tu veux dans un rayon de 300m autour de ton domicile".

Intégrer du code d'une application dans une autre, on fait pas ça tous les jours quand même. Quand on modifie un programme en général c'est par l'écriture de son propre code.

C'est naïf, comme vision des choses... particulièrement dans le cas de la programmation web.

Analyse intéressante,

Je vais tout de même un peu relativiser...

- GPL : L'utilisateur n'a plus pleine liberté d'utilisation (exemple : lib en GPL ne peut être utilisé dans un programme non GPL), mais les autres gagnent d'autres libertés (effet parfois appelé "contaminant") ;

Il y a vraiment deux cas: l'utilisation et la transmission.

Du point de vue de la GPL, l'utilisateur peut utiliser une lib en gpl dans un programme non-gpl ou une lib non-gpl dans un programme GPL, ou faire n'importe quel mix infâme des deux, tant qu'il ne cherche pas à distribuer le programme résultant. La "contamination" (je n'aime pas trop ce terme vu sa connotation négative), n'existe qu'en cas de redistribution, pas en cas d'utilisation.

Microsoft et quelques autres ont beaucoup bossé à une époque pour semer le FUD auprès des entreprises, prétendant que le simple fait d'utiliser du GPL entrainait ladite contamination, ce fud n'a pas été facile à combattre et a pas mal freiné la pénétration du libre en entreprise.

Maintenant, l'AGPL de son côté place cette fameuse "contamination" au niveau de l'utilisation (applicable en cas d'accessibilité au public uniquement, mais c'est le cas d'usage le plus fréquent) c'est une nouveauté, et ça rejoint malheureusement la situation décrite jadis dans le FUD de Microsoft & friends.

Il reste un dernier axe à considérer dans l'histoire AGPL, et je pense que c'est de là que viendra avant tout son succès: le pouvoir renforcé de l'auteur/propriétaire de l'application:

- ISC: l'auteur/propriétaire est mentionné dans tout produit dérivé de son application. En dehors de ça, l'auteur n'a aucun pouvoir.

- LGPL: l'auteur/propriétaire a l'exclusivité sur le changement de licence, la LGPL permet d'intégrer le code libre sous forme de librairie dans une application fermée, à condition de garder la librairie libre.

- GPL: l'auteur/propriétaire a l'exclusivité sur le changement de licence, ce qui lui permet de faire un système de double licence et ainsi de pouvoir prétendre à rémunération en cas d'accord sur la distribution du logiciel dans une solution commerciale fermée.

- AGPL: l'auteur/propriétaire a l'exclusivité sur le changement de licence. En plus des droits émanants de la GPL, la licence interdit de fait l'utilisation publique de l'application si celle-ci est intégrée avec du non-libre, l'auteur/propriétaire se retrouve en position de point de passage obligé pour toute intégration en entreprise nécessitant un usage conjoint de son code et d'une technologie non [A]GPL3. L'AGPL est donc un moyen supérieur à la GPL dans la recherche de rémunération pour l'auteur de logiciel qui sera plus souvent contacté par les entreprises désireuses d'utiliser le logiciel.