fredix a écrit 1945 commentaires

Perso en usage courant je préfère de loin une application native, et spotify fourni un excellent client natif en Qt. De plus apparemment ils implémentent un protocole P2P ce qui permet l'écoute de musique de manière immédiate sans lag. Perso je préfère une société qui investi dans la R&D et qui fait l'effort de s'adapter à l'OS de l'utilisateur plutôt que celles qui jurent que par le web et dont le business model se résume à acheter du catalogue.

Oui désolé, je pensais que pleins de geeks l'avaient déjà vu.
Comme impression c'est très émouvant de voir un quotidien des êtres humains derrière TPB. Le docu est orienté essentiellement sur le procès contre les 3 fondateurs du site, c'est dommage car on reste dans ce contexte sans en sortir.
J'ai été stupéfait lorsque Gottfrid Svartholm un des fondateurs a écrit sur un tableau le nombre PI de mémoire avec une vingtaine de chiffres après la virgule :)

Bon sinon, le docu montre bien l'acharnement juridique contre eux, l'ambiguité de la justice dont le juge qui avait des lien ambiguës avec les plaignants, il faisait parti d'une organisation de protection du copyright, or malgré des suspicions avérés de non partialité il a été reconnu impartial.

Coté accusé, on leur a reproché d'avoir fait de l'argent en plaçant de la publicité sur le site, pour environ 500€ par semaine par pub. L'accusation a estimé 64 pubs, eux estime 4 pubs ce qui reviendrait à 4*500*52 semaines = 104000$ somme qu'ils n'ont apparemment jamais eu, mais loin des 64*500*52=1 664 000$ estimé par les plaignants.
Or même s'ils me paraissent des idéologues hackers voir anarchistes, Cette partie est très ambiguë, même si je suis sur qu'ils sont à l'inverse de Kim dotcom.

Le documentaire montre aussi leur rapprochement avec le parti pirate, et l'intelligence de faire héberger le site par eux, afin de bénéficier de leur immunité, le parti ayant des sièges au parlement européens.

Ils ont été tous les 3 condamnés à plusieurs mois de prisons ferme, pour complicité d'infraction au copyright (ou quelque chose du genre).
Le Gottfrid qui s'était enfui au Cambodge a été extradé puis mis en prison, un autre a fondé Flattr mais on ne sait pas s'il a été en prison (google doit savoir) et un autre s'est enfui au Laos s'est marié, il est recherché par Interpol.

Je pense que même si TPB sert essentiellement à échanger des fichiers soumis à des copyright, il n'est qu'un annuaire. A priori s'ils avaient accepté de supprimer des torrents comme demandé par des majors et pas gagné d'argent par la pub, ils auraient été relaxé à mon avis.
Il n'en reste pas moins que les US ont lancé des menaces économique contre la Suède afin de les pousser à réagir fermement. Invariablement la justice Américaine à tendance à faire Loi à travers le monde, et cela est de plus en plus inquiétant.

Pour l'aspect technique j'en reviens à mon journal, TPB ainsi que megaupload ont montré la faiblesse d'un système centralisé. Ils sont toujours là mais pour combien de temps. Devrait-on se réjouir à ce qu'ils disparaissent ? En tout cas tant que les industries du divertissement ne propose pas un modèle de distribution rapide (torrent), propre (formats, sous titres, etc), abordable il est difficile de jeter la pierre à ces sites de partage ; lire l'édifiant http://jvoulaispaspirater.tumblr.com/

Le problème, bien sûr, c'est qu'il ne la codera pas forcément aussi vite…

Je ne suis pas convaincu. Ayant fait pendant des années du dev web, je te garanti que développer une application web complexe, demande des compétences dans de nombreuses technos comme JS, CSS, HTML, et coté serveur, un langage script comme PHP/Python/Ruby, + config serveur web et base de données.
Sans parler des lib comme HAML, coffeescript , sass, jquery, etc etc. parce que n'importe quel dev web sérieux n'utilise plus HTML, CSS, JS directement.
Au final développer une application native en Qt est beaucoup plus simple d'autant plus avec des outils comme QtCreator et QtDesigner.

Alors sans doute que le JS/GNOME n'est pas comparable à toute la stack nécessaire au dev web. L'avenir nous dira si c'est un bon choix. Je remarque cependant que l'API de OSX, est obligatoirement ObjectiveC, langage loin d'être accessible au commun des mortels, en tout cas pas ceux visé par l'API en JS, ce qui n'empêche pas OSX d'avoir un store énorme d'applications et d'autre part permet d'avoir un desktop fluide pas envahi de petites apps en scripts…

Je reste convaincu que promouvoir un langage par défaut comme Vala aurait été un meilleur choix pour la plateforme. Et rien n'empêche d'utiliser Python ou JS pour ceux qui le veulent.

Idem, une palanquée de soft en python marchouille sans vraiment planter. Au moins en C/C++ si ça merde ça plante ou ça leak mais dans les 2 cas c'est rapidement visible et corrigé.
Exemple les clients twitter en python qui rament tous, le seul qui me parait utilisable est Choqok qui bizarrement est en C++…

C'est pas si évident mais un programmeur mauvais ou moyen il fera toujours un app plus lente en JS qu'en C++, or le but du JS par défaut dans GNOME c'est justement d'attirer le dev moyen …
Si le but est de descendre le niveau d'accès des dev à la plateforme GNOME au détriment des perfs et donc au détriment des machines un peu plus ancienne, perso je ne me reconnais plus du tout dans cet écosystème.

Je suppose que tu fais de l'ironie sauf que Nagios a beau être en C la plupart des plugins sont en scripts donc il se peut très bien que shinken soit plus rapide car meilleur architecture que Nagios et ses plugins en scripts. Zabbix est lui très rapide.
C'est pas tant le langage qui fait la différence que le fait de passer par une VM/interpréteur ou pas.

Évidement j'exagère, mais la grande majorité des apps sont en C++ et à l'usage du desktop change tout.

Moi je pense que GNOME devrait se rapprocher de FirefoxOS, vu que l'Avenir d'Internet, des bureaux, des smartphones passent pas les technos WEB.

Bon sinon j'ai un uptime de plusieurs semaines avec HaikuOS sur un vieux laptop, ca tourne au poil, empreinte mémoire de l'OS autour de 300Mo, tout est fluide, ya pas de merdes en scripts. Bref, mon avenir perso je sais ou il va :)

pas grave il y a Razor-qt :)

Les apps en Qt se lancent bien sous XFCE non ?

Oui et je ne vois toujours pas l'intérêt face un un client pyqt pour lancer des commandes systèmes locales.

Pour lancer des commandes systèmes sur une machine locale je ne suis pas sûr que le web soit le plus simple pour ça :)
Je te moinsse pas mais c'est une erreur de penser dev web pour un oui ou pour un non.

Ah oui vu comme ça en effet .. :)

Franchement avec le chemin full Qt que prend Blackberry, Ubuntu Phone, Jolla Mobile, et le support natif de Qt sur Mac, ca me parait plus judicieux Qt que GTK+. Personnellement je ne vois plus l'intérêt de GTK+ face à Qt.

PyQt peut être pas mal, et python ca permet en plus autant de faire du système que du web.

http://qt-project.org/doc/qt-4.8/examples-statemachine.html

Telehash ca me semble bien mort. Sinon j'ai pas de spec ni rien mais j'ai du code qui tourne en prod :)
Je pense que je me pencherais sur l'aspect P2P lorsque tout le reste sera stabilisé et documenté, donc pas pour demain …

Donc si ffmpeg intègre ce code ils vont se faire taper ?

Apparemment il y a un DEC/ENC sous licence BSD : http://hevc.hhi.fraunhofer.de/ https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/trunk/

Ok pour java, perso je suis allergique :)
Pour le P2P le mieux est peut être d'utiliser une DHT, via une lib comme bitdht ou tomP2P

Je taff sur le projet nodecast qui est en gros un ordonnanceur générique de jobs asynchrone. L'idée est d'envoyer des payloads vers l'API HTTP qui seront traités par des workers selon un workflow défini. Les payloads peuvent être du JSON ou bien un binaire qui seront stockés dans GridFS.
De fait ces payloads peuvent être du texte, images, vidéos. L'intelligence est donc dans les workers qui seront quoi en faire. Ce principe permet de scaler facilement car on peut lancer un poll d'un même worker, nodecast se chargeant de loadbalancer sur le premier de libre.

En plus d'un serveur HTTP, nodecast embarque aussi un serveur XMPP et FTP et bientot un tracker bittorrent (donc un serveur HTTP dédié à cette tâche). Avec ce type d'outils il doit être possible de répondre à toutes sortes de besoins aussi bien pour des applications web que natives.
Par exemple je souhaite développer un outil de partage de fichier intégrant un réseau social. Le réseau social serait fourni par le serveur XMPP, le FTP permettrait d'uploader un gros fichier, générer un torrent par un worker, le transmettre à ses contacts via XMPP puis le seeder et mettre en liaison les peers via le tracker.
Pour un simple site web, l'API HTTP générique pourrait stocker ses données et lui fournir. Il resterait à savoir comment synchroniser des noeuds nodecast. Telehash semblait prometteur pour ça mais le code ne bouge plus. Il y a aussi LSD basé sur Zyre basé sur ZeroMQ.
Bref, beaucoup de rêves encore, mais si tu aimes le C++ .. :)

Je travaille sur un projet libre et je voudrais atteindre cet objectif, mais j'ai pas fais de thèse :)
La plus grosse difficulté étant de développer un protocole de synchronisation entre des instances, sachant que certaines instances pourrait ne pas avoir suffisamment d'espace disque pour tout stocker.

Pourquoi se contenter de décentraliser une tribune et pas un site web complet ? Ainsi il pourrait y avoir des instances de linuxfr un peu partout et lorsqu'un article, journal, commentaire est posté sur l'une d'elle c'est synchronisé avec les autres.

Elles vont bien. Tu n'as pas compris, je comparais une architecture centralisé en web + protocole HTTP et une architecture décentralisé + protocole bittorrent. Cette dernière est à mon avis hautement plus scalable et adapté au partage de fichier que la première.