Guillaume Denry a écrit 2971 commentaires

C'est marrant de parler des « avantages du Cloud », alors qu'en réalité il y a surtout des inconvénients à l'utiliser, en particulier des inconvénients très sérieux concernant tes données personnelles

J'ai délibérément évité le débat des données personnelles parce que c'est une des choses qui justifierait l'évitement des gmail et autres services hébergés en clair, et je trouverais Cette démarche plus d'honorable : salvatrice.

Non, je me suis positionné uniquement sur le plan technique, et je ne vois pas ce qui peut être plus simple et immédiat que de lancer une URL sur un navigateur web et accéder à tous ses services. Que ton cloud soit chez Google ou chez toi sur une box d'ailleurs hein.

Tu parles d'un système hébergé sur clef USB, as-tu la garantie que où tu ailles, l'ordinateur que tu utilises soit opérationnellement et matériellement capable d'exécuter ce système ? Est-ce que tu penses que la gymnastique de devoir systématiquement penser à embarquer sa clef USB (je sais, porte-clef, etc), ou bien simplement d'en faire la maintenance est quelque chose d'accessible au commun des mortels ? Soyons sérieux, l'ubiquité du "cloud" est quelque chose d'incomparable. Bienheureux sont ceux qui sont capables de s'en passer sans soucis ou de coupler cette utilisation avec un backup local, pour pouvoir maîtriser totalement la confidentialité et l'accessibilité de leurs données, mais c'est une utilisation de niche.

Si la génération d'un nouvel élément dure longtemps, on peut très bien demander son calcul à une promise qui se chargera d'appeler le callback et de demander la génération du prochain élément au moment voulu.

Et tu dois donc penser l'écriture de ton traitement de façon asynchrone.

Ici yield te permettrait d'insérer des points d'entrées dans ton algorithme de façon à ce que tu te dises "ici on a besoin d'attendre un next()" pour pouvoir continuer le traitement. On y gagne en concision et en expressivité.
Les promises c'est sympa, j'aime bien, mais quand il s'agit de véhiculer le contexte d'exécution de toute la promise chain simplement, il faut en passer par des variables extérieures, etc.

Tu as un exemple relativement petit de programmation pseudo-synchorne avec des générateurs et des promises?

Qu'as-tu donc contre la myriade d'exemples qu'on peut trouver sur le web ? :)

Rien que l'exemple sur la page d’accueil de cette lib (qui gagne en popularité en ce moment) : http://taskjs.org/

Ok ok.
Dans ton cas, tu génères une séquence en une fois, sans "coupure" du traitement, mais pour moi, les générateurs (donc les itérateurs, quelque part) présentent l'avantage de pouvoir s'associer aux promises pour faire du code sous forme pseudo-synchrone. Ca ouvre des possibilités assez sensationnelles pour injecter de l'asynchronicité dans un long traitement écrit sous forme synchrone.
Je répond peut-être à côté de la plaque ?

Cela ne s'arrête jamais, mais si le code utilisant l'énumération en a marre, il peut lancer une exception par exemple.

Une exception pour arrêter une boucle ? Erk.
Tu vois autre chose pour arrêter la boucle dans ce cas là ?

Il me semble que dans un cadre privé, mais encore plus dans un cadre d'entreprise, il est primordial de garder la main mise sur son infrastructure. Le cloud est très pratique, mais stocker tout ses documents, même les plus confidentiels dans des serveurs étrangers me semble être très délicat et dangereux.

Ce qui me semble primordial au delà de l'endroit où sont réellement stockées nos données, c'est de savoir QUI a la capacité d'accéder réellement à ces données. Avec du chiffrement fort, je pourrais être convaincu de stocker mes données n'importe où, même dans le coin le plus malfamé d'internet, à partir du moment où j'ai la garantie absolue d'être le seul à pouvoir déchiffrer mes données. Bien sûr, il faudrait avoir de la redondance parce que des données que personne (à part vous) ne peut déchiffrer qui disparaissent, bin c'est mort, effectivement. Bien sûr, cela soulève également la problématique de la confiance dans la chaîne logicielle qui va de moi à mes données.

Si tu veux évoquer les cas "aux limites", effectivement, on peut commencer à couper les cheveux en quatre pendant 107 ans sur l'avantage de telle ou telle configuration. Je parlais du cas nominal.
Se priver volontairement des avantages du "cloud" juste parce que "on sait jamais, je préfère me trimballer une clef USB ou réinstaller mes logiciels où que j'aille, y'a ptete pas le net", c'est assez singulier, mais pourquoi pas.

• donc il nous faut ** un semaphore qui compte les places libre ** un semaphore qui compte les places occupée

Un truc m'échappe : places libres = taille du tuyau - places occupées
Non ?

Du coup, pourquoi ne pas parler QUE de places occupées ou QUE de places libres dans le reste de ton énoncé ?

le plus rigolo étant que les adorateurs de la ligne de commande utilisent des terminaux… la plupart du temps dans une interface graphique. Pas très crédible quand même

J'adore la ligne de commande (miam antigen, miam liquidprompt, zsh-syntax-highlighting, etc) et j'adore aussi les IHM graphiques (bin, euh, va faire un dessin à la Gimp avec une console !)
.
Ouch, je sens que je me fais aspirer par une faille de l'espace-temps-contradiction Zenitramesque ! Au secours /o\

Encore une fois, tu forces les gens à rentrer dans des cases pour pouvoir combattre leurs arguments, qui a dit ici que la console était capable de combler facilement tous les besoins ?

Est-ce une chose vers laquelle on doit avoir envie de tendre ?

Le fait de pouvoir :

1/ de plus avoir à faire N "maintenances" logicielle (au moins l'installation) pour pouvoir éditer un document sur N machines
2/ pouvoir accéder de n'importe où à son document sans se trimballer une clef USB sur soi mais en lançant juste un navigateur web

Oui, c'est plutôt un énorme avantage et c'est pour moi quelque chose qui rend le cloud très séduisant.

Ceci étant dit, un cloud "personnel" à la ownCloud me semble effectivement quelque chose vers lequel on devrait tendre, et pas vers un monde où l'on confie toutes nos données à Google et Cie.

Le gars s'en fout de rester en bons termes avec toi parce que le gars a envie de bosser sur ses projets, il a probablement des fréquentations qui lui suffisent, et il s'est visiblement beaucoup moins fait de mouron que toi sur ce sujet, tout simplement parce que ça n'en vaut pas la peine, son conseil d'aller de l'avant est plutôt bon, et rejoint la teneur du dernier commentaire de ton blog.
Je trouve assez sain même si ça peut sembler paradoxal que le web et les projets collaboratifs permettent de se concentrer uniquement sur la technique quitte à employer une franchise absolue dans les rapports humains.

Un channel IRC n'est pas un agora, le type anime son channel IRC et lorsque tu y entres, tu y es un invité.
Lorsque tu es invité chez quelqu'un, si tu commences à péter dans le frigo et à critiquer la cuisine de la maîtresse de maison, les hôtes ne vont pas forcément avoir envie de te garder chez eux.

Zenitram l'a très bien expliqué, mais ta proposition d'aide n'en est pas vraiment une.
Le gars est over-booké, si tu veux vraiment lui proposer de l'aide, il faut éventuellement lui fournir une solution clef-en-main en lui expliquant quels seraient les avantages pour LUI, pas quelque chose qui va lui prendre une partie de son temps alors que les bénéfices lui seront relatifs. Peut-être que son objectif principal n'est pas de gagner des tonnes d'utilisateurs mais juste de construire la distrib qui lui plaît, dans ce cas, construire régulièrement des builds n'est pas sa priorité.
Il n'est certes pas diplomate, mais relis bien les logs à tête reposée, essaye juste de te projeter un peu à sa place, avec ses impératifs, et peut-être que tu comprendras son attitude.

Preuve que la décision précédente était mauvaise (tout comme Mozilla a lâché leur refus de H264 pour prendre un autre exemple, mais eux ont lâché après 1 an).

En quoi est-ce une "mauvaise décision" de faire acte de résistance et de parier sur quelque chose ?
Leur position est pour moi infiniment plus respectable que celle qui consiste à adopter la solution la moins éthique mais la plus pragmatique parce que "bin c'est comme ça, c'est les plus forts, inutile de lutter".

Tu te bases sur quoi de concret exactement pour dire que la part non libre de Qt est de plus en plus prédominante au point de dire que Qt "était" un bon toolkit libre ?

Oui en fait, c'est de la ressource perdue pour Linux et les systèmes libres. C'est ce que je voulais dire mais ma tournure est effectivement ambigüe.

Les gens qui s'intéressent au portage d'un logiciel sous windows ne seraient peut-être (et encore, "peut-être", je suis gentil) pas intéressés pour bosser sur d'autres aspects du soft.

J'ai braqué violemment en utilisant knockoutJs + reqwest + requireJS + Q + vanilla, en attendant d'avoir un truc meilleur pour le front-end.

Je te conseille de jeter un oeil sur ReactJs, en tout cas ne serait-ce que pour la partie V de MVC.
Ce truc là est en train de monter et les concepts sont puissants.

Ca va probablement te faire un choc.

http://french.stackexchange.com/questions/11799/continuer-de-faire-ou-continuer-%C3%A0-faire
http://fr.wiktionary.org/wiki/Discussion:continuer
http://www.etudes-litteraires.com/forum/topic4301-continuer-a-continuer-de.html

Donc je demande a ses utilisateurs: pourquoi preferer Chrome?

Malheureusement, sur mon laptop du moins, Chrome est bien bien plus véloce en ce qui concerne mes applis JavaScript.
C'est dommage, je trouve que l'équipe de Chrome est une équipe de nazis qui refuse certaines choses élémentaires (comme la possibilité de cacher la croix de fermeture des onglets), de plus je trouve Firefox bien plus sympa au niveau des extensions.

Là pour moi, on est plus dans la crétinerie bas de plafond que dans le sexisme.

Google n'a pas assuré sur ce coup-là.

Ca dépend ce qu'on veut dire par "assuré". Google n'étant pas une association philanthropique ou bien un service public, sa démarche est parfaitement corporate : un service se fait dépasser et n'est plus à la hauteur : ils le ferment et proposent une procédure de migration des projets tout en maintenant les projets consultables pendant un bon moment.
Donc, dans un sens, si, ils "assurent". Mais juste pas dans ton sens à toi.

ça va grave faire chier son business car toutes les merdewares livrées avec son soft qui installent des extensions cochonwares ne vont plus pouvoir pourrir les profils Firefox.

Vraiment ? Je veux dire, est-ce que Firefox a vraiment le pouvoir d'empêcher la corruption d'un profile de la part d'un installeur Windows ? C'est une vraie question, j'ignore comment fonctionnent les droits sous Windows.

Exact, j'aurais dû parler de "droits d'auteur".
Merci

Pourquoi s'arrêter au web ? Un auteur de BD ne devrait pas s'offusquer de voir des scans de ses oeuvres être librement redistribuer non plus puisque hé, la BD était publiquement diffusée hein.

En gros, tu es en train de nous dire que le brevetage et la propriété intellectuelle, c'est pareil.

Désolé, je garde mes espadrilles !