Paf a écrit 114 commentaires

  • [^] # Re: Travail sur soi

    Posté par . En réponse au journal Changement de carrière.. Évalué à 2.

    N'etant qu'un etranger d'Internet, il est difficile de donner des conseils avec precisions.

    Ceci dit, si le probleme n'est pas avec le boulot, changer non seulement de boulot mais aussi de domaine rajoute un gros risque.
    Avec ta position actuelle, tu es deja familier avec les differents acteurs, les responsabilites, tu sais quoi faire en cas d'urgence. Avec un nouveau domaine, tout sera a re-apprendre et risque de generer encore plus de stress.

    Donc avant de completement changer de boulot, mon conseille serait d'evaluer quels sont les risques que tu mentionnes et comment simplifier ta vie afin de te donner plus d'espace pour que tu puisses addresser tes problemes:

    • Si tu te sens frustre par le fait de te prendre les consequences d'actions d'autres personnes, parles en avec ton manager. Il doit y avoir des considerations que soit toi, soit ces personnes n'avaient eu vent
    • Deplace ton energie creative ailleurs. Sur quelque chose que tu controles completement (ex: projet perso ou autre)
    • Simplifies ta vie privee. Si cela signifie que tu dois te faire delivrer des plats prepares ou aller au restaurant, fais le.
    • Simplifies les taches menageres.
    • Tu n'as pas pris de vacances. Prends en, meme si c'est pour rester a la maison.
    • Prepares les choses en avance afin de ne pas avoir a reflechir et simplifier les choses. Fais meme un calendrier pour ca.
  • [^] # Re: Alternatives

    Posté par . En réponse au journal Elastic fait fermer les dépôts SearchGuard sur GitHub. Évalué à 2.

    Tout a fait! Et c'est l'un des gros avantages de l'ASF!
    Ceci dit l'ASF n'est pas completement immunise contre ce genre de tactiques. Voir par exemple tous les coups bas entre les differentes boites liees au big data et comment ils ont fait le forcing pour enlever la clause de diversite pour la graduation de l'incubateur.

  • [^] # Re: Alternatives

    Posté par . En réponse au journal Elastic fait fermer les dépôts SearchGuard sur GitHub. Évalué à 3.

    influxdb-relay est quelque chose d'autre.
    Voir https://www.influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/ pour plus de details. Mais en gros:

    Next week we’ll be cutting the first release candidate for the 0.11.0 release. While this release includes significant improvements in the query engine and the clustering code base, it will be the last open source version that includes clustering. In April, we’ll release 0.12.0, which will be fully open source and have great new features, but it will be focused on the standalone InfluxDB server. Both of these will be drop in replacements for the current stable 0.10.3 release.

    For our users looking for free open source options, we’ll be releasing the open source InfluxDB Relay project along with a landing page how to achieve high availability using pure open source and subscription options with the 0.12.0 releases and beyond. From that point forward our clustering efforts will be focused on the closed source Influx Enterprise offering.

    Dans les projets libres que je recommande, je ne regarde pas juste la license du logiciel mais aussi si il y a une communaute autour. Un logiciel libre pousse par une boite sans communaute se rapproche plus d'un shareware que d'un logiciel dans l'esprit du libre. Et note que c'est voulu et admis (de facon semi-ouverte) par la plupart de ces boites.
    Et pour rappel, voici ce qu'a dit le CEO de mongodb recemment:

    [W]e didn't open source it to get help from the community, to make the product better. We open sourced as a freemium strategy; to drive adoption.

    La plupart de ces boites veulent beneficier de l'aura positive des logiciel libres sans pour autant s'y investir completement. Realistiquement, ells vont mettre des barrieres a la contribution tiers.

    En tant qu'utilisateur, je veux m'assurer les que les interets des utilisateurs passe en premier pour eviter que d'autres ennuis comme le clustering d'influxdb ne m'arrive. Je veux aussi pouvoir contribuer de facon positive au projet si necessaire et meme beneficier du choix de plusieurs fournisseurs de services si necessaire. Et c'est bien pour ca aussi que le motto non-officiel de l'ASF est "community over code".

  • [^] # Re: Oss

    Posté par . En réponse au journal Elastic fait fermer les dépôts SearchGuard sur GitHub. Évalué à 2.

    Si on prend le cas d'elasticsearch, cela reste tres problematique combien meme le coeur est libre:
    Ils ont tout mis dans le meme depot git, que ce soit la partie libre ou la partie pas libre. Du coup ce qui se passe dedans n'est pas forcement clair (ex: si je construit un tar, comment ca se passe?) mais cela rend plus complique toute contribution (ex: j'ai du code a contribute mais ca risque de casser une de leur partie proprio or entre en concurrent).
    De meme il n'y a pas vraiment de communaute de developpeurs pour elasticsearch, seulement des utilisateurs. Note: Avoir une visibilite dans les tickets et pr du repository ne compte pas vraiment comme communaute.

  • [^] # Re: Alternatives

    Posté par . En réponse au journal Elastic fait fermer les dépôts SearchGuard sur GitHub. Évalué à 5.

    Chronograf est un autre product open core, que je ne compterai pas dans la categorie libre. Pour rappel, les gars d'influxdata, qui sont derriere chronograf, sont les memes qui ont enleve tout code lie au clustering d'influxdb pour le rendre proprietaire et rabaisser le coeur libre.

    Elasticsearch n'est que l'enrobage de la bibliotheque Apache Lucene dans un service distribute. Donc on peut arriver a la meme chose avec Apache Solr qu'Elasticsearch. L'avantage d'elasticsearch est qu'il a ete longtemps l'outil le plus facile a deployer et a integrer avec des connecteurs pour tout ce qui est a la mode et le fait que l'on pouvait envoyer des documents sans avoir a definir de schema au prealable. Apache Solr Cloud s'est pas mal ameliore en terme de facilite d'utilisation depuis.
    D'ailleurs pour tous mes prochain projets, je vais regarder en premier Apache Solr.

  • [^] # Re: Code source

    Posté par . En réponse au journal Mobicoop, une alternative « libre » à Blablacar. Évalué à 4. Dernière modification le 22/03/19 à 22:13.

    Le Mossieur a quand meme une bonne remarque sur ce point.

    Ce journal et les commentaires defendant mobiscoop mettent beaucoup en avant le fait que ce soit libre, que cela tente de minimiser les couts et avoir un systeme plus humain. Le tout s'opposant a blablacar en evoquant l'argent et autres symboles associes.
    Le fait que le code ne soit qu'open core et que ce soit proprietaire en dual license n'est pas du tout en accord avec les valeurs affichees abondamment par mobiscoop.
    Si mobiscoop veut etablir un systeme en accord avec ses valeurs affichees, faire du proprietaire y va a l'encontre. Permettre aux gens d'avoir et heberger leur propre version ne peut qu'aller dans le sens de ces valeurs (ex: avoir une instance a l'echelle d'une boite pour aider et encourager les employes a faire du covoiturage). Le proprietaire n'a de sense que dans un contexte ou on essaie de rendre les utilisateurs captifs afin de maximiser le profit.

    D'un point de vu potentiel contributeur, cette situation actuelle me fait fuir et eviter de toucher au code a ce projet car du point de vu license c'est le bordel:
    * Il y a un badge de license AGPLv3. Cool, ca a l'air d'etre libre
    * Je regarde la license https://gitlab.com/mobicoop/mobicoop/blob/dev/LICENSE et ca a l'air d'etre la license standard pour l'AGPLv3.
    * La license specifiee dans https://gitlab.com/mobicoop/mobicoop/blob/dev/package.json#L42 indique aussi GPLv3. Donc pour le moment, pas de proprio
    * Je vais sur leur doc referencee sur leur README.md ( https://mobicoop.gitlab.io/mobicoop/#/ ) et voir tout en bas:

    Mobicoop software is owned by Mobicoop cooperative. Mobicoop cooperative is opened to any individual, company or public authority who >wish to become a shareholder.
    In order to increase the impact of our platform to any sort of clients whatever type of contractual relationship they require, Mobicoop software >is dual-licensed:
    - AGPL-3
    - proprietary software

    Since Mobicoop is dual licensed AGPLv3/proprietary, all components used for Mobicoop must be compatible with both licenses. As a consequence, all components integrated into Mobicoop source code must be released with a permissive open source license. More information on license compatibility for software components and content components (Creative Commons issues).

    Mobicoop CI process includes a License Management which checks the license of all components part of a merge request. The most common permissive licenses have already been added to the approved licenses list of this License Management process.
    In case you have one of the following situation while merging, please get in touch with Mobicoop project licensing issues expert before merging:
    - one of the license pops up as non part of the approved license for the project
    - a component is license under AGPLv3 and is not Mobicoop itself

    Donc ce n'est pas AGPLv3 en fait? Ou se trouve cette autre license proprietaire?

    /**
    * Copyright (c) 2018, MOBICOOP. All rights reserved.
    * This project is dual licensed under AGPL and proprietary licence.


    • This program is free software: you can redistribute it and/or modify
    • it under the terms of the GNU Affero General Public License as
    • published by the Free Software Foundation, either version 3 of the
    • License, or (at your option) any later version. *
    • This program is distributed in the hope that it will be useful,
    • but WITHOUT ANY WARRANTY; without even the implied warranty of
    • MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
    • GNU Affero General Public License for more details. *
    • You should have received a copy of the GNU Affero General Public License
    • along with this program. If not, see . ***************************
    • Licence MOBICOOP described in the file
    • LICENSE **************************/

    Donc ca dit que c'est AGPLv3 ET proprietaire. Mais la encore cette license proprietaire n'est definie nul part. De meme je n'ai vu nul part de Contributor License Agreement (CLA ou son equivalent francais). J'ai aussi regarde quelques merge requests au cas il y a une verification du fait que chaque contributeur donne une license perpetuelle proprietaire a la boite derriere mobicoop, mais je n'ai rien trouve de tel.

    Donc au final, je leur souhaite de reussir mais aussi:
    * Je serais curieux de comprendre la difference de raisonnement pour le cote proprietaire du code. Je n'ai pas trouve d'explication sur le site
    * Je leur conseille de se renseigner plus sur les licenses proprietaires vu qu'en l'etat cela ne me semble pas applicable. Voir a titre d'exemple https://www.elastic.co/contributor-agreement ou https://www.ubuntu.com/legal/contributors ou encore https://www.clahub.com/ . Ceci dit je suis loin d'etre un avocat et tres loin d'etre fan des projets libres qui me demandent le droit d'utiliser mes contributions pour leurs produits proprietaires.

  • [^] # Re: Community over code

    Posté par . En réponse au lien Elastic Search préforké. Évalué à 3. Dernière modification le 14/03/19 à 09:36.

    Il faut tout d'abord separer les differents problemes.

    En premier lieu, je ne pense pas que ce soit un bon echange de sacrifier sa liberte pour du code. Si moi ou AWS ne peuvent fournir un service d'hebergement d'elasticsearch, ce n'est pas libre. Donc je ne vois rien de mal a avoir AWS ou autre fournir un tel service d'hebergement.
    Ce serait aussi injuste vis a vis des autres projets qui sont au coeur d'Elasticsearch comme netty ou apache lucene. Elastic devrait les remunerer.
    Tout ca me rappelle d'ailleurs ce qu'ecrivait RMS il y a presque 30ans: https://www.albertopettarin.it/fsfs2/fsfs2.xhtml#x1-590006

    Par ailleurs, AWS l'a demontre avec mongodb: si ca vaut le coup, ils developperont une facade pour supporter le protocole de mongodb sans utiliser une seule ligne de code de mongodb. Donc ca ne protege en rien elastic.

    Donc que peut faire Elastic? Ils peuvent se congratuler! Ils sont devenus si populaire et gros qu'AWS leur paie attention. Ensuite ils peuvent accepter qu'Elasticsearch est devenue une commodite. Se fermer et se replier serait une erreur car la communaute l'abandonnerait au profit du fork le plus accueillant (ou Apache Solr) et ne ferait que renforcer sa competition. A la place:

    • S'ouvrir plus et accepter qu'Elasticsearch est une commodite. Mine de rien Elastic a le plus de contributeurs sur le projet, ce qui lui donne le plus d'influence. Ils baissent la barre pour contibuer a Elasticsearch et ainsi rendre le developpement trop gros/rapide pour un fork.

    • Redoubler d'efforts sur l'hebergement. Il y a plusieurs opportunites qu'AWS ne pourra jamais supporter comme cross-cloud federation. Ils peuvent aussi s'etendre horizontalement (comme une plateforme) ou verticalement (plutot cote applicatif comme ils ont tente avec un APM). Faciliter son integration avec les domaines en poupes comme le deep learning (ex: tres utile pour chercher a base de vecteur) ou IoT. S'assurer aussi d'une bonne integration avec les bibliotheques et cadres populaires (spring, react, ruby, etc.)

    • Monter au prochain niveau d'abstraction avec une strategie open core. Etablir une separation claire et nette entre la commodite (elasticsearch) et la partie proprietaire qui sera au dessus. Ca permet de non seulement garder la communaute, mais de l'etendre tout en beneficiant de ses avancees

    • Reduire le pouvoir d'AWS avec un investissement dans les technologies cloud agnostic. Genre s'assurer une bonne integration avec Kubernetes

    Quant au financenent en general, c'est assez vague. Mais si elasticsearch n'existait pas, tout le monde utiliserait Apache Solr :)
    La difference de popularite s'explique surtout a la facilite d'utilisation d'elasticsearch a mon avis.

    Un gros facteur ici est le fait qu'Elastic a recu pas mal d'investissements, ce qui rajoute pas mal de pression pour des retours.

    Un autre example serait aussi de regarder et s'inspirer d'autres gros projets qui ont beaucoup de succes et ont du developpement finance par plusieurs entreprises:

    • Gnome
    • Apache Spark
    • Apache Flink
    • Apache Kafka
    • Apache Hadoop ecosysteme
    • Apache Lucene
    • Nextcloud
  • [^] # Re: Community over code

    Posté par . En réponse au lien Elastic Search préforké. Évalué à 2.

    Et c'est un probleme?

    Il y avait la meme question lorsqu'Oracle voulait donner OpenOffice a la fondation Apache. Il existait deja LibreOffice et la reputation d'Oracle n'etait pas franchement bonne. Donc c'etait quoi l'interet de jouer le jeu et de l'accepter?

    La position de l'ASF est que ce n'est pas un investisseur ou ne specule pas sur les projets. Ils ne font que fournir un cocon pour aider les projets a se gerer. Donc ils ne vont pas juger en se basant sur les chances de success.

    L'interet est que l'on se retrouve avec le choix:

    • l'ASF refuse et ne fait rien -> Le code source n'est jamais libere et disparait
    • l'ASF accepte mais il n'y pas vraiment de communaute qui se forme -> On archive le projet mais l'ASF a toujours les droits et le code est toujours dispo sous license libre. Voir https://attic.apache.org/ pour les projets archives
    • l'ASF accepte et une communaute se construit autour du projet -> Tout va bien, on a un projet vibrant et libre

    Et du point de vus succes, la fondation Apache n'a rien d'une poubelle. Rien que le poids financier des projets genre Apache Hadoop/hbase/spark/mesos/flink/lucene/solr/camel se compte en millards de dollars. Ou je pourrais aussi mentioner l'impacte que d'autres projets ont sur l'ecosysteme entier comme Apache Httpd, Maven, ivy, commons, groovy

  • [^] # Community over code

    Posté par . En réponse au lien Elastic Search préforké. Évalué à 3. Dernière modification le 12/03/19 à 23:46.

    Je pense que cette situation est le resultat d'une communaute qui n'est pas saine et ne remet pas en cause le financement de projets libres.
    D'autant plus qu'Elastic a aussi un service d'hebergement pour Elasticsearch qui se porte plutot bien.

    Le probleme ici est que Elastic a un controle total sur le projet et qu'ils ont commence a en profiter pour leur avantage, au detriment du projet lui-meme et de sa communaute.

    Ce n'est pas la premiere fois et ce ne sera pas la derniere fois non plus. Voir entre autre:

    • Oracle et OpenOffice
    • Oracle et Hudson
    • Oracle et Java
    • InfluxDB et les fonctionnalites qu'ils ont enleve dans le code libre pour le garder seulement dans leur version proprietaire

    Parfois ca passe, parfois ca fork ou parfois le projet se meurt.
    En general cela repose sur le fait que la partie libre n'est qu'une version shareware deguisee. C'est tres bien pour experimenter et meme avoir des contributions externes (avec attribution a la boite derriere le projet bien entendu, au cas ou ils veulent changer la license…), mais il faut soit passer a la caisse quand on veut passer en production ou avoir la capacite technique de le faire soi-meme (et qui a un certain cout).
    Si l'on rajoute a ca le fait que tout ce qui irait a l'encontre de la boite derriere le projet serait rejete ou rendu impossible, la situation actuelle n'est pas vraiment ideale pour un ecosysteme libre et sain.

    Donc le fait qu'AWS pousse vers une remise a niveau n'est pas un mal en soit. C'est une opportunite de rendre le projet plus libre. J'imagine qu'a ce niveau, soit Elastic reste tetu est essaye de resister, soit ils coupent l'herbe sous le pied d'AWS et donnent le projet a l'ASF ou il deviendra plus neutre.

    Faire rentrer le projet a l'ASF serait vraiment bien. Il ne peut pas y avoir de co-opetition si les acteurs ne sont pas au meme niveau et c'est exactement ce que fournit la fondation Apache. D'ailleurs on entend souvent "community over code" pour souligner le fait qu'avoir une communaute saine est beaucoup plus important que le code.
    Et meme si ce n'est pas parfait, ils ont fait un bon boulot. On peut voir plusieurs entreprises supportant Apache Hadoop, plusieurs entreprises derriere Apache Lucene et Solr et se portent toutes tres bien.

    Donc non, le fait que le createur d'Elasticsearch bosse a Elastic ne donne pas le droit a Elastic d'etablir une rente a vie sur du logiciel libre.

  • [^] # Re: Deux interprétations

    Posté par . En réponse au journal [bookmark] Privacy Shield subira-t-il le sort de Safe Harbor ?. Évalué à 2. Dernière modification le 08/10/17 à 23:54.

    Sur le fond, honnêtement, je ne comprends pas pourquoi les grosses boîtes ont un besoin essentiel de faire traverser l'Atlantique aux données personnelles des citoyens européens. C'est quand même une bulle ce truc, tout le monde semble être prêt à payer des bases de données personnelles à des sommes faramineuses, mais sur le fond, est-ce qu'une seule boîte a jamais réussi à faire une quelconque marge dessus?

    Les donnees des utilisateurs ne traversent pas l'atlantique dans le but unique de pouvoir revendre les donnees. Il y a aussi l'aspect pratique et technique.
    Ne pas avoir a se soucier du pays d'origine des utilisateurs (Internet sans frontieres!) permet d'eviter tout un tas de problemes techniques tels que:

    • Federation (ou solution similaire) des comptes et services.
    • Gestion de l'exploitation/infrastructure plus lourde et compliquee
    • Deploiements plus compliques
    • BI/Data analysis plus compliques vu qu'il y a maintenant differents points de collection avec differentes politiques de traitement
    • Rassembler toutes les donnees sous une forme acceptable pour qu'elles puissent etre envoyees aux utilisateurs qui les demandent et offrir la possibilite de les rectifier.

    Donc a moins que ne ce ne soit un besoin fortement exprime par les utilisateurs ou une contrainte imposee par la loi, les boites n'ont pas vraiment de raison de separer les donnees par continent/pays.

  • [^] # Re: des pistes

    Posté par . En réponse au message Publication d'une application libre : comment faire avec des bibliothèques et des dépendances ?. Évalué à 2.

    Je recommande quand même la même chose d'un point de vu général pour faciliter les contributions. Et aussi d'avoir un readme à la racine de ton dépôt avec un lien vers le site et les instructions de construction.

    Du point de vu légal je n'ai rien a rajouter. Il faudrait lister et voir toutes les licences de tes dépendances.

  • [^] # Re: des pistes

    Posté par . En réponse au message Publication d'une application libre : comment faire avec des bibliothèques et des dépendances ?. Évalué à 2. Dernière modification le 28/02/17 à 07:22.

    si tu n'utilisais pas play, j'aurais recommendé Apache Maven ou gradle (perso hé préfère Apache Maven) pour gérer ton projet.

  • # des pistes

    Posté par . En réponse au message Publication d'une application libre : comment faire avec des bibliothèques et des dépendances ?. Évalué à 2.

    Ce que je recommenderai:
    * regarde du côté de https://www.playframework.com/documentation/2.5.x/Deploying pour construire une archive de déploiement avec les dépendances.
    * automatiser le build et les tests. Il y a travis ou circle ci qui fournissent des services de construction gratuits pour les projets libre. Sinon gitlab fournit des cela aussi. Cela à plusieurs avantages, notamment l'assurance de savoir que ton projet puisse être construit pars des contributeurs et de savoir quand un commit casse la construction ou des tests.

    Après pour aller plus loin, voir :
    * scripts de déploiements pour les différents services. Par exemple ansible ou puppet
    * images docker et/ou intégration avec kubernetes. Mais pas tout le monde utilisé pas encore.

  • [^] # Re: La version officielle

    Posté par . En réponse au journal Cozy cloud, maif et licenciement du CTO???. Évalué à 7.

    La différence se trouve principalement que l’intérêt d'une boite n'est pas nécessairement le même que celui de la communauté et qu'elle a aussi un poids surdimensionne dans les décisions.
    Même si GNOME ou systemd ont pris des décisions que l'on apprécie pas, elles ont toutes ou presque été faites a la suite de discussions et/ou votes (ex: https://lists.debian.org/debian-ctte/2014/02/msg00294.html ). Par ailleurs les décisions ont ete prise avec pour objectif le bien être du projet/communauté et non pas celui d'un unique membre de la communauté.

    Tu ne verras jamais GNOME ou systemd enlever des parties du projet afin de les rendre propriétaires pour rendre les utilisateurs dépendant et prévenir d'autres boites de fournir des services dessus comme cela a été fait pour influxdb ( voir https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/ ) ou les tests dans certains autres projets libres.
    Tu ne les verras jamais aussi bloquer les contributions aux projets car cela peut nuire a leurs bénéfices de leurs autres produits proprietaires ou donner certains avantages a leur compétition.

    Donc au final concentrer les gens avec les droits de commit peut donner un certain pouvoir qui peut être abusé. Ce n'est pas forcement le cas de toutes les boites, mais la diversité des développeurs et/ou la politique affichée de la boite derrière un projet sont des critères qui aident a mitiger ce risque.

  • [^] # Re: La version officielle

    Posté par . En réponse au journal Cozy cloud, maif et licenciement du CTO???. Évalué à 4. Dernière modification le 20/07/16 à 21:30.

    Si le projet m’intéresse et qu'une des entités concentre une majeure partie des développeurs, oui ça peut m’intéresser car cela peut introduire un risque pour moi.

    Je suis aussi convaincu que ces entités souhaitent encore avoir des utilisateurs, seulement je ne suis pas sur de toujours faire parti du groupe qu'elles souhaitent avoir, surtout si je ne paye pas.
    Lorsque l'on concentre la majeure partie des développeurs dans une même boite, il est très tentant de saisir l’opportunité pour en contrôler son développement et éliminer la concurrence pour le bénéfice de la boite et au détriment de la communauté.

    Note: Juste pour être bien clair, cela ne vise pas cozycloud. Je trouve au contraire que cozycloud a été exemplaire.

  • [^] # Re: Loganalyzer

    Posté par . En réponse au message Logiciel de supervision de log KISS, avec remontée d'alerte. Évalué à 1.

    Logstash est très beau mais c'est tout ce qu'il y a de moins KISS (charge CPU et MEM importante). Pas adapté à une petite structure.

    Pour la partie analyse ou remontee de logs?
    As-tu essaye lumberjack pour la remontee de logs?

  • [^] # Re: systeme de monitoring

    Posté par . En réponse au message Logiciel de supervision de log KISS, avec remontée d'alerte. Évalué à 1.

    On utilisait fut en temps logstash -> elasticsearch.
    Mais logstash avait du mal a suivre la charge. Apache Flume s'en sortait beaucoup mieux (du genre 10x mieux). Du coup on utilise maintenant Apache Flume avec morphlines qui envoie le tout dans un cluster elasticsearch.
    Concernant les alertes on se dirige vers des alertes nagios qui font des requetes sur elasticsearch et alertent en fonction.

  • [^] # Re: La France ce n'est pas les USA

    Posté par . En réponse au journal Aller bosser à San Francisco. Évalué à 1.

    Du genre?
    Il y a moult choses a faire dans le sud de la baie.

  • [^] # Re: La France ce n'est pas les USA

    Posté par . En réponse au journal Aller bosser à San Francisco. Évalué à 1.

    Trou paume, trou paume… c'est quand meme pas si paume que ca entre Palo Alto, Mountain View et San Jose :)

  • [^] # Re: rigolade

    Posté par . En réponse au journal Entretiens du nouveau monde industriel 2012. Évalué à 5.

    Je viens de voir la video en question et je suis decu. Les idees ne sont pas si betes que ca. Elles repondent a un besoin.
    C'est pas comme si twitter et instagram sont completement innovantes et geniales.

  • [^] # Re: Pour le lancement du jar

    Posté par . En réponse au journal Write once, run anywhere qu'il disait. Évalué à 5.

    Ca peut aussi aider a traquer le pid si besoin est.

  • [^] # Re: Super

    Posté par . En réponse à la dépêche Wikidata : Wikipedia comme une base de données. Évalué à 2.

    http://www.freebase.com/view/people/views/person
    Ensuite dans filter: "Date of birth value is 1952"
    Et hop on peut afficher tout ca sous forme de table, carte, timeline et meme l'export sous son format favoris.

    Freebase est quand meme le wikipedia des donnees. A noter que les dumps sont disponibles :)

  • [^] # Re: Kouakece ?

    Posté par . En réponse au journal Un AppStore est-il viable pour une distribution Linux ?. Évalué à 1.

    Note que ce n'est pas aussi complique ou misereux que ce qui est laisse entendre. Loin de la.

  • [^] # Re: un fichier pour les gouverner tous... mon precieux....

    Posté par . En réponse au message Installateur packaging. Évalué à 2.

    Si tu veux faire des paquets:
    * Chaque distribution a ses regles de paquetage. Pour fedora, voir par exemple https://fedoraproject.org/wiki/Packaging:Guidelines et https://fedoraproject.org/wiki/Packaging:Java
    * Regarde du cote de https://build.opensuse.org/ qui te fourni un service gratuitement pour faire des paquets pour les distributions GNU/Linux les plus connues
    * Pour gerer ton projet, je te conseille de regarder du cote de maven :)
    * le jre ne doit pas etre dans les dependances. Ton paquet dependra sur un truc du genre "Requires: java".
    * Les distributions GNU/Linux fournissent au moins openJDK. Donc je ne me soucierai pas trop de la presence ou non de la JRE.

  • [^] # Re: Kouakece ?

    Posté par . En réponse au journal Un AppStore est-il viable pour une distribution Linux ?. Évalué à -1.

    Dans le pire des cas weboob-havesex n'est pas dans les depots par defaut. Mais cela ne les empeche pas de le fournir via des depots alternatifs.
    Tout comme Amazon et autres ont des depots alternatifs a android.

    Alors que dans le cas d'Apple, si ils te refusent, tu ne pourras rien distribuer du tout, que je sache.