qui suggère assez explicitement que tu peux faire exprès de ne pas améliorer le logiciel (voire pire, de faire exprès d'y introduire de la complexité) pour sauvegarder ton espace vital. Ce qui me semble malsain.
Oui l'étape d'après c'est d'obfuscer le code de ton jeu pour rendre le travail des autres moins simple. Oh wait ;)
Je ne parlais pas de cynogen ni de XDA en particulier. Mon expérience est peut être biaisée ayant regardé pour des appareils ne pouvant pas faire tourner cyanogen mais en gros ca se résumait à des neuneus, qui peuvent être très bons au passage, qui publient des binaires sortis dont ne sait où, faisant on ne sait quoi, basé eux même sur des binaires sortis dont ne sait où, faisant on ne sait quoi, basé eux même etc. Et pour uploader les binaires ? Bha un binaire sorti dont ne sait où, hébergé n'importe où et qui n'a jamais la même signature. Chaque forum à son neuneu star pour chaque device. Et tu as l'opportunité d'avoir une star par pays en plus par ce que faut bien son quart d'heure de gloire en repackagant son mod bidouillé !
Franchement du peu que j'en ai vu, c'est aussi pathétique que le milieu de la sécurité d'il y a 10+ ans. Des gamins, des neuneus et pas mal de monde avec de sérieux problème psychologiques.
Après peut être que cyanogen est super pro et fait du soft correctement… Mais le lien donée par Tankey résume exactement mon ressenti.
Et en pratique y'a quoi comme applis correctes qui marchent pour de vrai ?
C'est une vraie question la dernière fois que j'ai été y faire un tour je suis rentré bredouille vu la qualité des trucs. Même pour un bloc note à la con…
Je ne suis pas du tout dans le mobile pour deux sous mais c'est effectivement l'impression que j'ai eu la dernière fois que j'ai eu à rooter un téléphone et mettre une ROM custom.
Tout le monde utilise des ROM sorties dont ne sait où, avec un lien sur un forum qui pointe vers fileshare qui assemble 10 modules dont personne n'a jamais vu les sources ou un gestionaire de version. Sans compter les outils qui vont autour. Mais c'est de la balle hein…
Je suis certain que si on voyait la gueule des patchs on rigolerait peut être moins que ca soit intentionnel où juste du jean kevin.
Un service irréprochable, ce qui permet de l'avoir, c'est aussi la connaissance sur le bout des doigts de ton code et ça le créateur du code aura souvent une longueur d'avance.
Un longueur d'avance sur quoi ? Le prochain add-on libre disponible publiquement ? T'es super avancé ca rentre toujours pas de pognon !
Avec du soft grand publique sans besoin particulier tu n'as à priori que trois facon de financer:
- barrière à l'entrée: tu demandes de l'argent pour publier ton travail
- abonnement: Si tout est libre ta plus value c'est 0 et quelqu'un le fera pour moins cher que toi. Au mieux l'abonnement ca sera une plateforme qui le gérera et toi tu récupéras un % (musique par exemple). Mais si c'est libre pourquoi la plateforme te remunerait. Le rapport de force me semble très incertain.
- achat du produit/don: là il faut compter sur la bonne volonté des gens. Ca risque de marcher pour les premiers, savoir si ca se généralise j'ai comme un doute.
Bref rien n'est impossible. Mais avant de financer un vrai jeu et que ca soit reproductible va falloir réfléchir un peu.
Tiens, ça ressemble cruellement aux "attaques" sur le libre dans tous les autres domaines…
Choupinet je suis pas un lapin de deux semaines et tu peux éviter de me sortir ta réthorique usuelle à moi ?
Ce que tu vends comme service, c'est par exemples des évolutions (qui pourraient bien être financée par du financement participatif, par exemple).
Donc c'est pas un service en tant que tel que tu vends. C'est juste un financement d'un dev à l'avance avant de publier le code avec une condition que tu ne publies pas tant que tes pas rentré dans tes frais…
Sinon c'est juste voué à l'échec dès que ton code est sorti et que les gens peuvent l'avoir gratos ils le feront. Une fois publié tu n'as plus aucune plus value possible avec ton savoir faire. C'est exactement le problème de la musique et du cinema et le problème n'a pas l'air si évident que ca à résoudre.
Ca ne veut pas dire que ca ne marchera pas pour quelques uns ou qu'il n'y a pas beaucoup d'autres idées à creuser. Mais que le commentaire original me semble être une vision très très simpliste.
Tiens, ça ressemble cruellement aux "attaques" sur le libre dans tous les autres domaines… (oui, je me répète).
Les pieds sur terre je les ai peut être aussi pour avoir fait pendant 6 ans du dev libre et avoir une idée des coûts dans le soft. Quand tu sors du petit soft développé par un freelance dans son coin, le pognon à un moment il faut le rentrer.
Il y a plein de chose à expérimenter mais dire que c'est simple et que ce qui va marcher une fois par ce que t'es tout seul à le faire se généralisera…
Le seul truc c'est que pour "vendre" le service doit être irréprochable.
C'est quoi le service dans le jeu vidéo ?
Si par service tu entends l'accès à un serveur pour certain type de jeu, jx'ai un peu un doute que ca couvre tes frais de dev sachant que n'importe qui qui n'a pas ces coûts de dev peut héberger aussi ton truc…
Faut peut être avoir les pieds sur terre des fois.
Depuis Java 5 c'est possible avec un thread par fils. Les flux sont pas selectables mais on peut faire des i/o avec timeout dessus alors on s'en sort.
On pouvait le faire avant avec un bête available() (bon qui lui même était buggé dans certains cas mais j'ai oublié les corner cases depuis le temps et si ils existent toujours).
Tu peux tout mutualiser sur un seul thread. De toute facon quitte a écrire du code complexe que tu vas passer 10 plombes à stabiliser alors que ca devrait être dans le JDK… Il te reste le reaper, mais effectivement ca ne va te poser problème que si tu fork pas mal.
je continue à trouver que c'est un moindre mal par rapport à se retrouver avec un batch qui OOM la JVM et et plante les autres batches
Je suis entièrement d'accord avec ca.
Mon point était juste de tempérer l'enthousiame qui pouvait sembler naïf sur le ProcessBuilder. C'est juste une API de merde qui te masque presque tout ce dont tu as besoin pour faire ton job avec une implémentation bien pourrie aussi.
On arrive à faire des trucs qui marchouillent en lisant tout le code des VM et quand tout va bien. Quand tu forks des processus non controllés sur plusieurs systèmes différents c'est bien plus "rigolo".
Pourquoi je parle de 10-20 ans minimum (et même 50 ans)? Parce que pour moi ça doit être aussi pérenne qu'un album physique (autant pour le format que pour la gestion des sauvegardes). Pour moi c'est quelque chose de très préoccupant.
Dans ce cas exporte tes versions modifiées en JPEG/TIFF que tu vas backuper. C'est ca que tu veux garder (+ les originaux si tu veux). Le mieux c'est de faire l'export automatiquement.
Le bonus de la compatibilité c'est à partir de l'original + xmp être capable d'avoir exactement la même sortie qu'au moment ou tu l'as travaillé (X versions du soft sont passées depuis). Ca lightroom le gère assez bien simplement par ce qu'ils embarquent les moteurs et écran de réglages des précédentes versions. La dessus aucune idée de ce qu'est capable darktable.
C'est exactement pour ca que selon comment on travail et ce que l'on souhaite faire il faut bien réfléchir au soft qu'on choisi ou ne choisi pas. En général c'est un choix à long terme et le changement est couteux…
Perso darktable à pas encore réussi à me convaincre dans ses premières versions ou la dernière. Rien ne presse.
Perdre 10% de perf pour gagner 10% de productivité ne m'intéresse pas.
Ca me semble de la grosse pignole. Défini déjà précisement ton projet et son domaine fonctionnel précis. Designes en conséquence, la perf du langage ou du middleware est assez secondaire et sera évidente une fois que tu sais ou tu vas. 10% de perf, d'une part t'es encore dans l'erreur statistique de l'autre ca ne veut absolument rien dire.
Ce que tu dis est très très flou; mais pour ce dont tu parlais au début c'est le design du système et du dataflow qui fait que ca marche ou pas. Après tu choisis l'outil qui te semble adapté. Tu veux publier des valeurs de marché avec un jitter minimal ? Alors tu peux vouloir faire une archi type lmax couplé à un pub/sub adhoc. Ou peut être que tu veux faire un truc un poil différent sans de contraintes très forte sur la latence et un modèle à acteur sera la bonne abstraction. Où peut être qu'en fait c'est des algo de streaming couplé à une in-memory grid qui rendront ton business possible.
Une fois ces briques posée tu peux comencer à vouloir réfléchir aux outils à utiliser et comment les utiliser (entre du Java idiomatique et du Java HFT y'a pas grand chose en commun).
Autrement si tu n'as pas une spec précise, tu as juste le problème commun de > 90% des sites webs. Utilise ce que tu veux de toute facon tu n'as aucune idée d'où tu vas et tu vas tout réarchitecturer au fur et à mesure que ca se cassera la gueule. Faut juste compartimenter proprement pour pouvoir faire évoluer les briques indépendaments. Viser la perf au début c'est de la connerie et syndrome classique de la startup "Je veux utiliser la même stack que XXXX par ce que ca va vite"
Le souci vient notamment des navigateurs qui présentent les alertes x509 en mettant tout au même niveau (auto-signé, chaîne de confiance invalide, expiration, mauvais domaine).
Oui.
Maintenant si tu peux éviter de faire crier les navigateurs par ce que toi l'admin tu sais, le monde ne s'en portera pas plus mal en attendant que les navigateurs évoluent. Un peu comme linuxfr cacert et la blague du domaine image…
Pour des tâches longues et gourmandes, tu as parfaitement raison. Nous avons cherché une seule solution pour l'ensemble. Au risque qu'elle ne soit parfaite pour personne.
Tu as une partie métier spécifique mais tous les problèmes d'infra autours sont assez courants. En partant de 0 tu vas au final te prendre dans la face tout les problèmes du monde réel qu'ont les job scheduler et calcul distribué:
- Fork et surveillance des processus
- IPC
- Gestion du réseau
- Tolérance au panne, restart
- Haute dispo
Et ca, c'est juste un travail monstrueux. À partir de 0, je regarderais si il est pas possible de réutiliser un truc comme Hadoop YARN ou autre pour se concentrer sur le métier plutôt que de partir sur une version très simple qui va fatalement se retrouver à tout réimplémenter.
Bah depuis Java 5 tu peux killer, avoir les 3 flux (in, out, err) séparément et en nio, et poller ou attendre un fils. Si t'arrives pas à faire du reporting d'avancement et du kill avec ça, c'est que t'as pas lu la doc…
NIO sur les stream d'un process ? Depuis quand un FileChannel est Selectable ? Non non ton "nio" c'est juste implémenté un bon gros pooling à la main si tu veux pas te retrouver avec 4*N threads pour chaque process. (et au passage c'est bufferisé aussi).
Pour avoir souffert pendant quelques années à maintenir un truc massivement basé sur du fork/exec en Java 5/6 j'étais arrivé exactement à la même conclusion que Charles Nutter (je me souviens encore du code qu'il donne en exemple plus des Windowseries…). Le mec qui dit que c'est facile de faire un truc production ready avec la pauvreté du ProcessBuilder c'est qu'il l'a pas fait lui même.
Là c'est toi qui confond tout… Qu'HotSpot soit incapable de vectoriser du code n'a aucun rapport avec le langage ou sa complexité d'implémentation. Le mot JVM était un indice, c'est juste une limitation de toutes les JVM actuelles.
tu me parles de complexité d'implémentation de Java en la comparant avec C++
Je n'ai jamais parlé de C++.
C'est valable pour toutes les plateformes de dev… Quel est le problème spécifique à Java là dedans?
Il combine:
1- Un langage à neuneu avec 3/4 features rajoutées de manière bancale (bonjour le boxing de type primitif avec overhead mémoire de 200 à 400%, bonjour le type erasure)
2- Un JDK incomplet pour les besoins courant qui vieilli, et qui prend la flotte de partout.
Enfin si tu vois pas le problème tu vois pas le problème et comment il empire petit à petit soit heureux. Contrairement à tout les autres qui passent leur temps à s'amuser entre Java/Scala/Clojure/Groovy pour mettre un pied après les années 80.
Pourtant la JVM défonce à peu près tout le monde niveau perfs
Je ne te parle pas de la JVM.
Si tu regardes les évolutions du langage la majorité écrivent juste le boilerplate, que tu n'aurais jamais du avoir à écrire, pour toi. Les concepts restes les mêmes on les masque juste et c'est javac qui pisse du bytecode pour toi.
Bref c'est cool on arrête d'avoir à écrire des stupidités, ca va réduire le nombre de lignes de code inutile mais des vrais progrès tu en as très peu que ce soit en expressivité, en perf ou en fiabilité. Le langage a beau être simple il est piégeur dans la vraie vie.
Maintenant la complexité d'implémentation le dev ne la voit pas. Mais si tu t'interesse un poil au travail dans OpenJDK tu verras que ca devient de plus en plus difficile pour rajouter quelque chose dans le langage. Et ca ne présage rien de bon pour l'avenir.
Pour les perfs de la JVM, c'est un excellent compromis si tu n'as pas besoin du SIMD ni d'auto-vectorisation. C'est actuellement l'un de ses plus gros points faibles par rapport à du C/C++. Tout le monde n'en a pas besoin mais quand tu tombes dessus ca fait mal. Après selon tes besoins tu vas coder en Java idiomatique ou en C-like si tu as besoin d'aller vite où d'avoir de faible latence (finance, db, big data).
jamais eu autant de libs (le JDK on s'en fout, tout se fait via Maven)
Non on ne s'en fou pas. Il y a des choses qui doivent être au coeur du langage sinon elles perdent leur intêret. Si part hasard elles finissent par trouver leur chemin dans le JDK alors tu traines ce clash pendant des années.
Prenons Optional de Java 8. Java est une pourriture concernant la null-safety depuis le début.
Guava a rajouté l'Optional comme sucre syntaxique. C'est cool on peut commencer à l'utiliser, c'est toujours pas null-safe (un Optional peut être null) mais au moins c'est expressif. Si je veux l'utiliser je dois ajouter une dépendence vers Guava. Maintenant ca fait sont chemin vers le JDK. Maintenant j'ai deux implémentations concurrentes et incompatible. Si je bascule sur le JDK je pète la compat de mon projet. Si je reste sur Guava alors je vais imposer de plus en plus de conflit à mes utilisateurs. Ooops. C'est un problème très courant quand des libs font le job de ce qui devrait être dans le JDK. Et ca fini toujours en bordel crado.
Maintenant on a rajouté Optional mais comme on va pas changer l'API du JDK bin j'ai 50% des méthodes du JDK qui peuvent toujours retourner null. Donc je fini aussi avec un truc ultra-batard
C'est un exemple parmis des dizaines d'autres. De même avoir un langage expressif à la base permet d'avoir du code cohérent et fiable. Regarde les milliers de pauvres dev Java se débattre avec la composition de future et tu pleures. Ce genre de trou fait très très mal et c'est en parti un problème du langage et du JDK.
On peut regretter le poids de l'historique et la bloat attitude, mais quelle plateforme de dev peut aujourd'hui prétendre à ce niveau?
Aucune. Ne lis pas ce que je dis comme une critique bête et méchante de Java ce n'est pas le cas. Je signalais que tout n'est pas rose ainsi que les problèmes qui arrivent.
Ca fait quelques années que pas mal de gens cherchent à avancer et construire un nouveau langage sur la JVM et c'est chaud à cause de l'interop Java (autrement l'interet de la JVM diminue fortement). Pendant ce temps là on continue d'écrire les core-lib en Java comme on écrirait du C, des bindings Scala/Groovy/Whatever et on prend son mal en patience en ayant l'impression d'être toujours aussi mal chaussé et le cul entre deux chaises depuis 10-15 ans même si c'est clairement la meilleure plateforme pour beaucoup de trucs.
Ou pas. Peut être que je fais parfaitement la différence entre la Java Language Specification et la Java Virtual Machine Spécification. Voir même j'ai une petite idée des trous qu'il y a entre les deux même si je suis très très loin d'être un dev OpenJDK ou ex Harmony.
J'ai juste suffisament tordu le truc dans tout les sens ces dix dernières années pour avoir quelques notions relativement solides…
Tu aurais quelque chose d'un peu plus concret que « Java c'est de la merde donc la JVM c'est de la merde » ?
Java n'est pas de la merde. Ses choix initiaux se font par contre de plus en plus payer de jour en jour. On est de deux axiomes: compatibilité reine et moins on t'en donne mieux tu te portes. Dans l'idée ca se tient, sauf qu'en pratique les deux ont conflictés et conflicteront toujours de manière de plus en plus violente. Le sous ensemble fourni était mauvais (et l'est toujours) donc on a passé les dix dernières années à le patcher comme on pouvait. Sauf que la compatibilité à forcée à faire des implémentations complexes de leaky abstraction bourrées de corner cases: Les generics fuient dans tout les sens, l'autoboxing est une horreur tant pour le footprint, que pour les perfs que pour la sureté, les lambdas sont une demi réponse au manque d'objets de premier ordre ca ne couvre pas 50% des besoins et la tête du bytecode à générer est rigolote, l'ajout des default methods est un gros patch qui encore une fois ne règle pas le vrai problème de la composition etc.
Plus ca va, plus les problèmes d'impedance entre Java et ce vers quoi on veut aller augmente. Et c'est encore renforcé par le JDK qui soufre exactement des mêmes symptomes.
Je n'ai jamais dit "beurk caca", la JVM est ses langages sont mon outil de travail depuis des années et c'est actuellement un excellent choix pour beaucoup de chose notamment grace à son ecosysteme, outillage et sa facilité de déployment pour des perfs honnorables.
Par contre dire que l'interop des langages sur la JVM c'est chaud bouillant ca me parait objectif. Si les gens utilisent la JVM c'est rarement pour le côté technique mais pour choper la traction de son ecosysteme afin de pouvoir percer. Et la ca demande d'avoir un langage sur la JVM et qui peut parler à du Java. Et c'est la que les ennuis commencent. Si tu es intéressé les Talks du Java Language Submit sont en ligne depuis des années. On peut aussi dire que Java est de plus en plus en boulet d'une complexité de plus en plus grande pour de faibles de gain en perf ou en sureté (pas du simple sucre syntaxique qui génére le boilerplate pour toi). De même que le JDK reste aussi pauvre conceptuellement d'année en année par rapport à d'autre plateformes.
Quand tu regardes le "top" des technos utilisés par les sites à forte audience, tu tombes sur… PHP. No comment.
En meme temps ca veut pas dire grand chose par ce que dès que tu sors du petit site web, ton truc est en fait une grosse composition d'une multitude de services, souvent chacun fait dans une technos completement différente. Tu as aussi des grosses boucles d'interactions. Typiquement du front & back qui pissent du log, qui vont passer par l'analytics qui va le repasser dans une db qui va être consommée par X autres services. Chacun de ces modules à sa propre techno.
Ce qui est visible de la partie front est en général assez petit niveau fonctionnel et les contraintes de perfs sont pas lourdes (lire ca scale horizontalement linéairement et la plupart du temps est passé à attendre les autres services). Et cette partie se fait de plus en plus vampiriser par l'évolution des clients qui bouffent de l'API qui elle même n'est le fruit que d'une composition.
Bref c'est un choix technos parmis des dizaines d'autres qui se combinent et ne sont pas exclusif. Bien souvent tu vas même avoir plusieurs technos front en même temps, la tendence étant de laisser chaque équipe produit la plus indépendante possible.
Strictement aucune des technos "vrais hommes avec des couilles et de la scale serieuse" n'ont emerge du monde .net:
Tu pourrais leur laisser l'honneur de Rx quand même !
Et le pompom c'est qu'ils ont reussi a se faire piquer leur principale avancee, un vm multi langage, par la jvm avec des trucs comme scala ou jruby.
Cela dit la JVM et le multilangage c'est très loin d'être tout rose. Suffit de suivre les JVM Language submit pour rigoler un peu.
Maintenant on se retrouve avec une VM construite initialement pour un langage "à neuneu" qui à profité de milliers d'années de boulot. Le langage a été patché dans tout les sens mais ses tares resteront à jamais pour raison de compat. Et les nouveaux langages choisissent la JVM pour éviter d'avoir à réinventer une VM et pour chopper la traction des devs Java. Sauf que souvent ca veut dire compat avec Java et exposer toutes ses tares dans les nouveaux langages.
Ca reste le moins pire choix, mais le futur est pas super brillant non plus.
Ensuite, des travaux répétitifs, il y en a plein dans une économie de services, précisément (parce qu'on ne peut pas vraiment automatiser la relation aux clients / usagers / partenaires).
Ca ne veut pas dire qu'ils sont non qualifiés et que la différence de rendement n'est pas significative. Typiquement pour la partie commerciale tu retombes sur le même problème: connaissance du job/ secteur/clients, besoin d'une démarche unifiée, personne ne veut avoir 20 interlocuteurs différents.
Pour les jobs de vendeur interchangeable au smic tu retombes sur la problématique du travail non qualifié qui va disparaitre dès que l'évolution technique et culturelle le rendront non viable. C'est en marche.
Ce qui compte c'est la production globale et sa répartition (i.e. la distribution des richesses). Le temps nécessaire pour parvenir à produire ne devrait pas intervenir.
Oui sauf que si au final tu vas vers 5% des personnes qui peuvent effectivement participer à la production globale et faire évoluer les choses, le débat sur la distribution va devenir de plus en plus compliquer.
Plus tu vas sur du qualifié, plus tu cherches des gens pointus et à minimiser leur nombre. Ce qui est en conflit direct avec la diminution du travail et une distribution équitable.
[^] # Re: Mais si, faut y croire !
Posté par ckyl . En réponse au journal [bookmark] 2014 ne sera pas l'année du jeu libre. Évalué à 4.
Oui l'étape d'après c'est d'obfuscer le code de ton jeu pour rendre le travail des autres moins simple. Oh wait ;)
[^] # Re: Android sans Google
Posté par ckyl . En réponse au journal 36 15 ma vie avec l'univers google. Évalué à 8.
Je ne parlais pas de cynogen ni de XDA en particulier. Mon expérience est peut être biaisée ayant regardé pour des appareils ne pouvant pas faire tourner cyanogen mais en gros ca se résumait à des neuneus, qui peuvent être très bons au passage, qui publient des binaires sortis dont ne sait où, faisant on ne sait quoi, basé eux même sur des binaires sortis dont ne sait où, faisant on ne sait quoi, basé eux même etc. Et pour uploader les binaires ? Bha un binaire sorti dont ne sait où, hébergé n'importe où et qui n'a jamais la même signature. Chaque forum à son neuneu star pour chaque device. Et tu as l'opportunité d'avoir une star par pays en plus par ce que faut bien son quart d'heure de gloire en repackagant son mod bidouillé !
Franchement du peu que j'en ai vu, c'est aussi pathétique que le milieu de la sécurité d'il y a 10+ ans. Des gamins, des neuneus et pas mal de monde avec de sérieux problème psychologiques.
Après peut être que cyanogen est super pro et fait du soft correctement… Mais le lien donée par Tankey résume exactement mon ressenti.
[^] # Re: fdroid
Posté par ckyl . En réponse au journal 36 15 ma vie avec l'univers google. Évalué à 7.
Et en pratique y'a quoi comme applis correctes qui marchent pour de vrai ?
C'est une vraie question la dernière fois que j'ai été y faire un tour je suis rentré bredouille vu la qualité des trucs. Même pour un bloc note à la con…
[^] # Re: Android sans Google
Posté par ckyl . En réponse au journal 36 15 ma vie avec l'univers google. Évalué à 8.
Je ne suis pas du tout dans le mobile pour deux sous mais c'est effectivement l'impression que j'ai eu la dernière fois que j'ai eu à rooter un téléphone et mettre une ROM custom.
Tout le monde utilise des ROM sorties dont ne sait où, avec un lien sur un forum qui pointe vers fileshare qui assemble 10 modules dont personne n'a jamais vu les sources ou un gestionaire de version. Sans compter les outils qui vont autour. Mais c'est de la balle hein…
Je suis certain que si on voyait la gueule des patchs on rigolerait peut être moins que ca soit intentionnel où juste du jean kevin.
[^] # Re: Intérêt de Google ?
Posté par ckyl . En réponse au journal Le Codec VP9 reçoit le soutien de l'industrie.. Évalué à 5.
Oui. Fais un sondage dans la rue… Les deux exploitent une petite niche.
[^] # Re: Mais si, faut y croire !
Posté par ckyl . En réponse au journal [bookmark] 2014 ne sera pas l'année du jeu libre. Évalué à 1.
Un longueur d'avance sur quoi ? Le prochain add-on libre disponible publiquement ? T'es super avancé ca rentre toujours pas de pognon !
Avec du soft grand publique sans besoin particulier tu n'as à priori que trois facon de financer:
- barrière à l'entrée: tu demandes de l'argent pour publier ton travail
- abonnement: Si tout est libre ta plus value c'est 0 et quelqu'un le fera pour moins cher que toi. Au mieux l'abonnement ca sera une plateforme qui le gérera et toi tu récupéras un % (musique par exemple). Mais si c'est libre pourquoi la plateforme te remunerait. Le rapport de force me semble très incertain.
- achat du produit/don: là il faut compter sur la bonne volonté des gens. Ca risque de marcher pour les premiers, savoir si ca se généralise j'ai comme un doute.
Bref rien n'est impossible. Mais avant de financer un vrai jeu et que ca soit reproductible va falloir réfléchir un peu.
[^] # Re: Mais si, faut y croire !
Posté par ckyl . En réponse au journal [bookmark] 2014 ne sera pas l'année du jeu libre. Évalué à 3.
Choupinet je suis pas un lapin de deux semaines et tu peux éviter de me sortir ta réthorique usuelle à moi ?
Donc c'est pas un service en tant que tel que tu vends. C'est juste un financement d'un dev à l'avance avant de publier le code avec une condition que tu ne publies pas tant que tes pas rentré dans tes frais…
Sinon c'est juste voué à l'échec dès que ton code est sorti et que les gens peuvent l'avoir gratos ils le feront. Une fois publié tu n'as plus aucune plus value possible avec ton savoir faire. C'est exactement le problème de la musique et du cinema et le problème n'a pas l'air si évident que ca à résoudre.
Ca ne veut pas dire que ca ne marchera pas pour quelques uns ou qu'il n'y a pas beaucoup d'autres idées à creuser. Mais que le commentaire original me semble être une vision très très simpliste.
Les pieds sur terre je les ai peut être aussi pour avoir fait pendant 6 ans du dev libre et avoir une idée des coûts dans le soft. Quand tu sors du petit soft développé par un freelance dans son coin, le pognon à un moment il faut le rentrer.
Il y a plein de chose à expérimenter mais dire que c'est simple et que ce qui va marcher une fois par ce que t'es tout seul à le faire se généralisera…
[^] # Re: Mais si, faut y croire !
Posté par ckyl . En réponse au journal [bookmark] 2014 ne sera pas l'année du jeu libre. Évalué à 5.
C'est quoi le service dans le jeu vidéo ?
Si par service tu entends l'accès à un serveur pour certain type de jeu, jx'ai un peu un doute que ca couvre tes frais de dev sachant que n'importe qui qui n'a pas ces coûts de dev peut héberger aussi ton truc…
Faut peut être avoir les pieds sur terre des fois.
# COCOMO
Posté par ckyl . En réponse à la dépêche Statistiques 2013 du site LinuxFr.org. Évalué à 7.
Y'a encore des gens qui pensent que c'est utile de parler de cette estimation pourrie qui est toujours aussi fausse autant en temps qu'en argent ?
[^] # Re: de la pertinence d'une JVM permanente pour y exécuter les tâches longues et gourmandes
Posté par ckyl . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 3.
Je suis entièrement d'accord avec ca.
Mon point était juste de tempérer l'enthousiame qui pouvait sembler naïf sur le ProcessBuilder. C'est juste une API de merde qui te masque presque tout ce dont tu as besoin pour faire ton job avec une implémentation bien pourrie aussi.
On arrive à faire des trucs qui marchouillent en lisant tout le code des VM et quand tout va bien. Quand tu forks des processus non controllés sur plusieurs systèmes différents c'est bien plus "rigolo".
[^] # Re: Celles qui m'ont marquées jusque là
Posté par ckyl . En réponse à la dépêche darktable 1.4. Évalué à 2.
Dans ce cas exporte tes versions modifiées en JPEG/TIFF que tu vas backuper. C'est ca que tu veux garder (+ les originaux si tu veux). Le mieux c'est de faire l'export automatiquement.
Le bonus de la compatibilité c'est à partir de l'original + xmp être capable d'avoir exactement la même sortie qu'au moment ou tu l'as travaillé (X versions du soft sont passées depuis). Ca lightroom le gère assez bien simplement par ce qu'ils embarquent les moteurs et écran de réglages des précédentes versions. La dessus aucune idée de ce qu'est capable darktable.
C'est exactement pour ca que selon comment on travail et ce que l'on souhaite faire il faut bien réfléchir au soft qu'on choisi ou ne choisi pas. En général c'est un choix à long terme et le changement est couteux…
Perso darktable à pas encore réussi à me convaincre dans ses premières versions ou la dernière. Rien ne presse.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par ckyl . En réponse au journal Normalisation du langage Dart de Google par l'Ecma. Évalué à 8.
Ca me semble de la grosse pignole. Défini déjà précisement ton projet et son domaine fonctionnel précis. Designes en conséquence, la perf du langage ou du middleware est assez secondaire et sera évidente une fois que tu sais ou tu vas. 10% de perf, d'une part t'es encore dans l'erreur statistique de l'autre ca ne veut absolument rien dire.
Ce que tu dis est très très flou; mais pour ce dont tu parlais au début c'est le design du système et du dataflow qui fait que ca marche ou pas. Après tu choisis l'outil qui te semble adapté. Tu veux publier des valeurs de marché avec un jitter minimal ? Alors tu peux vouloir faire une archi type lmax couplé à un pub/sub adhoc. Ou peut être que tu veux faire un truc un poil différent sans de contraintes très forte sur la latence et un modèle à acteur sera la bonne abstraction. Où peut être qu'en fait c'est des algo de streaming couplé à une in-memory grid qui rendront ton business possible.
Une fois ces briques posée tu peux comencer à vouloir réfléchir aux outils à utiliser et comment les utiliser (entre du Java idiomatique et du Java HFT y'a pas grand chose en commun).
Autrement si tu n'as pas une spec précise, tu as juste le problème commun de > 90% des sites webs. Utilise ce que tu veux de toute facon tu n'as aucune idée d'où tu vas et tu vas tout réarchitecturer au fur et à mesure que ca se cassera la gueule. Faut juste compartimenter proprement pour pouvoir faire évoluer les briques indépendaments. Viser la perf au début c'est de la connerie et syndrome classique de la startup "Je veux utiliser la même stack que XXXX par ce que ca va vite"
[^] # Re: b0rked link
Posté par ckyl . En réponse à la dépêche Appel à conférenciers pour Python-FOSDEM 2014. Évalué à 2.
Oui.
Maintenant si tu peux éviter de faire crier les navigateurs par ce que toi l'admin tu sais, le monde ne s'en portera pas plus mal en attendant que les navigateurs évoluent. Un peu comme linuxfr cacert et la blague du domaine image…
[^] # Re: de la pertinence d'une JVM permanente pour y exécuter les tâches longues et gourmandes
Posté par ckyl . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 3.
Vous avez regarderzsur qu'elle brique d'infra vous pourriez greffer votre truc ?
Tu as une partie métier spécifique mais tous les problèmes d'infra autours sont assez courants. En partant de 0 tu vas au final te prendre dans la face tout les problèmes du monde réel qu'ont les job scheduler et calcul distribué:
- Fork et surveillance des processus
- IPC
- Gestion du réseau
- Tolérance au panne, restart
- Haute dispo
Et ca, c'est juste un travail monstrueux. À partir de 0, je regarderais si il est pas possible de réutiliser un truc comme Hadoop YARN ou autre pour se concentrer sur le métier plutôt que de partir sur une version très simple qui va fatalement se retrouver à tout réimplémenter.
[^] # Re: de la pertinence d'une JVM permanente pour y exécuter les tâches longues et gourmandes
Posté par ckyl . En réponse à la dépêche JQM, un serveur de batchs asynchrones en Java. Évalué à 4.
NIO sur les stream d'un process ? Depuis quand un FileChannel est Selectable ? Non non ton "nio" c'est juste implémenté un bon gros pooling à la main si tu veux pas te retrouver avec 4*N threads pour chaque process. (et au passage c'est bufferisé aussi).
Pour avoir souffert pendant quelques années à maintenir un truc massivement basé sur du fork/exec en Java 5/6 j'étais arrivé exactement à la même conclusion que Charles Nutter (je me souviens encore du code qu'il donne en exemple plus des Windowseries…). Le mec qui dit que c'est facile de faire un truc production ready avec la pauvreté du ProcessBuilder c'est qu'il l'a pas fait lui même.
[^] # Re: b0rked link
Posté par ckyl . En réponse à la dépêche Appel à conférenciers pour Python-FOSDEM 2014. Évalué à 3.
Si tu as des besoins simples StartSSL file des certificats gratos
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par ckyl . En réponse au journal Normalisation du langage Dart de Google par l'Ecma. Évalué à 2.
Là c'est toi qui confond tout… Qu'HotSpot soit incapable de vectoriser du code n'a aucun rapport avec le langage ou sa complexité d'implémentation. Le mot JVM était un indice, c'est juste une limitation de toutes les JVM actuelles.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par ckyl . En réponse au journal Normalisation du langage Dart de Google par l'Ecma. Évalué à 2. Dernière modification le 27 décembre 2013 à 20:25.
Je n'ai jamais parlé de C++.
Il combine:
1- Un langage à neuneu avec 3/4 features rajoutées de manière bancale (bonjour le boxing de type primitif avec overhead mémoire de 200 à 400%, bonjour le type erasure)
2- Un JDK incomplet pour les besoins courant qui vieilli, et qui prend la flotte de partout.
Enfin si tu vois pas le problème tu vois pas le problème et comment il empire petit à petit soit heureux. Contrairement à tout les autres qui passent leur temps à s'amuser entre Java/Scala/Clojure/Groovy pour mettre un pied après les années 80.
[^] # Re: Les masques dessiné ?
Posté par ckyl . En réponse à la dépêche darktable 1.4. Évalué à 2.
Les smart preview (DNG de 2048px, editable et exportable)sont dispo dans lightroom 5.
Si la taille n'est pas un problème pourquoi ton fichier est offline ? :p
Un feedback sur la compatibilité et la pérénité à long terme ? (Il est bien sur beaucoup trop tôt pour pouvoir en juger sérieusement)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par ckyl . En réponse au journal Normalisation du langage Dart de Google par l'Ecma. Évalué à 5.
Je ne te parle pas de la JVM.
Si tu regardes les évolutions du langage la majorité écrivent juste le boilerplate, que tu n'aurais jamais du avoir à écrire, pour toi. Les concepts restes les mêmes on les masque juste et c'est javac qui pisse du bytecode pour toi.
Bref c'est cool on arrête d'avoir à écrire des stupidités, ca va réduire le nombre de lignes de code inutile mais des vrais progrès tu en as très peu que ce soit en expressivité, en perf ou en fiabilité. Le langage a beau être simple il est piégeur dans la vraie vie.
Maintenant la complexité d'implémentation le dev ne la voit pas. Mais si tu t'interesse un poil au travail dans OpenJDK tu verras que ca devient de plus en plus difficile pour rajouter quelque chose dans le langage. Et ca ne présage rien de bon pour l'avenir.
Pour les perfs de la JVM, c'est un excellent compromis si tu n'as pas besoin du SIMD ni d'auto-vectorisation. C'est actuellement l'un de ses plus gros points faibles par rapport à du C/C++. Tout le monde n'en a pas besoin mais quand tu tombes dessus ca fait mal. Après selon tes besoins tu vas coder en Java idiomatique ou en C-like si tu as besoin d'aller vite où d'avoir de faible latence (finance, db, big data).
Non on ne s'en fou pas. Il y a des choses qui doivent être au coeur du langage sinon elles perdent leur intêret. Si part hasard elles finissent par trouver leur chemin dans le JDK alors tu traines ce clash pendant des années.
Prenons Optional de Java 8. Java est une pourriture concernant la null-safety depuis le début.
Guava a rajouté l'Optional comme sucre syntaxique. C'est cool on peut commencer à l'utiliser, c'est toujours pas null-safe (un Optional peut être null) mais au moins c'est expressif. Si je veux l'utiliser je dois ajouter une dépendence vers Guava. Maintenant ca fait sont chemin vers le JDK. Maintenant j'ai deux implémentations concurrentes et incompatible. Si je bascule sur le JDK je pète la compat de mon projet. Si je reste sur Guava alors je vais imposer de plus en plus de conflit à mes utilisateurs. Ooops. C'est un problème très courant quand des libs font le job de ce qui devrait être dans le JDK. Et ca fini toujours en bordel crado.
Maintenant on a rajouté Optional mais comme on va pas changer l'API du JDK bin j'ai 50% des méthodes du JDK qui peuvent toujours retourner null. Donc je fini aussi avec un truc ultra-batard
C'est un exemple parmis des dizaines d'autres. De même avoir un langage expressif à la base permet d'avoir du code cohérent et fiable. Regarde les milliers de pauvres dev Java se débattre avec la composition de future et tu pleures. Ce genre de trou fait très très mal et c'est en parti un problème du langage et du JDK.
Aucune. Ne lis pas ce que je dis comme une critique bête et méchante de Java ce n'est pas le cas. Je signalais que tout n'est pas rose ainsi que les problèmes qui arrivent.
Ca fait quelques années que pas mal de gens cherchent à avancer et construire un nouveau langage sur la JVM et c'est chaud à cause de l'interop Java (autrement l'interet de la JVM diminue fortement). Pendant ce temps là on continue d'écrire les core-lib en Java comme on écrirait du C, des bindings Scala/Groovy/Whatever et on prend son mal en patience en ayant l'impression d'être toujours aussi mal chaussé et le cul entre deux chaises depuis 10-15 ans même si c'est clairement la meilleure plateforme pour beaucoup de trucs.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par ckyl . En réponse au journal Normalisation du langage Dart de Google par l'Ecma. Évalué à 3.
Ou pas. Peut être que je fais parfaitement la différence entre la Java Language Specification et la Java Virtual Machine Spécification. Voir même j'ai une petite idée des trous qu'il y a entre les deux même si je suis très très loin d'être un dev OpenJDK ou ex Harmony.
J'ai juste suffisament tordu le truc dans tout les sens ces dix dernières années pour avoir quelques notions relativement solides…
Java n'est pas de la merde. Ses choix initiaux se font par contre de plus en plus payer de jour en jour. On est de deux axiomes: compatibilité reine et moins on t'en donne mieux tu te portes. Dans l'idée ca se tient, sauf qu'en pratique les deux ont conflictés et conflicteront toujours de manière de plus en plus violente. Le sous ensemble fourni était mauvais (et l'est toujours) donc on a passé les dix dernières années à le patcher comme on pouvait. Sauf que la compatibilité à forcée à faire des implémentations complexes de leaky abstraction bourrées de corner cases: Les generics fuient dans tout les sens, l'autoboxing est une horreur tant pour le footprint, que pour les perfs que pour la sureté, les lambdas sont une demi réponse au manque d'objets de premier ordre ca ne couvre pas 50% des besoins et la tête du bytecode à générer est rigolote, l'ajout des default methods est un gros patch qui encore une fois ne règle pas le vrai problème de la composition etc.
Plus ca va, plus les problèmes d'impedance entre Java et ce vers quoi on veut aller augmente. Et c'est encore renforcé par le JDK qui soufre exactement des mêmes symptomes.
Je n'ai jamais dit "beurk caca", la JVM est ses langages sont mon outil de travail depuis des années et c'est actuellement un excellent choix pour beaucoup de chose notamment grace à son ecosysteme, outillage et sa facilité de déployment pour des perfs honnorables.
Par contre dire que l'interop des langages sur la JVM c'est chaud bouillant ca me parait objectif. Si les gens utilisent la JVM c'est rarement pour le côté technique mais pour choper la traction de son ecosysteme afin de pouvoir percer. Et la ca demande d'avoir un langage sur la JVM et qui peut parler à du Java. Et c'est la que les ennuis commencent. Si tu es intéressé les Talks du Java Language Submit sont en ligne depuis des années. On peut aussi dire que Java est de plus en plus en boulet d'une complexité de plus en plus grande pour de faibles de gain en perf ou en sureté (pas du simple sucre syntaxique qui génére le boilerplate pour toi). De même que le JDK reste aussi pauvre conceptuellement d'année en année par rapport à d'autre plateformes.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par ckyl . En réponse au journal Normalisation du langage Dart de Google par l'Ecma. Évalué à 3.
En meme temps ca veut pas dire grand chose par ce que dès que tu sors du petit site web, ton truc est en fait une grosse composition d'une multitude de services, souvent chacun fait dans une technos completement différente. Tu as aussi des grosses boucles d'interactions. Typiquement du front & back qui pissent du log, qui vont passer par l'analytics qui va le repasser dans une db qui va être consommée par X autres services. Chacun de ces modules à sa propre techno.
Ce qui est visible de la partie front est en général assez petit niveau fonctionnel et les contraintes de perfs sont pas lourdes (lire ca scale horizontalement linéairement et la plupart du temps est passé à attendre les autres services). Et cette partie se fait de plus en plus vampiriser par l'évolution des clients qui bouffent de l'API qui elle même n'est le fruit que d'une composition.
Bref c'est un choix technos parmis des dizaines d'autres qui se combinent et ne sont pas exclusif. Bien souvent tu vas même avoir plusieurs technos front en même temps, la tendence étant de laisser chaque équipe produit la plus indépendante possible.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par ckyl . En réponse au journal Normalisation du langage Dart de Google par l'Ecma. Évalué à 2.
Tu pourrais leur laisser l'honneur de Rx quand même !
Cela dit la JVM et le multilangage c'est très loin d'être tout rose. Suffit de suivre les JVM Language submit pour rigoler un peu.
Maintenant on se retrouve avec une VM construite initialement pour un langage "à neuneu" qui à profité de milliers d'années de boulot. Le langage a été patché dans tout les sens mais ses tares resteront à jamais pour raison de compat. Et les nouveaux langages choisissent la JVM pour éviter d'avoir à réinventer une VM et pour chopper la traction des devs Java. Sauf que souvent ca veut dire compat avec Java et exposer toutes ses tares dans les nouveaux langages.
Ca reste le moins pire choix, mais le futur est pas super brillant non plus.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par ckyl . En réponse au journal Normalisation du langage Dart de Google par l'Ecma. Évalué à 6. Dernière modification le 24 décembre 2013 à 00:06.
http://highscalability.com/blog/2013/3/20/dart-is-it-the-future-of-the-web.html
https://gist.github.com/paulmillr/1208618
(je me fiche de Dart mais ca me semble etre plus ce que tu attends)
[^] # Re: Rien de nouveau à l'horizon
Posté par ckyl . En réponse au journal Google Robotics. Évalué à 2.
Ca ne veut pas dire qu'ils sont non qualifiés et que la différence de rendement n'est pas significative. Typiquement pour la partie commerciale tu retombes sur le même problème: connaissance du job/ secteur/clients, besoin d'une démarche unifiée, personne ne veut avoir 20 interlocuteurs différents.
Pour les jobs de vendeur interchangeable au smic tu retombes sur la problématique du travail non qualifié qui va disparaitre dès que l'évolution technique et culturelle le rendront non viable. C'est en marche.
Oui sauf que si au final tu vas vers 5% des personnes qui peuvent effectivement participer à la production globale et faire évoluer les choses, le débat sur la distribution va devenir de plus en plus compliquer.
Plus tu vas sur du qualifié, plus tu cherches des gens pointus et à minimiser leur nombre. Ce qui est en conflit direct avec la diminution du travail et une distribution équitable.