Ah mais je suis tout à fait d'accord avec toi, 42 forme des humains à un état d'esprit bien spécifique. Tu décris cet état d'esprit comme étant le mal, comme si les gens qui en sortaient n'étaient rien d'autre que des zombies cracheurs de code. Sauf que les 2 points de la notation sont une forme stricte de ce que tu trouveras de toute façon en entreprise (dans une boite qui fait du logiciel, hein). Si tu t'habitues à ça, la version "vie réelle" sera enfantine. Je peux t'assurer que ces deux points sont absolument critiques à la réussite d'un projet (parce que dans réussite, il y a aussi maintenance après la livraison, et c'est là qu'on voit très clairement ceux qui n'auraient jamais du passer la Moulinette).
Ah, et on en fait tout un foin, mais on parle là de la piscine, c'est-à-dire la période de 1 mois qui ne sert qu'à sélectionner les gens qui passent. Un peu comme quand tu as un projet pour un gros client dans un mois, si tu rates ce client t'es foutu, tu t'es mal débrouillé du coup t'es à la bourre comme pas possible: tu peux ne pas aimer ça, mais parfois se démener pour une cible précise peut être nécessaire.
Du peu que j'ai vu, 42 est une école préparatoire aux entreprises, il faut être clair.
Première étape: le compilateur est con comme un manche, les autres développeurs sont nuls mais croient tous être uniques. Le seul moyen de bosser correctement ensemble, c'est d’être rigoureux sur la manière dont on s'organise; c'est se poser des conventions et s'y tenir.
Deuxième étape: a moins que tu écrives du logiciel libre pour une entreprise, les seuls qui pourront lire ton code et te donner leurs commentaires seront tes collègues, et j’espère bien que tu fais des revues de code avec eux avant de passer ton code en production. Le fait qu'ils soient en compétition avec toi, tant dans l'entreprise que chez 42, est selon moi une énorme erreur, malheureusement. Par contre c'est beaucoup plus intelligent que de faire corriger ça par un prof (il n'y a pas de prof qui connait tout a 100% en entreprise)
C'est pas du tout mon expérience, mais c'est vrai qu'elle est pas très longue. J'aurais tendance a penser que c'est comme ça dans une boite qui tourne dans l'informatique, et dans ce cas je confirme, écrire du code qui fait ce qui est demande sans dépasser les contraintes temps/budget, c'est beaucoup plus important que la couleur de la cravate du consultant (qui n'en n'a même pas, d'ailleurs).
Il serait peut-être judicieux de se renseigner un minimum, non ?
La notation se passe en 2 temps:
Première étape, la Moulinette et sa copine la Norminette: cette dernière vérifié juste des trucs bêtes comme la syntaxe, si les fichiers ont le bon nom, s'ils sont dans le bon dossier, bref, s'il respecte les normes, si ça passe pas c'est 0. Si ça passe, le code est compile puis teste, si ça passe pas, c'est 0. Ça ressemble pas mal a ce qui peut être attendu de toi en entreprise (un code qui fait pas ce qu'on lui demande, voire qui le fait mal, c'est direct des problèmes avec le client ou l'utilisateur et les brouzoufs qui s'enfuient a toute vitesse)
Deuxième étape, la notation par les pairs: ce sont d'autres nageurs qui notent, en groupe, et cette notation est elle-même notée. Je connais pas les détails, mais d’expérience sur des situations similaires ce sont les pairs qui sont toujours les plus critiques.
En bref, pisser du code comme un consultant ne suffira pas, loin de la.
Ça dépend. Je suis de ceux qui pensent qu'une situation exceptionnelle est effectivement exceptionnelle, et que tu n'as donc pas nécessairement le temps/les moyens de nettoyer proprement derrière toi quand un problème survient. Si tu te débrouilles pour qu'un SIGKILL soit la manière normale de fermer ton logiciel (pas de transaction à écrire, pas de fichier à créer/déplacer/supprimer, …), alors tu es prêt pour toutes les situations.
Lister et indexer les salons publics c'est possible […] Tenir un salon sans avoir à l'héberger c'est déjà possible
Techniquement tout ça c'est possible, le problème c'est qu'en pratique c'est beaucoup moins accessible qu'IRC: déjà il faut trouver quelqu'un qui veut bien l'héberger, je suis sûr que des services existent bien mais là comme ça aucun nom ne me vient en tête. À l'inverse sur IRC le premier réseau qui te vient en tête pour avoir un chan pour ton projet c'est Freenode. Je suis convaincu qu'avec une fédération au niveau des salons de discussion-même (et non pas juste au niveau des serveurs), on pourra voir émerger un réseau communautaire qui hébergera la plupart des salons (un peu comme Freenode), et que ça facilitera la dissémination de XMPP (plus de découvrabilité, plus de visibilité)
Est-ce que tu as plus de détails sur les discussions sur MUC 2 ? J'avais lu la XEP-289, et je l'avais trouvé super intéressante, à mon avis tant que XMPP n'aura pas de salon de discussion qui vont dans ce sens IRC aura encore une bonne raison d'exister, parce que la fédération des serveurs permet d'avoir un endroit où il est plus facile de
lister et indexer les discussions qui existent, pour les rendre plus facilement découvrables
tenir un salon, sans avoir à l'héberger soi-même
Je vois également que tu vas t'intéresser de plus près au côté non-messagerie, qui est effectivement extrêmement important à remonter tant il est sous-exploité, j'ai hâte !
C'est un poil malhonnête comme comparaison: dans tame le développeur dit ce dont il a besoin et laisse le système gérer les cas d'erreur, alors que dans le cas de Capsicum c'est le développeur qui doit gérer lui même les cas d'erreur. Un truc un peu plus lisible aurait été du genre caps_ioctls_limit quitte le programme avec une grosse erreur si c'est pas possible. Bon, dit comme ça, on se dit que ça devrait être le boulot de Capsicum d'offrir cette API là, mais bon.
le wiki est un ensemble de fichiers dans un repository git, qui peut être servi par une application tierce libre, gollum
les issues et Pull Requests peuvent être récupérées via l'API, après ce sont de simples fichiers JSON
Pour moi, Github ne peut pas subir le même sort que Sourceforge parce que tout peut être récupéré et modifié depuis l'extérieur, vu que le format est spécifié. C'est d'ailleurs déjà courant, il y a nombre de services qui interagissent avec cette API. De la même manière que Word a beau être propriétaire, si le format utilisé est ODF, au moins tout le monde peut le parler. Du coup pour moi Github est loin d'être autant le mal qu'on en dit.
Le seul intérêt était de pouvoir utiliser un client tiers […] Utiliser XMPP pour que tout le monde ou presque se retrouve chez le même hébergeur, sans chiffrement ou fédération, sans contrôle sur les données, ça n'a pas grand intérêt.
Je sais que tu aimes le coté fédération qui est si cher a XMPP, mais pour moi c'estc’était quand même intéressant que Facebook utilise XMPP, pour pouvoir reutiliser tout ce qui se fait cote client qui ne dépend pas du serveur: chiffrement bout-en-bout, Jingle, bots divers, parties de tarot …
Les experts confirmeront, mais la visio conf c'est du Jingle, c'est-à-dire que c'est un problème purement client qui ne dépend absolument pas du serveur, puisque ce sont des choses qui se négocient de client à client; ça ne concerne donc pas prosody !
(Bon en réalité, pour ce qui est transport dans Jingle, typiquement la connexion directe de client à client ne marche pas, il vaut mieux passer par un tiers, comme par exemple un proxy SOCKS5. Ça tombe bien, Prosody peut faire proxy SOCKS5)
Par contre je te rejoins à 100% sur le sujet: si quelqu'un avait un tuto, ça serait super, ne serait-ce que pour se donner un coup de pied dans le derrière et implémenter ça un peu partout !
J'irais même plus loin concernant Prosody: le paquet de base répond déjà a 80% des besoins. S'il manque quelque chose, il y a une très forte chance qu'un module fasse l'affaire. Si c'est encore pas suffisant, en effet il faut soi faire du Lua soit passer par un composant externe. Ce qui en pratique revient a coder. Mais pour un usage "standard", il n'y a absolument pas besoin d'aller jusque la.
Prosody ça juste marche, c'est facile a installer et a utiliser, c'est stable, sans écrire une ligne de lua… Que demander de plus ?
Attention à ne pas confondre dividende universel (quantité d'argent que n'importe quel citoyen reçoit sans condition) et salaire (quantité d'argent que n'importe qui reçoit en récompense de son travail). Les deux ne sont pas incompatibles, bien au contraire. Personne ne prétend remplacer tous les revenus d'argent par le dividende universel; ce dernier peut, tout au plus, suffire à assurer les besoins primaires (logement, nourriture, accès téléphone/internet). Et encore. Pour tout le reste il y a le travail !
Décider à qui on donne l'argent, combien et au nom de quoi, on le fait tout les jours. Ça me paraît être le problème politique de fond derrière le brevet, en fait.
Est-ce que tu imagines un organisme gouvernemental qui décide combien donner
à celui qui trouve un procédé pour allonger la durée de vie des batteries
à celui qui trouve un procédé pour fabriquer des balles de FAMAS plus vite
à celui qui trouve un procédé pour qu'un moteur thermique consomme 10% de moins
à celui qui trouve un procédé pour s'éclairer avec 10x moins d'énergie qu'aujourd'hui
à celui qui trouve un procédé pour se téléporter
Bon, c'est vrai, je connais pas le monde de la recherche, mais j'ai l'impression que si un organisme devait décider combien donner pour chaque "équivalent-brevet", ça serait assez vite le bordel.
Mais tu ne dis pas ce qu'est un inventeur dans un système où le brevet est aboli ?
Même de manière générale, qu'est-ce qu'un inventeur ? Je doute qu'on puisse effectivement définir un statut qui donne droit à une subvention. Surtout que la plupart des inventeurs aujourd'hui sont des équipes dans des compagnies. Mais pourquoi pas.
Nan mais on paye déjà des milliers de chercheurs avec du salaire […] Je vois pas quel progrès un dividende universel pourrait apporter par rapport au salaire, en particulier s'il s'agit de se débarasser du brevet
Ne pas avoir besoin du statut officiel de chercheur pour pouvoir inventer ? Je pense par exemple aux développeurs open source; tiens, par exemple, Bram Cohen qui a mis au point Bittorrent, il n'est pas chercheur, et pourtant la société devrait pouvoir le remercier.
Franchement le don j'y crois absolument pas.
Idem. À moins d'avoir un moyen super simple et répandu pour transférer de l'argent, ça ne financera pas grand chose à lui tout seul.
Généralisation du salaire à tous les inventeurs du territoire
Comme dit plus haut, ça pose le problème de définir qui est inventeur, et le problème de "si tu es inventeur, tu ne peux pas être autre chose (ie avoir une autre activité)". C'est pour ça que je suis plutôt en faveur d'un dividende universel, qui laisse l'opportunité à n'importe qui d'inventer… mais ça n'est pas suffisant pour la partie "remerciement".
Mais justement ! Comme je l'ai dit plus haut, il y aura toujours des éléments mathématiques qui portent le logiciel. Je ne le nie absolument pas. Sauf que les équations sont tout en bas dans la chaîne.
Si un logiciel existe, c'est d'abord pour répondre à un besoin. Ton logiciel qui positionne un outil dans l'espace, tu l'écris pour permettre à un humain de positionner un logiciel dans l'espace. C'est exactement ça qui est protégé par le brevet: un machin qui remplit la fonctionnalité utilisée par des gens.
Et je confirme: répondre à une fonction n'est pas l'application d'une équation, sauf dans des cas très limités. Quand je dis fonction, ici, je parle du besoin des utilisateurs potentiels. Est-ce que tu saurais m'expliquer, concrètement, quelles équations j'applique lorsque:
Je télécharge le dernier film de vacances sur Transmission
J'écris ce message dans cette interface
J'envoie ce message sur Linuxrf
Je reçois une notification dans mon flux RSS que tu m'auras répondu
Aucune de ces fonctionnalités n'a été implémentée comme l'application d'une ou plusieurs équations. Un médicament, qui n'est que l'application des connaissances scientifiques sur les effets de telle ou telle molécule, peut effectivement être vu comme l'application directe d'une "équation" (même si dans ce cas on parlera plutôt de réaction). Dans le cas d'un logiciel, les équations sont loin d'être la raison première de son existence.
Très bonne question, il "suffit" de revenir à la base pour comprendre: un type passe du temps dans son labo, et au bout d'un moment arrive à résoudre un problème humain avec une machine/un procédé. En tant que société on a décidé de le remercier en le payant pour ses efforts.
Sauf qu'au lieu de lui donner de l'argent, ce qui serait une calamité en matière de gestion (tout simplement parce que personne ne sera d'accord sur le "combien"), on part du principe que l'inventeur est aussi un bon industriel, et qu'il va donc vendre son procédé. Pour être sur qu'il le fasse, la société lui assure un monopole sur l'exploitation de son procédé. C'est là qu'est la protection: protection contre la concurrence, limitée dans le temps. Et ça pose un problème majeur: pour que le système marche il faut être un bon industriel (le monopole ne fait pas tout, surtout si l'inventeur part de zéro)
Du coup si on veut vraiment abolir les brevets, il faut revenir aux sources et se demander: comment remercier les inventeurs ? (Je pars du principe qu'on veut bien les remercier, parce qu'on est pas des rats)
Le dividende universel suffirait-il ? Ya pas vraiment de "remerciement" dans le sens où l'inventeur n'empoche pas plus que les autres. Mais au moins ça pourrait aider à financer tous ces pauvres inventeurs qui n'ont pas pu aller au bout (voire même commencer) parce qu'ils n'avaient pas les fonds
Le don ? Même s'il est vrai qu'il est techniquement infiniment plus facile de donner aujourd'hui qu'à l'époque où les brevets ont été mis en place, je doute sur la viabilité de la chose. D'autant que ça voudrait dire qu'au lieu d'être un industriel, l'inventeur devrait être un "marketeux" pour convaincre les gens de lui donner
Moi je serais plutôt pour un mix des deux, avec un bonus si l'inventeur ne brevète pas mais décide juste de faire un papier (pour prouver l'antécédent), tout en punissant bien les officines de brevets qui ne font pas leur boulot autant que ceux qui ne commercialisent pas le fruit du brevet (si le monopole n'est pas utilisé, il doit y avoir sanction et retrait du monopole)
Quand quelqu'un trouve quelque chose, il le publie dans un article, avec son nom et une date.
Ya un peu de la même chose en informatique: quelqu'un peut écrire un papier et le diffuser (Google fait beaucoup ça, par exemple avec BigTable). Ce qui est bien c'est que ça montre au futurs breveteurs potentiels qu'il y a de l'état de l'art, et que donc un brevet un peu trop proche serait invalide.
je vois pas très bien l'intérêt :
- d'accorder au dépositaire un monopole qui lui permettra de tirer une rente
L'idée, à la base, c'est que l'inventeur commercialise son invention pour se payer la recherche. Le monopole lui assure que la commercialisation marche, et qu'il gagne effectivement de l'argent avec.
de reporter les bénéfices dont pourrait bénéficier immédiatement la société
Les bénéfices sont là, théoriquement: la société profite de l'invention au travers de la commercialisation des produits finis. Elle n'a juste pas accès à la fabrication, au sens où elle ne peut modifier la machine. Mais elle profite bien de l'invention.
Ça, bien sûr, c'est la théorie, et quand des boîtes s'amusent à garder le monopole sans rien en faire c'est très clairement un abus. De la même manière qu'accepter des brevets vagues, qui englobent beaucoup trop, est un abus.
Le logiciel lui même, c'est la démonstration de cette équation.
Peut-être que dans quelque cas très rares, c'est vrai, mais l'immense majorité des logiciels n'ont pas été créés pour démontrer une équation (ou même en être l'utilisation) mais pour répondre à une fonction. Je crois que tu oublies trop facilement que les logiciels sont d'abord et avant tout faits pour les humains. En ce sens, ils n'ont pas de valeur absolue (comme pourrait l'être une équation, ou sa preuve) mais une valeur relative aux utilisateurs potentiels.
En plus de ça, même si je suis sûr qu'en fouillant suffisamment on trouvera toujours des bouts de maths, un humain ne crée pas un logiciel à partir de ces bouts de maths (c'est quoi les équations qui permettent de faire fonctionner Docker ? c'est quoi les maths qu'il y a derrière Popcorn Time ?). On est beaucoup beaucoup plus haut.
Pour reprendre le parallèle: un atome n'est pas "libre", dans le sens où il n'a pas de droit. Que t'en prenne un ou plusieurs, c'est pareil. Du coup, un humain, qui n'est rien d'autre qu'une masse d'atomes, n'a pas de liberté à proprement dire. J'ai bon ?
La composante humaine est centrale dans le logiciel (ça a été fait par un humain, pour un humain), c'est pour ça que tu peux pas réduire un logiciel aux maths qu'il y a derrière.
Ça défend l'innovation ça ?
Attention, ne me fais pas dire ce que je n'ai pas dit :)
Les brevets défendent l'acte d'invention par l'inventeur. Et si on regarde bien, ça défend surtout l'inventeur lui-même, contre les gros qui pourraient utiliser le fruit de son travail pour s'enrichir sans que l'inventeur n'en bénéficie (en tout cas, c'est le projet initial). Les brevets ne défendent pas l'invention en général, ou l'innovation, bien au contraire même (ça, c'est aujourd'hui).
je pense que beaucoup (sinon toutes et tous) ici savent qu'un logiciel n'est qu'une forme d'équation mathématique et qu'on ne brevette pas une équation (ni un bout de texte, par exemple)
Pas d'accord, ce raisonnement est tout simplement fallacieux, pour 2 raisons:
Un logiciel n'est pas une équation
Les brevets ne protègent pas tant le procédé lui-même que l'"inventeur" et le phénomène même d'invention
Un logiciel n'est pas une équation
Une équation décrit un phénomène naturel, c'est à dire un phénomène qui existe en dehors de son observation. Les équations de Maxwell définissent comment la lumière se comporte, sans aucune considération pour ceux qui connaissent ces équations.
Un logiciel est l'application d'un algorithme. Un algorithme, ça reste encore un peu "naturel", dans le sens où ça ne dépend pas vraiment des observateurs; son application, par contre, est totalement centrée sur les utilisateurs de cet algorithme. Un logiciel est entièrement conçu pour des humains, il ne sort pas de nulle part et ne décrit absolument rien en soi. C'est un outil, pas une description.
Les brevets défendent l'invention
Et justement, comme tous les outils, il y a quelqu'un (une personne ou un groupe) qui est parvenue à trouver comment réaliser cet outil. C'est exactement ça qui est protégé par un brevet. C'est pour ça que ça n'aurait pas beaucoup de sens de breveter les équations de Maxwell (puisqu'elles permettent de décrire) mais ça a du sens de breveter un machin qui permet de résoudre un problème (puisque c'est un outil, qui à priori a couté du temps et de l'argent à son inventeur). D'ailleurs le nom qu'on utilise c'est procédé.
Alors bien sûr la vision du brevet logiciel (voire même du brevet tout court) aujourd'hui est complètement différente de la vision originelle: les brevets ne servent plus à d'abord faire avancer la société avec comme side-effect d'assurer un revenu à l'inventeur, ils servent d'abord à assurer les revenus à l'inventeur, et ce au détriment de la société. Pour autant, c'est pas une raison pour déformer les faits.
Dire que "les logiciels sont des équations donc non-brevetables" est aussi faux que dire "les humains ne sont qu'une masse d'atomes sans vie donc non-tuable, le meurtre ne doit donc pas être interdit". Un raccourci faux qui mène à une conclusion fausse.
OTR, le protocole de forward secrecy, n'est pas utilisé par TextSecure, comme tu le dis toi-même; ils utilisent leur propre protocole (Axolotl) qui permet d'être réellement asynchrone (ie envoyer des messages même quand l'autre n'est pas connecté), ce qui permet d'ailleurs d'avoir un support pour la discussion de groupe simple contrairement à mpOTR qui galère comme pas possible.
Seul problème: c'est encore pas répandu. J'ai une entrée dans ma TODO-list pour voir comment utiliser XMPP avec, mais comme ma TODO-list fait 200km de long…
[^] # Re: Piscine
Posté par rakoo (site web personnel) . En réponse au journal François Hollande visite 42, non mais allô quoi.... Évalué à 3.
Ah mais je suis tout à fait d'accord avec toi, 42 forme des humains à un état d'esprit bien spécifique. Tu décris cet état d'esprit comme étant le mal, comme si les gens qui en sortaient n'étaient rien d'autre que des zombies cracheurs de code. Sauf que les 2 points de la notation sont une forme stricte de ce que tu trouveras de toute façon en entreprise (dans une boite qui fait du logiciel, hein). Si tu t'habitues à ça, la version "vie réelle" sera enfantine. Je peux t'assurer que ces deux points sont absolument critiques à la réussite d'un projet (parce que dans réussite, il y a aussi maintenance après la livraison, et c'est là qu'on voit très clairement ceux qui n'auraient jamais du passer la Moulinette).
Ah, et on en fait tout un foin, mais on parle là de la piscine, c'est-à-dire la période de 1 mois qui ne sert qu'à sélectionner les gens qui passent. Un peu comme quand tu as un projet pour un gros client dans un mois, si tu rates ce client t'es foutu, tu t'es mal débrouillé du coup t'es à la bourre comme pas possible: tu peux ne pas aimer ça, mais parfois se démener pour une cible précise peut être nécessaire.
Du peu que j'ai vu, 42 est une école préparatoire aux entreprises, il faut être clair.
[^] # Re: Lol
Posté par rakoo (site web personnel) . En réponse au journal François Hollande visite 42, non mais allô quoi.... Évalué à 3.
Comment pourrait-il être le meilleur puisqu'il donne autant de chances de réussite que les autres ?
[^] # Re: adéquation
Posté par rakoo (site web personnel) . En réponse au journal François Hollande visite 42, non mais allô quoi.... Évalué à 6.
Il a dit que c’était théorique, il a pas dit que c’était compliqué. Les deux notions sont orthogonales.
[^] # Re: Piscine
Posté par rakoo (site web personnel) . En réponse au journal François Hollande visite 42, non mais allô quoi.... Évalué à 9.
[^] # Re: Piscine
Posté par rakoo (site web personnel) . En réponse au journal François Hollande visite 42, non mais allô quoi.... Évalué à 2.
C'est pas du tout mon expérience, mais c'est vrai qu'elle est pas très longue. J'aurais tendance a penser que c'est comme ça dans une boite qui tourne dans l'informatique, et dans ce cas je confirme, écrire du code qui fait ce qui est demande sans dépasser les contraintes temps/budget, c'est beaucoup plus important que la couleur de la cravate du consultant (qui n'en n'a même pas, d'ailleurs).
[^] # Re: Piscine
Posté par rakoo (site web personnel) . En réponse au journal François Hollande visite 42, non mais allô quoi.... Évalué à 6.
Il serait peut-être judicieux de se renseigner un minimum, non ?
La notation se passe en 2 temps:
Première étape, la Moulinette et sa copine la Norminette: cette dernière vérifié juste des trucs bêtes comme la syntaxe, si les fichiers ont le bon nom, s'ils sont dans le bon dossier, bref, s'il respecte les normes, si ça passe pas c'est 0. Si ça passe, le code est compile puis teste, si ça passe pas, c'est 0. Ça ressemble pas mal a ce qui peut être attendu de toi en entreprise (un code qui fait pas ce qu'on lui demande, voire qui le fait mal, c'est direct des problèmes avec le client ou l'utilisateur et les brouzoufs qui s'enfuient a toute vitesse)
Deuxième étape, la notation par les pairs: ce sont d'autres nageurs qui notent, en groupe, et cette notation est elle-même notée. Je connais pas les détails, mais d’expérience sur des situations similaires ce sont les pairs qui sont toujours les plus critiques.
En bref, pisser du code comme un consultant ne suffira pas, loin de la.
[^] # Re: Avancée notable
Posté par rakoo (site web personnel) . En réponse au journal Tame et OpenBSD. Évalué à 2.
Ça dépend. Je suis de ceux qui pensent qu'une situation exceptionnelle est effectivement exceptionnelle, et que tu n'as donc pas nécessairement le temps/les moyens de nettoyer proprement derrière toi quand un problème survient. Si tu te débrouilles pour qu'un SIGKILL soit la manière normale de fermer ton logiciel (pas de transaction à écrire, pas de fichier à créer/déplacer/supprimer, …), alors tu es prêt pour toutes les situations.
[^] # Re: MUC 2
Posté par rakoo (site web personnel) . En réponse au journal Parlons XMPP - épisode 5 - les discussions de groupe (suite) et les transports. Évalué à 3. Dernière modification le 22 juillet 2015 à 21:27.
Techniquement tout ça c'est possible, le problème c'est qu'en pratique c'est beaucoup moins accessible qu'IRC: déjà il faut trouver quelqu'un qui veut bien l'héberger, je suis sûr que des services existent bien mais là comme ça aucun nom ne me vient en tête. À l'inverse sur IRC le premier réseau qui te vient en tête pour avoir un chan pour ton projet c'est Freenode. Je suis convaincu qu'avec une fédération au niveau des salons de discussion-même (et non pas juste au niveau des serveurs), on pourra voir émerger un réseau communautaire qui hébergera la plupart des salons (un peu comme Freenode), et que ça facilitera la dissémination de XMPP (plus de découvrabilité, plus de visibilité)
# MUC 2
Posté par rakoo (site web personnel) . En réponse au journal Parlons XMPP - épisode 5 - les discussions de groupe (suite) et les transports. Évalué à 3.
Est-ce que tu as plus de détails sur les discussions sur MUC 2 ? J'avais lu la XEP-289, et je l'avais trouvé super intéressante, à mon avis tant que XMPP n'aura pas de salon de discussion qui vont dans ce sens IRC aura encore une bonne raison d'exister, parce que la fédération des serveurs permet d'avoir un endroit où il est plus facile de
Je vois également que tu vas t'intéresser de plus près au côté non-messagerie, qui est effectivement extrêmement important à remonter tant il est sous-exploité, j'ai hâte !
[^] # Re: Avancée notable
Posté par rakoo (site web personnel) . En réponse au journal Tame et OpenBSD. Évalué à 10.
C'est un poil malhonnête comme comparaison: dans
tamele développeur dit ce dont il a besoin et laisse le système gérer les cas d'erreur, alors que dans le cas de Capsicum c'est le développeur qui doit gérer lui même les cas d'erreur. Un truc un peu plus lisible aurait été du genrecaps_ioctls_limitquitte le programme avec une grosse erreur si c'est pas possible. Bon, dit comme ça, on se dit que ça devrait être le boulot de Capsicum d'offrir cette API là, mais bon.[^] # Re: forges
Posté par rakoo (site web personnel) . En réponse au journal SourceForge dans les choux. Évalué à 10.
Plutôt: Si c'est pour une application visant à être populaire, pitié soyez pragmatique et utilisez un format ouvert !
En l'occurrence toutes les données sur Github sont dans un format spécifié et peuvent être récupérées/modifiées individuellement:
Pour moi, Github ne peut pas subir le même sort que Sourceforge parce que tout peut être récupéré et modifié depuis l'extérieur, vu que le format est spécifié. C'est d'ailleurs déjà courant, il y a nombre de services qui interagissent avec cette API. De la même manière que Word a beau être propriétaire, si le format utilisé est ODF, au moins tout le monde peut le parler. Du coup pour moi Github est loin d'être autant le mal qu'on en dit.
[^] # Re: Pas vraiment un problème
Posté par rakoo (site web personnel) . En réponse au journal Facebook sauce XMPP est mort. Évalué à 3.
Je sais que tu aimes le coté fédération qui est si cher a XMPP, mais pour moi
c'estc’était quand même intéressant que Facebook utilise XMPP, pour pouvoir reutiliser tout ce qui se fait cote client qui ne dépend pas du serveur: chiffrement bout-en-bout, Jingle, bots divers, parties de tarot …M'enfin, de toute façon c'est fini tout ça.
[^] # Re: Merci et une question
Posté par rakoo (site web personnel) . En réponse au journal Parlons XMPP - épisode 3 - le cœur et les extensions (suite). Évalué à 4. Dernière modification le 01 juillet 2015 à 23:07.
Les experts confirmeront, mais la visio conf c'est du Jingle, c'est-à-dire que c'est un problème purement client qui ne dépend absolument pas du serveur, puisque ce sont des choses qui se négocient de client à client; ça ne concerne donc pas prosody !
(Bon en réalité, pour ce qui est transport dans Jingle, typiquement la connexion directe de client à client ne marche pas, il vaut mieux passer par un tiers, comme par exemple un proxy SOCKS5. Ça tombe bien, Prosody peut faire proxy SOCKS5)
Par contre je te rejoins à 100% sur le sujet: si quelqu'un avait un tuto, ça serait super, ne serait-ce que pour se donner un coup de pied dans le derrière et implémenter ça un peu partout !
[^] # Re: Merci et une question
Posté par rakoo (site web personnel) . En réponse au journal Parlons XMPP - épisode 3 - le cœur et les extensions (suite). Évalué à 6.
J'irais même plus loin concernant Prosody: le paquet de base répond déjà a 80% des besoins. S'il manque quelque chose, il y a une très forte chance qu'un module fasse l'affaire. Si c'est encore pas suffisant, en effet il faut soi faire du Lua soit passer par un composant externe. Ce qui en pratique revient a coder. Mais pour un usage "standard", il n'y a absolument pas besoin d'aller jusque la.
Prosody ça juste marche, c'est facile a installer et a utiliser, c'est stable, sans écrire une ligne de lua… Que demander de plus ?
[^] # Re: Autres outils
Posté par rakoo (site web personnel) . En réponse au journal chaintools, outils unix avec syntaxe pythonique. Évalué à 3.
Encore un autre: python-sh
[^] # Re: Protection ?
Posté par rakoo (site web personnel) . En réponse au journal Et dire qu'avec le brevet logiciel on est loin de toucher le fond.. Évalué à 2.
Attention à ne pas confondre dividende universel (quantité d'argent que n'importe quel citoyen reçoit sans condition) et salaire (quantité d'argent que n'importe qui reçoit en récompense de son travail). Les deux ne sont pas incompatibles, bien au contraire. Personne ne prétend remplacer tous les revenus d'argent par le dividende universel; ce dernier peut, tout au plus, suffire à assurer les besoins primaires (logement, nourriture, accès téléphone/internet). Et encore. Pour tout le reste il y a le travail !
[^] # Re: Protection ?
Posté par rakoo (site web personnel) . En réponse au journal Et dire qu'avec le brevet logiciel on est loin de toucher le fond.. Évalué à 2.
Est-ce que tu imagines un organisme gouvernemental qui décide combien donner
Bon, c'est vrai, je connais pas le monde de la recherche, mais j'ai l'impression que si un organisme devait décider combien donner pour chaque "équivalent-brevet", ça serait assez vite le bordel.
Même de manière générale, qu'est-ce qu'un inventeur ? Je doute qu'on puisse effectivement définir un statut qui donne droit à une subvention. Surtout que la plupart des inventeurs aujourd'hui sont des équipes dans des compagnies. Mais pourquoi pas.
Ne pas avoir besoin du statut officiel de chercheur pour pouvoir inventer ? Je pense par exemple aux développeurs open source; tiens, par exemple, Bram Cohen qui a mis au point Bittorrent, il n'est pas chercheur, et pourtant la société devrait pouvoir le remercier.
Idem. À moins d'avoir un moyen super simple et répandu pour transférer de l'argent, ça ne financera pas grand chose à lui tout seul.
Comme dit plus haut, ça pose le problème de définir qui est inventeur, et le problème de "si tu es inventeur, tu ne peux pas être autre chose (ie avoir une autre activité)". C'est pour ça que je suis plutôt en faveur d'un dividende universel, qui laisse l'opportunité à n'importe qui d'inventer… mais ça n'est pas suffisant pour la partie "remerciement".
[^] # Re: Brevets en général
Posté par rakoo (site web personnel) . En réponse au journal Et dire qu'avec le brevet logiciel on est loin de toucher le fond.. Évalué à 2.
Ça tombe bien, je ne fais pas cette réduction.
[^] # Re: Brevets en général
Posté par rakoo (site web personnel) . En réponse au journal Et dire qu'avec le brevet logiciel on est loin de toucher le fond.. Évalué à 2.
Mais justement ! Comme je l'ai dit plus haut, il y aura toujours des éléments mathématiques qui portent le logiciel. Je ne le nie absolument pas. Sauf que les équations sont tout en bas dans la chaîne.
Si un logiciel existe, c'est d'abord pour répondre à un besoin. Ton logiciel qui positionne un outil dans l'espace, tu l'écris pour permettre à un humain de positionner un logiciel dans l'espace. C'est exactement ça qui est protégé par le brevet: un machin qui remplit la fonctionnalité utilisée par des gens.
Et je confirme: répondre à une fonction n'est pas l'application d'une équation, sauf dans des cas très limités. Quand je dis fonction, ici, je parle du besoin des utilisateurs potentiels. Est-ce que tu saurais m'expliquer, concrètement, quelles équations j'applique lorsque:
Aucune de ces fonctionnalités n'a été implémentée comme l'application d'une ou plusieurs équations. Un médicament, qui n'est que l'application des connaissances scientifiques sur les effets de telle ou telle molécule, peut effectivement être vu comme l'application directe d'une "équation" (même si dans ce cas on parlera plutôt de réaction). Dans le cas d'un logiciel, les équations sont loin d'être la raison première de son existence.
[^] # Re: Protection ?
Posté par rakoo (site web personnel) . En réponse au journal Et dire qu'avec le brevet logiciel on est loin de toucher le fond.. Évalué à 4.
Très bonne question, il "suffit" de revenir à la base pour comprendre: un type passe du temps dans son labo, et au bout d'un moment arrive à résoudre un problème humain avec une machine/un procédé. En tant que société on a décidé de le remercier en le payant pour ses efforts.
Sauf qu'au lieu de lui donner de l'argent, ce qui serait une calamité en matière de gestion (tout simplement parce que personne ne sera d'accord sur le "combien"), on part du principe que l'inventeur est aussi un bon industriel, et qu'il va donc vendre son procédé. Pour être sur qu'il le fasse, la société lui assure un monopole sur l'exploitation de son procédé. C'est là qu'est la protection: protection contre la concurrence, limitée dans le temps. Et ça pose un problème majeur: pour que le système marche il faut être un bon industriel (le monopole ne fait pas tout, surtout si l'inventeur part de zéro)
Du coup si on veut vraiment abolir les brevets, il faut revenir aux sources et se demander: comment remercier les inventeurs ? (Je pars du principe qu'on veut bien les remercier, parce qu'on est pas des rats)
Moi je serais plutôt pour un mix des deux, avec un bonus si l'inventeur ne brevète pas mais décide juste de faire un papier (pour prouver l'antécédent), tout en punissant bien les officines de brevets qui ne font pas leur boulot autant que ceux qui ne commercialisent pas le fruit du brevet (si le monopole n'est pas utilisé, il doit y avoir sanction et retrait du monopole)
[^] # Re: Protection ?
Posté par rakoo (site web personnel) . En réponse au journal Et dire qu'avec le brevet logiciel on est loin de toucher le fond.. Évalué à 2.
Ya un peu de la même chose en informatique: quelqu'un peut écrire un papier et le diffuser (Google fait beaucoup ça, par exemple avec BigTable). Ce qui est bien c'est que ça montre au futurs breveteurs potentiels qu'il y a de l'état de l'art, et que donc un brevet un peu trop proche serait invalide.
[^] # Re: Brevets en général
Posté par rakoo (site web personnel) . En réponse au journal Et dire qu'avec le brevet logiciel on est loin de toucher le fond.. Évalué à 2.
L'idée, à la base, c'est que l'inventeur commercialise son invention pour se payer la recherche. Le monopole lui assure que la commercialisation marche, et qu'il gagne effectivement de l'argent avec.
Les bénéfices sont là, théoriquement: la société profite de l'invention au travers de la commercialisation des produits finis. Elle n'a juste pas accès à la fabrication, au sens où elle ne peut modifier la machine. Mais elle profite bien de l'invention.
Ça, bien sûr, c'est la théorie, et quand des boîtes s'amusent à garder le monopole sans rien en faire c'est très clairement un abus. De la même manière qu'accepter des brevets vagues, qui englobent beaucoup trop, est un abus.
[^] # Re: Brevets en général
Posté par rakoo (site web personnel) . En réponse au journal Et dire qu'avec le brevet logiciel on est loin de toucher le fond.. Évalué à -1.
Peut-être que dans quelque cas très rares, c'est vrai, mais l'immense majorité des logiciels n'ont pas été créés pour démontrer une équation (ou même en être l'utilisation) mais pour répondre à une fonction. Je crois que tu oublies trop facilement que les logiciels sont d'abord et avant tout faits pour les humains. En ce sens, ils n'ont pas de valeur absolue (comme pourrait l'être une équation, ou sa preuve) mais une valeur relative aux utilisateurs potentiels.
En plus de ça, même si je suis sûr qu'en fouillant suffisamment on trouvera toujours des bouts de maths, un humain ne crée pas un logiciel à partir de ces bouts de maths (c'est quoi les équations qui permettent de faire fonctionner Docker ? c'est quoi les maths qu'il y a derrière Popcorn Time ?). On est beaucoup beaucoup plus haut.
Pour reprendre le parallèle: un atome n'est pas "libre", dans le sens où il n'a pas de droit. Que t'en prenne un ou plusieurs, c'est pareil. Du coup, un humain, qui n'est rien d'autre qu'une masse d'atomes, n'a pas de liberté à proprement dire. J'ai bon ?
La composante humaine est centrale dans le logiciel (ça a été fait par un humain, pour un humain), c'est pour ça que tu peux pas réduire un logiciel aux maths qu'il y a derrière.
Attention, ne me fais pas dire ce que je n'ai pas dit :)
Les brevets défendent l'acte d'invention par l'inventeur. Et si on regarde bien, ça défend surtout l'inventeur lui-même, contre les gros qui pourraient utiliser le fruit de son travail pour s'enrichir sans que l'inventeur n'en bénéficie (en tout cas, c'est le projet initial). Les brevets ne défendent pas l'invention en général, ou l'innovation, bien au contraire même (ça, c'est aujourd'hui).
[^] # Re: Brevets en général
Posté par rakoo (site web personnel) . En réponse au journal Et dire qu'avec le brevet logiciel on est loin de toucher le fond.. Évalué à 3.
Pas d'accord, ce raisonnement est tout simplement fallacieux, pour 2 raisons:
Un logiciel n'est pas une équation
Une équation décrit un phénomène naturel, c'est à dire un phénomène qui existe en dehors de son observation. Les équations de Maxwell définissent comment la lumière se comporte, sans aucune considération pour ceux qui connaissent ces équations.
Un logiciel est l'application d'un algorithme. Un algorithme, ça reste encore un peu "naturel", dans le sens où ça ne dépend pas vraiment des observateurs; son application, par contre, est totalement centrée sur les utilisateurs de cet algorithme. Un logiciel est entièrement conçu pour des humains, il ne sort pas de nulle part et ne décrit absolument rien en soi. C'est un outil, pas une description.
Les brevets défendent l'invention
Et justement, comme tous les outils, il y a quelqu'un (une personne ou un groupe) qui est parvenue à trouver comment réaliser cet outil. C'est exactement ça qui est protégé par un brevet. C'est pour ça que ça n'aurait pas beaucoup de sens de breveter les équations de Maxwell (puisqu'elles permettent de décrire) mais ça a du sens de breveter un machin qui permet de résoudre un problème (puisque c'est un outil, qui à priori a couté du temps et de l'argent à son inventeur). D'ailleurs le nom qu'on utilise c'est procédé.
Alors bien sûr la vision du brevet logiciel (voire même du brevet tout court) aujourd'hui est complètement différente de la vision originelle: les brevets ne servent plus à d'abord faire avancer la société avec comme side-effect d'assurer un revenu à l'inventeur, ils servent d'abord à assurer les revenus à l'inventeur, et ce au détriment de la société. Pour autant, c'est pas une raison pour déformer les faits.
Dire que "les logiciels sont des équations donc non-brevetables" est aussi faux que dire "les humains ne sont qu'une masse d'atomes sans vie donc non-tuable, le meurtre ne doit donc pas être interdit". Un raccourci faux qui mène à une conclusion fausse.
# Erreur
Posté par rakoo (site web personnel) . En réponse au journal Les solutions cryptographiques aujourd'hui : le simple et le compliqué. Évalué à 5.
OTR, le protocole de forward secrecy, n'est pas utilisé par TextSecure, comme tu le dis toi-même; ils utilisent leur propre protocole (Axolotl) qui permet d'être réellement asynchrone (ie envoyer des messages même quand l'autre n'est pas connecté), ce qui permet d'ailleurs d'avoir un support pour la discussion de groupe simple contrairement à mpOTR qui galère comme pas possible.
Seul problème: c'est encore pas répandu. J'ai une entrée dans ma TODO-list pour voir comment utiliser XMPP avec, mais comme ma TODO-list fait 200km de long…