On est d'accord.
Sauf que :
- on ne donne jamais "à chaque victime", mais uniquement à celles qui sont partie civile (grosso modo : qui ont parté plainte).
- quelqu'un qui porte plainte et qui obtient gain de cause et par principe la "victime" de l'affaire
- dans notre cas les seules victimes sont les auteurs du logiciel, pas les utilisateurs en manque de code source
A priori il n'y a qu'un seul plaignant, c'est l'unique auteur que la justice va considérer pour les dommages et intérêts, donc je maintiens, c'est lui qui récupèreras les sous de dommages et intérêts.
Effectivement par contre, dans le cas d'une amende ça ne va pas aux plaignants/victimes mais on parle bien d'une plainte civile là, donc à priori il y aura dommages et intérets
Pour le 1 je ne vois pas en quoi faire tourner une passerelle en local serait impossible ou même difficile. C'est à priori d'un niveau de difficulté équivalent à ce que font pidgin ou telepathy.
Pour le 3 c'est une question de dénominateur commun. Telepathy va forcément rencontrer à moyen terme des problèmes similaires. Quand on met une couche d'abstraction on a toujours le risque de perdre des détails.
Pour le 2, en considérant une passerelle locale (c'est à dire le même niveau d'abstraction/architecture que telepathy), je ne vois pas où est la difficulté en plus par rapport à ce que ferait telepathy.
> Tu oublies juste qu'il y a déjà un existant qui s'appelle d-bus pour faire
> ce genre de "messagerie" entre applis locales et qu'il serait
> dommage de ne pas en profiter ou de réinventer la roue.
Certes, mais entre utiliser un socket tcp/ip là où on pourrait utiliser dbus (ce que j'imaginais) et avoir à réimplémenter entièrement un protocole pour la gestion de la présence, pour les messages instantannés, pour la gestion des comptes, pour la gestion des contacts (ce qui a été fait ou qui est fait dans telepathy si j'ai bien compris) ...
J'ai l'impression que la seconde option est bien plus proche du "réinventer la roue" que la première. Maintenant il est possible/probable qu'il y ait quelque chose que je n'ai pas vu qui inverse la balance.
L'indépendance de licence et de langage elle existe justement déjà (et bien mieux) dans le principe d'échange xmpp.
Le partage des connexions n'y est pas, il est vrai, mais xmpp permettant de gérer plusieurs connexions sur le même compte, je ne sais pas si c'est vraiment indispensable de partager la connexion (surtout si on peut mettre un proxy xmpp au milieu pour ne pas surcharger le serveur distant).
Le cloisonnement, si je ne me trompe pas les passerelle jabber sont déjà indépendantes de ce côté là.
Mais qu'on soit d'accord, je ne dis pas que XMPP est la solution à tout où que Empathy a son rôle à jouer. C'est juste que je ne vois pas dans la news, dans le site ou dans ta réponse la fonctionnalité clé que couvre Empathy et que ne couvrait pas déjà XMPP à la base.
Mieux que ça même, je ne remettais pas en cause le bénéfice d'empathy, je demandais juste qu'on me le mette en lumière.
> Il est plus simple de faire un "for m in client.message_queue:" que de
> devoir reparser le XML à la main.
Je le conçois, mais dans ce cas la solution peut être une libxmpp ou une libjabber, pas forcément un serveur complet avec son propre protocole.
> En plus, il n'est pas évident qu'un "proxy XMPP" soit la solution
> multi-usage, ceux qui utilisent les passerelles Jabber savent qu'il
> n'est pas évident que le plus petit dénominateur commun convienne à
> tout le monde...
Empathy n'a pas l'air de changer quoi que ce soit à cette problématique. Il y a une méthode d'accès par fonctionnalité si j'ai bien compris. Donc on parle toujours d'avoir un dénominateur commun unique.
J'ai un peu de mal. Si je comprend bien ce que je lis Empathy et MC permettent d'avoir une abstraction pour envoyer des messages, les recevoir, les gérer, voir les présences, gérer les contacts, etc. Les logiciels vont pouvoir s'interfacer sur cette couche pour dialoguer au lieu de tout gérer eux même.
Ca c'est bien, mais ça ne fait pas déjà un double emploi avec ? XMPP est pour moi déjà un protocole standardisé qui gère tout ça. Il aurait "suffit" de faire une sorte de proxy XMPP local qui forwarde aux différents serveurs (jabber, msn, autres). Les applications n'auront qu'à parler XMPP.
Là j'ai l'impression qu'on refait encore une couche d'abstraction sans qu'elle apporte rien de plus que XMPP. Au lieu de dialoguer en XML/XMPP les applis vont dialoguer avec des structures en C avant d'être retraduits en XML/MSN/autre. Je ne suis pas certain du gain là.
C'est plus sioux que ça. TF1, M6 et W9, refusent d'être diffusés sur une sortie informatique. Ces trois chaînes sont bien accessibles si tu branche une T derrière la prise de la freebox.
Oui, je sais, c'est crétin comme critère, mais c'est comme ça.
J'y crois peu pour le "temporaire". Ca fait des années qu'on parle du cas des tuners TV sur PC. La question de la redevance dans ce cas là était déjà discutée quand j'étais en prépa, c'est à dire il y a 8 ans.
Ce n'est pas non plus un "vide juridique". Ta formulation laisse à penser que les ordinateurs ne sont pas inclus à cause d'une formulation obsolète alors qu'on voudrait les inclure. Or là c'est bien le contraire : ils sont inclus par défaut (comme tous les appareils permettant de recevoir la télévision) et ont été exclus explicitement. C'est tout sauf un vide juridique, c'est exactement le contraire, c'est une volonté manifeste.
Enfin, le succès des box ADSL je veux bien mais pour l'essentiel les gens branchent une vrai TV derrière. Ceux qui regardent via VLC sont des geeks ou étudiants, encore très minoritaires. Ceux qui le font sans avoir une TV à côté (donc qui ne payent pas déjà la redevance) sont encore plus minoritaires.
Bref, ça ne me semble pas une piste majeur. La fraude à la redevance me parait beaucoup plus importante que cette niche réduite. D'autant que dans cette niche il y a beaucoup d'étudiants qu'on n'a pas forcément envie de mécontenter bêtement sur ça.
> Et a la différence d'ubuntu, les paquets dans contribs ont
> quand meme des maj de sécurité si je ne m'abuse. Ce qui
> n'est pas forcément le cas de multiverse . Il y a déja eu des
> cas en tout cas.
Attend, tu es bien en train de comparer avec la debian testing qui elle n'a aucune garantie d'avoir les maj sécurité tout court ? (à moins que ça ait changé la garantie des maj sécu elle est sur la stable ; la testing est celle ou les maj de sécu sont les moins suivies)
Certes, reste à voir l'utilité de "gros blocs de data" dans le cadre d'un vote. Inscrire un octet à chaque vote dans le fichier au nom du candidat choisit ça garde une atomicité très simple à garantir. Tu n'auras jamais de démi octet écrit donc l'écriture ton bloc de data sera atomique.
> Et si y'a une erreur disque pendant que tu mets à jour ton
> compteur ?
La même chose que s'il y a une erreur de disque pendant que ton SGBD transactionnel bosse ?
- c'est une erreur non détectée par le logiciel, ça merdera sur le fichier texte mais aussi sur ton SGBD
- c'est une erreur renvoyée par l'OS mais le système continue de tourner : le SGBD comme la fonction d'écriture vont te répondre que l'écriture n'a pas eu lieu, à toi d'en faire ce que tu veux
- le système crashe, au redémarrage tu peux récupérer le journal d'écriture (celui du FS dans le cas du fichier texte, et en plus celui du SGBD dans ton cas), et là dans les deux cas l'écriture du journal peut être incomplète et on perd le dernier vote, soit elle est complète et on peut la récupérer.
Reste le cas où on écrit une demi ligne dans le fichier texte avant le crash, mais il existe des solutions très simples pour palier le problème (genre un fichier par candidat, à chaque vote on écrit un octet dedans : aucun risque de demi écriture ou d'écriture incohérente, et cette dernière solution est vachement plus sécurisée pour ce cas d'utilisation que tout ce que tu pourras faire avec ton moteur transactionnel).
Bref, dans les deux cas on peut perdre le dernier vote, dans les deux cas on ne peut perdre que le dernier vote (sous réserve de faire un flush entre chaque écriture).
Oui, en même temps là la machine a voté elle peut prendre plus d'une seconde par écriture, elle n'a aucune concurrence d'accès (un seul vote simultané par machine), etc.
Bref, un fichier de texte ouvert en écriture avec un flush et un FS journalisé, *ici* ça offrira autant ou presque que ce que peut proposer un SGBD évolué.
En effet, recoder tout soit même est très rarement "mieux", mais là quand il s'agit juste de faire un compteur fixe sans concurrence d'accès et sans contraintes de performances ... utiliser une couche SQL je vois mal ce que ça peut apporter de positif.
Il n'y a pas obligation de donner le code source, juste de le proposer. On peut même facturer les frais d'envoi.
Bref, s'il y avait un papier avec une URL, la licence et une explication je pense que ça aurait été. Là il n'y avait pas de copie de la GPL (ça c'est un problème), les détails d'accès au code source n'ont été donnés qu'après coup (pas sur les premières boites, ça aussi c'est un problème) et pas sur tout le logiciel (si j'ai bien compris uniquement vers les softs d'origine sur Internet, pas leur code/config/modif).
> non, a priori, cette affaire ne donne aucune chance d'avoir accès au
> code source du logiciel Skype.
Comme aucune affaire liée à la GPL. Au pire tu fais de la contrefaçon et donc on peut te demander de payer les dommages et intérêts, mais jamais il n'y aura de "tu l'as distribué donc tu dois maintenant donner ton code source contre ton gré".
Les sous ? à celui qui a porté plainte et qui a subit une violation de ses droits d'auteurs. C'est pour lui, personnellement, pour s'acheter une plus grosse TV s'il en a envie.
Peut être que tu peux compter qu'il utilisera ses sous pour gpl-violations mais rien ne l'y oblige, ni juridiquement ni même moralement.
Par contre tous ceux qui ont des droits sur le noyeau linux peuvent faire la même chose à priori.
Disons que c'est effectivement la dérive actuelle mais le brevet normalement couvre aussi le "comment".
Le brevet, si on regarde les textes français, couvre un *procédé* technique, pas un effet. Le terme des textes est explicite, c'est la façon de faire, le procédé, qui compte. Trouver une autre procédure pour convertir le plomb en or permet effectivement normalement de passer à côté du brevet.
Par contre ça couvre un autre comment que le copyright. Le copyright couvre l'originalité de l'oeuvre. Si tu utilises la même procédure mais sans "copier", tu n'as pas de problèmes de copyright. Par contre, même avec une autre procédure, si tu réutilises les plans ou si tu as le même aspect extérieur, tu auras des problèmes de copyright
Disons que l'esprit initial c'est d'éviter que des secrets de mise en oeuvre/création se perdent. On fait donc un deal : tu révèles ton secret et en échange on te garantis que tu restes seul à pouvoir l'utiliser pendant un temps (comme si tu gardais le secret). Du coup on s'assure qu'à terme la connaissance globale de l'humanité évoluera.
Pour la note c'est d'ailleurs aussi pour ça que dans certains pays, tant que l'invention n'est pas publique, on offre le brevet au premier qui dépose (donc qui révèle au public), et pas forcément à l'inventeur de départ.
Le fait qu'on considère le brevet comme un investissement et le ROI de la R&D, le fait qu'on cherche à lui faire couvrir l'effet plutôt que la procédure, ce sont les deux dérives actuelles qui font que notre système de brevet n'a plus aucun sens et est pourri jusqu'à la moelle (et franchement les brevets logiciels n'ont rien d'isolés à ce niveau).
> Ah, et comme ça en passant, pour tous ceux qui pensent que
> poser des brevets logiciels en Europe c'est impossible, je leur ai
> demandé et ils m'ont affirmé que la semaine passée ils ont fait
> valider un brevet sur la gestion d'objets dans un système
> d'exploitation à l'office des brevets de Londres. Juste comme ça en
> passant...
impossible != interdit ou invalide
D'ailleurs ce n'est pas le seul problème de leur brevet. Où est l'innovation technique ici ?
On le sait bien que c'est "possible", et c'est bien un des problèmes que ce soit possible bien que non légal. Certains tentent de faire passer tout et n'importe quoi, soit pour faire des sous, soit pour terroriser le petit d'en face, soit comme monnaie d'échange.
Visiblement ton avocat ou ta société fait partie de ce lot là parce qu'ils ne vont quand même pas soutenir qu'ils pensaient réellement faire une innovation technique méritant un monopole dans le cas que tu soulèves.
Bref, c'est sur que si tu demandes à ce genre de personnes ce qu'est un brevet, tu obtiendras une réponse sensiblement différente que celle que te donneront les anti-. Et la différence ne vient pas uniquement d'un problème de compétence/connaissance des intervenants dans la discussion.
> Conclusion, pour contribuer, il faut accepter cet affaiblissement du copyleft version GPLv2.
En même temps ça a toujours été le cas puisque auparavant pour contribuer il fallait donner tout son copyright(*) et donc par là accepter non seulement un affaiblissement potentiel des conditions de la GPL mais aussi carrément une autre licence.
Bref, la donne n'a pas changée.
(*: sur ce point précisément je n'en sais rien mais c'est la seule possibilité qui rendrait possible le rachat du projet avec l'ajout de l'exception à tout le projet comme ça vient d'être fait).
Pourquoi ? c'est juste une exception qui te permet de faire des choses "en plus" (à certaines conditions) que ce que te permet la GPL.
Pour tout ceux qui n'ont pas pour intention de développer du propriétaire basé sur cups à destination d'OS Apple, ça ne changera rien du tout. Ils pourront continuer à appliquer la GPL en oubliant complètement l'exclusion ci dessus.
On ne parle justement pas de racheter l'entreprise qui maintient un code, ou d'embaucher le leader. On parle de racheter un logiciel.
Quand tu contribues tu es aussi un des auteurs du logiciel, ce logiciel est aussi le tien (proportionnellement à tes contributions bien sûr).
Ca te parait logique et naturel qu'un tiers puisse vendre ton travail et celui de toute une communauté à son seul profit et suivant ses seuls choix simplement parce qu'il en a fait le principal ou qu'il est à l'origine du projet ?
Et on ne parle pas vraiment forcément de gagner de l'argent, on parle de paternité et de droit d'auteur aussi. Non seulement un tiers a vendu leur travail mais surtout les conditions du logiciel ont changé. Ces contributeurs ont mis leur code explicitement sous copyleft, pour éviter qu'il puisse être utilisé dans du proprio, c'est le but de ce genre de licence. Voilà que le projet racheté une entreprise met des exclusions de licence justement pour autoriser les dérives et extensions propriétaires. Ca te semble logique ?
L'indépendance ce n'est pas vivre isolé, c'est choisir ses contacts et être capable d'en changer à loisir voire de les couper. Avoir un partenariat avec quelqu'un, même très poussé, n'implique pas forcément d'être dépendant.
Voilà pourquoi à mon sens les contributeurs du libre ne devraient pas donner leur copyright quand ils contribuent.
Je n'ai rien contre un rachat et un contrôle par Apple mais je pense que les contributeurs qui n'ont rien touché de l'argent et qui voient maintenant des restrictions sur le nom du logiciel ou la possibilité de lié du propriétaire "si c'est pour l'OS Apple" doivent l'avoir mauvaise.
Les gens se fichent du logiciel et le voient comme un outil ? je ne vois pas ce qu'il y a de triste là dedans. Le logiciel *est* un outil et s'il arrive à se faire oublier c'est plutôt une réussite.
S'ils ne voient pas suffisamment de points négatifs pour faire un choix ou même se préoccuper d'un choix, c'est là aussi plutôt positif.
Et que des non techniciens fassent un classement différent que le tien n'a rien non plus d'étonnant ou même de dommage. C'est juste qu'ils ne le font pas avec les même critères. Eux jugent l'utilisation et la pénébilité de l'outil (et forcément, ajouter un soft non présent par défaut, changer des habitudes, risquer des incompatibilités avec l'existant, tout ça c'est pénible et demande un engagement que certains ne sont pas prêts à faire). Toi tu juges sa qualité technique et ses possibilités.
Le respect des standard c'est une question de technicien. L'utilisateur lui voit seulement si ça fonctionne ou si ça ne fonctionne pas. Il ne sait pas si un contenu est standard ou pas, ce que ça implique, et d'où vient la faute si un contenu ne passe pas.
Il n'y a aucune raison que des non informaticiens parlent de respect des standards quand ils pensent à leur navigateur, pas plus que je ne me préoccupe de savoir quel téléphone filaire respecte le mieux le standard de communication téléphonique.
Ca ne veut pas dire que ça n'a pas d'importance, juste que ce n'est pas à eux de s'en préoccuper.
Le côté libre / floss par contre c'est vrai que c'est dommage parce que c'est une question qui est celle du partage et de la pérennité, ça a des échos pour tout le monde.
[^] # Re: au moins il y a de la justice
Posté par Éric (site web personnel) . En réponse au journal Skype condamné pour Violation de GPL. Évalué à 3.
Sauf que :
- on ne donne jamais "à chaque victime", mais uniquement à celles qui sont partie civile (grosso modo : qui ont parté plainte).
- quelqu'un qui porte plainte et qui obtient gain de cause et par principe la "victime" de l'affaire
- dans notre cas les seules victimes sont les auteurs du logiciel, pas les utilisateurs en manque de code source
A priori il n'y a qu'un seul plaignant, c'est l'unique auteur que la justice va considérer pour les dommages et intérêts, donc je maintiens, c'est lui qui récupèreras les sous de dommages et intérêts.
Effectivement par contre, dans le cas d'une amende ça ne va pas aux plaignants/victimes mais on parle bien d'une plainte civile là, donc à priori il y aura dommages et intérets
[^] # Re: XMPP / Empathy
Posté par Éric (site web personnel) . En réponse à la dépêche Empathy : l'avenir de la messagerie instantanée dans GNOME. Évalué à 5.
Pour le 3 c'est une question de dénominateur commun. Telepathy va forcément rencontrer à moyen terme des problèmes similaires. Quand on met une couche d'abstraction on a toujours le risque de perdre des détails.
Pour le 2, en considérant une passerelle locale (c'est à dire le même niveau d'abstraction/architecture que telepathy), je ne vois pas où est la difficulté en plus par rapport à ce que ferait telepathy.
[^] # Re: XMPP / Empathy
Posté par Éric (site web personnel) . En réponse à la dépêche Empathy : l'avenir de la messagerie instantanée dans GNOME. Évalué à 3.
Oui, ça correspond à quelque chose du genre.
> Tu oublies juste qu'il y a déjà un existant qui s'appelle d-bus pour faire
> ce genre de "messagerie" entre applis locales et qu'il serait
> dommage de ne pas en profiter ou de réinventer la roue.
Certes, mais entre utiliser un socket tcp/ip là où on pourrait utiliser dbus (ce que j'imaginais) et avoir à réimplémenter entièrement un protocole pour la gestion de la présence, pour les messages instantannés, pour la gestion des comptes, pour la gestion des contacts (ce qui a été fait ou qui est fait dans telepathy si j'ai bien compris) ...
J'ai l'impression que la seconde option est bien plus proche du "réinventer la roue" que la première. Maintenant il est possible/probable qu'il y ait quelque chose que je n'ai pas vu qui inverse la balance.
[^] # Re: XMPP / Empathy
Posté par Éric (site web personnel) . En réponse à la dépêche Empathy : l'avenir de la messagerie instantanée dans GNOME. Évalué à 1.
Le partage des connexions n'y est pas, il est vrai, mais xmpp permettant de gérer plusieurs connexions sur le même compte, je ne sais pas si c'est vraiment indispensable de partager la connexion (surtout si on peut mettre un proxy xmpp au milieu pour ne pas surcharger le serveur distant).
Le cloisonnement, si je ne me trompe pas les passerelle jabber sont déjà indépendantes de ce côté là.
Mais qu'on soit d'accord, je ne dis pas que XMPP est la solution à tout où que Empathy a son rôle à jouer. C'est juste que je ne vois pas dans la news, dans le site ou dans ta réponse la fonctionnalité clé que couvre Empathy et que ne couvrait pas déjà XMPP à la base.
Mieux que ça même, je ne remettais pas en cause le bénéfice d'empathy, je demandais juste qu'on me le mette en lumière.
[^] # Re: XMPP / Empathy
Posté par Éric (site web personnel) . En réponse à la dépêche Empathy : l'avenir de la messagerie instantanée dans GNOME. Évalué à 8.
> devoir reparser le XML à la main.
Je le conçois, mais dans ce cas la solution peut être une libxmpp ou une libjabber, pas forcément un serveur complet avec son propre protocole.
> En plus, il n'est pas évident qu'un "proxy XMPP" soit la solution
> multi-usage, ceux qui utilisent les passerelles Jabber savent qu'il
> n'est pas évident que le plus petit dénominateur commun convienne à
> tout le monde...
Empathy n'a pas l'air de changer quoi que ce soit à cette problématique. Il y a une méthode d'accès par fonctionnalité si j'ai bien compris. Donc on parle toujours d'avoir un dénominateur commun unique.
# XMPP / Empathy
Posté par Éric (site web personnel) . En réponse à la dépêche Empathy : l'avenir de la messagerie instantanée dans GNOME. Évalué à 10.
Ca c'est bien, mais ça ne fait pas déjà un double emploi avec ? XMPP est pour moi déjà un protocole standardisé qui gère tout ça. Il aurait "suffit" de faire une sorte de proxy XMPP local qui forwarde aux différents serveurs (jabber, msn, autres). Les applications n'auront qu'à parler XMPP.
Là j'ai l'impression qu'on refait encore une couche d'abstraction sans qu'elle apporte rien de plus que XMPP. Au lieu de dialoguer en XML/XMPP les applis vont dialoguer avec des structures en C avant d'être retraduits en XML/MSN/autre. Je ne suis pas certain du gain là.
Quelqu'un pour m'éclairer ?
[^] # Re: Chaînes de droite
Posté par Éric (site web personnel) . En réponse au journal freebox, télé et non dégroupés. Évalué à 4.
Oui, je sais, c'est crétin comme critère, mais c'est comme ça.
[^] # Re: et la redevance ?
Posté par Éric (site web personnel) . En réponse au journal freebox, télé et non dégroupés. Évalué à 9.
Ce n'est pas non plus un "vide juridique". Ta formulation laisse à penser que les ordinateurs ne sont pas inclus à cause d'une formulation obsolète alors qu'on voudrait les inclure. Or là c'est bien le contraire : ils sont inclus par défaut (comme tous les appareils permettant de recevoir la télévision) et ont été exclus explicitement. C'est tout sauf un vide juridique, c'est exactement le contraire, c'est une volonté manifeste.
Enfin, le succès des box ADSL je veux bien mais pour l'essentiel les gens branchent une vrai TV derrière. Ceux qui regardent via VLC sont des geeks ou étudiants, encore très minoritaires. Ceux qui le font sans avoir une TV à côté (donc qui ne payent pas déjà la redevance) sont encore plus minoritaires.
Bref, ça ne me semble pas une piste majeur. La fraude à la redevance me parait beaucoup plus importante que cette niche réduite. D'autant que dans cette niche il y a beaucoup d'étudiants qu'on n'a pas forcément envie de mécontenter bêtement sur ça.
[^] # Re: J'ai remplacé ubuntu par debian
Posté par Éric (site web personnel) . En réponse au journal Retour vers le futur pour MEPIS. Évalué à 1.
> quand meme des maj de sécurité si je ne m'abuse. Ce qui
> n'est pas forcément le cas de multiverse . Il y a déja eu des
> cas en tout cas.
Attend, tu es bien en train de comparer avec la debian testing qui elle n'a aucune garantie d'avoir les maj sécurité tout court ? (à moins que ça ait changé la garantie des maj sécu elle est sur la stable ; la testing est celle ou les maj de sécu sont les moins suivies)
[^] # Re: .
Posté par Éric (site web personnel) . En réponse au journal Les machines a voter, définitivement pas sur.. Évalué à 4.
Certes, reste à voir l'utilité de "gros blocs de data" dans le cadre d'un vote. Inscrire un octet à chaque vote dans le fichier au nom du candidat choisit ça garde une atomicité très simple à garantir. Tu n'auras jamais de démi octet écrit donc l'écriture ton bloc de data sera atomique.
[^] # Re: fichier texte
Posté par Éric (site web personnel) . En réponse au journal Les machines a voter, définitivement pas sur.. Évalué à 3.
> compteur ?
La même chose que s'il y a une erreur de disque pendant que ton SGBD transactionnel bosse ?
- c'est une erreur non détectée par le logiciel, ça merdera sur le fichier texte mais aussi sur ton SGBD
- c'est une erreur renvoyée par l'OS mais le système continue de tourner : le SGBD comme la fonction d'écriture vont te répondre que l'écriture n'a pas eu lieu, à toi d'en faire ce que tu veux
- le système crashe, au redémarrage tu peux récupérer le journal d'écriture (celui du FS dans le cas du fichier texte, et en plus celui du SGBD dans ton cas), et là dans les deux cas l'écriture du journal peut être incomplète et on perd le dernier vote, soit elle est complète et on peut la récupérer.
Reste le cas où on écrit une demi ligne dans le fichier texte avant le crash, mais il existe des solutions très simples pour palier le problème (genre un fichier par candidat, à chaque vote on écrit un octet dedans : aucun risque de demi écriture ou d'écriture incohérente, et cette dernière solution est vachement plus sécurisée pour ce cas d'utilisation que tout ce que tu pourras faire avec ton moteur transactionnel).
Bref, dans les deux cas on peut perdre le dernier vote, dans les deux cas on ne peut perdre que le dernier vote (sous réserve de faire un flush entre chaque écriture).
[^] # Re: .
Posté par Éric (site web personnel) . En réponse au journal Les machines a voter, définitivement pas sur.. Évalué à 6.
Bref, un fichier de texte ouvert en écriture avec un flush et un FS journalisé, *ici* ça offrira autant ou presque que ce que peut proposer un SGBD évolué.
En effet, recoder tout soit même est très rarement "mieux", mais là quand il s'agit juste de faire un compteur fixe sans concurrence d'accès et sans contraintes de performances ... utiliser une couche SQL je vois mal ce que ça peut apporter de positif.
[^] # Re: Fanatiques ?
Posté par Éric (site web personnel) . En réponse au journal Skype condamné pour Violation de GPL. Évalué à 2.
Bref, s'il y avait un papier avec une URL, la licence et une explication je pense que ça aurait été. Là il n'y avait pas de copie de la GPL (ça c'est un problème), les détails d'accès au code source n'ont été donnés qu'après coup (pas sur les premières boites, ça aussi c'est un problème) et pas sur tout le logiciel (si j'ai bien compris uniquement vers les softs d'origine sur Internet, pas leur code/config/modif).
> non, a priori, cette affaire ne donne aucune chance d'avoir accès au
> code source du logiciel Skype.
Comme aucune affaire liée à la GPL. Au pire tu fais de la contrefaçon et donc on peut te demander de payer les dommages et intérêts, mais jamais il n'y aura de "tu l'as distribué donc tu dois maintenant donner ton code source contre ton gré".
[^] # Re: au moins il y a de la justice
Posté par Éric (site web personnel) . En réponse au journal Skype condamné pour Violation de GPL. Évalué à 3.
Peut être que tu peux compter qu'il utilisera ses sous pour gpl-violations mais rien ne l'y oblige, ni juridiquement ni même moralement.
Par contre tous ceux qui ont des droits sur le noyeau linux peuvent faire la même chose à priori.
# Mouais
Posté par Éric (site web personnel) . En réponse au journal Les brevets, c'est toute une histoire.... Évalué à 3.
Le brevet, si on regarde les textes français, couvre un *procédé* technique, pas un effet. Le terme des textes est explicite, c'est la façon de faire, le procédé, qui compte. Trouver une autre procédure pour convertir le plomb en or permet effectivement normalement de passer à côté du brevet.
Par contre ça couvre un autre comment que le copyright. Le copyright couvre l'originalité de l'oeuvre. Si tu utilises la même procédure mais sans "copier", tu n'as pas de problèmes de copyright. Par contre, même avec une autre procédure, si tu réutilises les plans ou si tu as le même aspect extérieur, tu auras des problèmes de copyright
Disons que l'esprit initial c'est d'éviter que des secrets de mise en oeuvre/création se perdent. On fait donc un deal : tu révèles ton secret et en échange on te garantis que tu restes seul à pouvoir l'utiliser pendant un temps (comme si tu gardais le secret). Du coup on s'assure qu'à terme la connaissance globale de l'humanité évoluera.
Pour la note c'est d'ailleurs aussi pour ça que dans certains pays, tant que l'invention n'est pas publique, on offre le brevet au premier qui dépose (donc qui révèle au public), et pas forcément à l'inventeur de départ.
Le fait qu'on considère le brevet comme un investissement et le ROI de la R&D, le fait qu'on cherche à lui faire couvrir l'effet plutôt que la procédure, ce sont les deux dérives actuelles qui font que notre système de brevet n'a plus aucun sens et est pourri jusqu'à la moelle (et franchement les brevets logiciels n'ont rien d'isolés à ce niveau).
> Ah, et comme ça en passant, pour tous ceux qui pensent que
> poser des brevets logiciels en Europe c'est impossible, je leur ai
> demandé et ils m'ont affirmé que la semaine passée ils ont fait
> valider un brevet sur la gestion d'objets dans un système
> d'exploitation à l'office des brevets de Londres. Juste comme ça en
> passant...
impossible != interdit ou invalide
D'ailleurs ce n'est pas le seul problème de leur brevet. Où est l'innovation technique ici ?
On le sait bien que c'est "possible", et c'est bien un des problèmes que ce soit possible bien que non légal. Certains tentent de faire passer tout et n'importe quoi, soit pour faire des sous, soit pour terroriser le petit d'en face, soit comme monnaie d'échange.
Visiblement ton avocat ou ta société fait partie de ce lot là parce qu'ils ne vont quand même pas soutenir qu'ils pensaient réellement faire une innovation technique méritant un monopole dans le cas que tu soulèves.
Bref, c'est sur que si tu demandes à ce genre de personnes ce qu'est un brevet, tu obtiendras une réponse sensiblement différente que celle que te donneront les anti-. Et la différence ne vient pas uniquement d'un problème de compétence/connaissance des intervenants dans la discussion.
[^] # Re: indice
Posté par Éric (site web personnel) . En réponse au journal Desperates Freenautes :-(. Évalué à 3.
[^] # Re: Et les contributeurs ?
Posté par Éric (site web personnel) . En réponse à la dépêche Apple rachète CUPS. Évalué à 1.
La seule chose que tu n'auras pas ce sont des modules spécifiques Mac, qui n'existaient déjà pas avant.
[^] # Re: Adieu cups
Posté par Éric (site web personnel) . En réponse à la dépêche Apple rachète CUPS. Évalué à 2.
En même temps ça a toujours été le cas puisque auparavant pour contribuer il fallait donner tout son copyright(*) et donc par là accepter non seulement un affaiblissement potentiel des conditions de la GPL mais aussi carrément une autre licence.
Bref, la donne n'a pas changée.
(*: sur ce point précisément je n'en sais rien mais c'est la seule possibilité qui rendrait possible le rachat du projet avec l'ajout de l'exception à tout le projet comme ça vient d'être fait).
[^] # Re: Ben et les contributeurs ?
Posté par Éric (site web personnel) . En réponse à la dépêche Apple rachète CUPS. Évalué à 2.
Non, mais à certaines conditions seulement (celles de la licence), conditions qui ont justement changé ici lors du rachat.
[^] # Re: Adieu cups
Posté par Éric (site web personnel) . En réponse à la dépêche Apple rachète CUPS. Évalué à 2.
Pour tout ceux qui n'ont pas pour intention de développer du propriétaire basé sur cups à destination d'OS Apple, ça ne changera rien du tout. Ils pourront continuer à appliquer la GPL en oubliant complètement l'exclusion ci dessus.
[^] # Re: Ben et les contributeurs ?
Posté par Éric (site web personnel) . En réponse à la dépêche Apple rachète CUPS. Évalué à 8.
Quand tu contribues tu es aussi un des auteurs du logiciel, ce logiciel est aussi le tien (proportionnellement à tes contributions bien sûr).
Ca te parait logique et naturel qu'un tiers puisse vendre ton travail et celui de toute une communauté à son seul profit et suivant ses seuls choix simplement parce qu'il en a fait le principal ou qu'il est à l'origine du projet ?
Et on ne parle pas vraiment forcément de gagner de l'argent, on parle de paternité et de droit d'auteur aussi. Non seulement un tiers a vendu leur travail mais surtout les conditions du logiciel ont changé. Ces contributeurs ont mis leur code explicitement sous copyleft, pour éviter qu'il puisse être utilisé dans du proprio, c'est le but de ce genre de licence. Voilà que le projet racheté une entreprise met des exclusions de licence justement pour autoriser les dérives et extensions propriétaires. Ca te semble logique ?
[^] # Re: Sans "Fuck you money", on est à la merci de ce genre de choses...
Posté par Éric (site web personnel) . En réponse à la dépêche Apple rachète CUPS. Évalué à 10.
# Et les contributeurs ?
Posté par Éric (site web personnel) . En réponse à la dépêche Apple rachète CUPS. Évalué à 10.
Je n'ai rien contre un rachat et un contrôle par Apple mais je pense que les contributeurs qui n'ont rien touché de l'argent et qui voient maintenant des restrictions sur le nom du logiciel ou la possibilité de lié du propriétaire "si c'est pour l'OS Apple" doivent l'avoir mauvaise.
# bof
Posté par Éric (site web personnel) . En réponse au journal Internet Explorer ou Firefox : micro-trottoir chez les gamers. Évalué à 8.
S'ils ne voient pas suffisamment de points négatifs pour faire un choix ou même se préoccuper d'un choix, c'est là aussi plutôt positif.
Et que des non techniciens fassent un classement différent que le tien n'a rien non plus d'étonnant ou même de dommage. C'est juste qu'ils ne le font pas avec les même critères. Eux jugent l'utilisation et la pénébilité de l'outil (et forcément, ajouter un soft non présent par défaut, changer des habitudes, risquer des incompatibilités avec l'existant, tout ça c'est pénible et demande un engagement que certains ne sont pas prêts à faire). Toi tu juges sa qualité technique et ses possibilités.
[^] # Re: Je retiendrais...
Posté par Éric (site web personnel) . En réponse au journal Internet Explorer ou Firefox : micro-trottoir chez les gamers. Évalué à 9.
Il n'y a aucune raison que des non informaticiens parlent de respect des standards quand ils pensent à leur navigateur, pas plus que je ne me préoccupe de savoir quel téléphone filaire respecte le mieux le standard de communication téléphonique.
Ca ne veut pas dire que ça n'a pas d'importance, juste que ce n'est pas à eux de s'en préoccuper.
Le côté libre / floss par contre c'est vrai que c'est dommage parce que c'est une question qui est celle du partage et de la pérennité, ça a des échos pour tout le monde.