Non. Une part variable doit être basée sur des conditions s'appuyant sur des critères précis : objectifs, CA généré, etc. Et l'employeur ne peut pas décider spontanément que tu n'as pas atteint les objectifs car c'est contractuel.
Attention toutefois que dans certains cas l'employé n'a pas vraiment la maîtrise de tous les paramètres qui lui permettrait de faire valoir son droit.
Par exemple, je dois réussir un projet dans les temps mais mon employeur lui même met des battons dans les roues ou change les spécifications sans arrêt.
Tu as raison. Ceci dit suivant la capacité / rapidité de compréhension du client, tu as parfois l'impression de "perdre" (surtout dans les cas ou tu es au forfait en fait…)
Mais ceci dit j'aime aussi la discussion avec les gens qui ont une "autre logique", ça amène aussi à se reposer parfois des questions plus fondamentales, alors qu'on était prisonnier d'un détail logique. Ça amène aussi des découvertes par sérendipité (une réponse illogique qui amène à se rendre compte que le besoin est un autre).
Ah oui j'oubliais de dire que tout cela est aussi inhérent à ce que je nomme "métier de la connaissance" (voir Knowledg worker. On n'appréhende qu'un système ou un concept qu'avec le temps, qu'avec sa manipulation. Parfois ceci change complètement notre vision par rapport à la vision initiale. C'est la même chose pour l'API et le découpage du code, c'est souvent à la fin de projet qu'on a une idée plus claire de comment il aurait fallu faire…
Et c'est bien le problème que tente d'adresser les méthodes agiles.
Tout d'abord merci pour ce journal, je trouve vraiment intéressant de prendre du recul comme ça. De plus le développement de projet au forfait n'est vraiment pas un métier facile.
Les API bien faite c'est vraiment le Graal, ce qui rende le produit évolutif et perso je pense qu'il faut au contraire pouvoir les casser pour arriver petit à petit à la bonne convergence. Seule règle que je trouve intéressante : les API de haut niveau devrait parler en langage métier (utiliser les mots / les concepts) c'est ce qui bougera le moins. Bien sur on a souvent besoin d'aller dans plus de détails technique (par exemple on a pas seulement des utilisateurs mais on doit se connecter à une BDD ou un LDAP…) doivent la encore refléter le mots de cet univers technique et si possible être dé-corrélées.
Concernant les tests, j'ai déjà essayé de faire des tests qui produisaient en sorti un scénario : je suis tel utilisateur, je fais ça puis ça, il se passe ça, etc… j'ai vu que malheureusement, comme j'ai dit dans un commentaire précédent, les clients n'ont souvent pas la volonté de vérifier tout ça ou pas la compétence d'en vérifier la cohérence. Le dialogue de personne à personne, l'écoute et l'intuition du besoin et du métier, la capacité de raisonnement et de créativité restent souvent les meilleurs facteurs de succès.
Le découpage en responsabilité et composants est également important et là encore très difficile à juger du premier coup. Par exemple je pourrais souvent, au début, mettre utilisateurs, groupes et permissions ensemble, mais si ça se complexifié ça devient un poids. De plus il faut éviter les dépendances croisées (A dépend de B qui dépend de A) qui sont une plaie pour les évolutions (il faut un A' qui dépend de A et B et éventuellement un B' qui dépend aussi de A et B) mais c'est très difficile de prendre la décision de refactorer au bon moment. Car sinon on va être dans l'over-engineering. Mais en pratique on se rend souvent compte trop tard, qu'à force d'entorses, on aurait dû séparer en plusieurs responsabilités. C'est de la dette technique et peu de client acceptent de payer pour ça (ou il faut vraiment une relation de confiance).
Tout cela sans compter que dans mon expérience sur une équipe de dév il y aura souvent 60% des gens qui n'auront pas une grande attention à ces discours, les trouverons obscurs ou superflus, ou simplement auront une petit flemme de bien faire et ne suivront donc que partiellement ces consignes…
Bref, je ne pense pas qu'il y ai de silver bullet. Par contre effectivement avoir une personne qui, dans l'équipe, tient l'œil sur ces points, mener des réflexions ensemble là dessus, est toujours intéressant et peut porter à un mieux.
En fait mon expérience perso est que ce qui bouffe pas mal du temps dans la conception d'un projet c'est que le développeur n'est pas seulement un codeur (un traducteur en code machine) mais extrêmement souvent le gardien de la logique et de la cohérence de l'application. Il doit perdre du temps à expliquer au client pourquoi telle ou telle chose n'est pas souhaitable, lui montrer les incohérence qu'elle produit etc. (et c'est long et difficile, ce qui explique que parfois il n'a plus trop envie de communiquer avec le client et cherche à répondre lui même au questions comme noté dans la technique n°1). Perso je pense que le plus gros gain de temps (et de confort) c'est quand on a un client qui a un esprit logique et ne rebute pas à affronter les problèmes. (On pourrait imaginer un test de logique fait au client avant de lui fournir un devis :-P), et en tout cas un dialogue fluide (réactivité aux questions / réponses, points régulier) est plus qu'indispensable.
Ceci dit la technique n°3 (commencer/prototyper les interfaces) est sûrement intéressante (mais peut conduire à des promesses ensuite difficile à tenir, quand on a occulté une difficulté technique).
Sans l'avoir utilisé, je trouve la liste de nouvelles fonctionnalités intéressante car elles étaient attendues de ma part. Je suis ravi en particulier de savoir qu'il y a une meilleure gestion de la couleur, enfin ! Les styles de tableau c'est aussi utile. Les styles en preview, ça peut aider à les repérer rapidement visuellement et à rendre la fonctionnalité plus intuitive pour les utilisateurs moins aguerris.
Perso après avoir utilisé Ansible sur un projet important. Je me trouve un peu limité par ce qu'il propose avec YAML / Jinja (pour les itérations, les valeurs par défaut, etc…). Et, détail, je suis un peu perdu dans mon éditeur avec 100 fichiers qui s'appellent main.yaml !
pyinfra reprend la structure et les termes de Ansible, mais les fichiers sont en python. On a aussi l'aspect idempotent. Je trouve ça vraiment tentant (mais n'ai pu encore tester).
Un autre aspect intéressant est que contrairement à Ansible, il envoie des commandes shell (et non uniquement des scripts python exécutés sur la machine distance comme Ansible) ce qui semble plus efficace pour pas mal de tâches simples.
Je ne sais pas si l'un de vous à pu tester sur des projets un peu importants ?
Un problème en français c'est qu'on ne peut pas (ou on n'ai pas habitué à) coller les mots côte à côte comme en anglais. Nuag-ique ça devient un peu pompeux (et c'est un néologisme) au lieu de juste informatique nuage.
À notre que le cloud computing est venu de Amazon à un moment où coté universitaires ont parlait du grid computing (avoir de la puissance de calcul comme on a de l'électricité). On pourrait voir le cloud comme la réponse des ingénieurs (de chez Amazon) a ces concepts fumeux qui semblait devoir mettre 300 ans à émerger…
Perso j'ai toujours admiré l'avance incroyable de Amazon quand ils ont lancé ce concept (et c'était tout de suite concret avec EC2). Google a essayé de suivre rapidement avec Google App Engine. Et en parallèle on a commencé à avoir le lavage marketing du terme : tout ceux qui ne faisait pas de Cloud et étaient à des années d'en faire (genre Microsoft ou Orange), on commencé à dire qu'ils faisait du Cloud, en confondant service mutualisé et Cloud. Les hébergeurs vendaient leur VPS comme "Cloud", et ce genre de confusion continue encore aujourd'hui.
Comme tout les technologies qui suivent le Cycle du hype, la techno en elle même a des cas d'usage, mais n'est pas forcément utile pour toutes les applications. Elle est clairement utile pour des services avec pleins d'utilisateurs: le rêve de beaucoup de startup et la réalité de peu d'entre elles.
Perso je trouve ça intéressant aussi pour le serveur à serveur. Si on veut un web décentralisé, il faudra certainement explorer ces techniques où la charge est répartie de serveur en serveur, surtout si les accès sont contrôlés (ainsi je peux faire ma recherche dans mes documents du boulot, ceux de mon projet open-source et ceux de mon groupe d'activiste pour le contrôle des chats pour internet).
Oui c'est exactement ce genre d'abus qui a rendu impopulaire XML.
Perso je trouve XSLT immonde par exemple (utiliser XML pour faire un langage de programmation), mais je sais qu'il a ses défenseurs. Il y a également l'utilisation de XML pour des fichiers de configurations édités par des humains, qui pourraient par ailleurs être super simples.
Les spécifications de type SOAP ont également joué leur part (comment tout ré-inventer de manière lourde et imbuvable).
En soit XML c'est bien qu'en on en a des problématique qui s'y prêtent (j'apprécie en particulier les espaces de noms), mais si c'est pour une édition par des humains, je préfère YAML.
En particulier pour RDF je préfère des notations plus simples.
En effet d'un coté je suis assez à l'aise avec vim, mais j'utilise plutôt Geany au quotidien, pour le coté "capacité de découverte" justement, n'étant pas fan de passer ma vie dans les manuels.
Là le coté interactif, l'auto-complétion etc… me donne envie d'essayer.
J'avoue que perso je me réjouis plus de l'enrichissement de la barre latérale, et je trouve qu'elle a vraiment amélioré ma productivité.
Coté ruban, je ne vois vraiment pas l'intérêt d'encombrer l'écran en hauteur, alors que les écrans sont majoritairement en 16/9, et que le A4 est plus haut que large.
Le ruban apporte certes le groupe de fonctionnalité et une taille d'icône proportionnelle à la fréquence d'utilisation. Mais j'avoue que n'utilisant pas fréquemment MS Office, j'ai du mal à trouver ce que je veux, la logique de placement n'étant pas du tout intuitive pour moi (qui suis pourtant un utilisateur assez avancé des suites bureautiques).
J'espère quand même qu'il y aura une certaine logique entre le ruban et la barre latérale.
Ok mais OpenAI n'est pas du tout NVidia que je sache, voir OpenAI
Un des fondateur est Elon Musk.
Nvidia se fait un coup de pub en leur offrant leur très jolie bête (la puissance de calcul est juste énorme), eux vont l'utiliser pour faire tourner des simulations qui à priori utilise du logiciel libre (pas que vu que déjà le driver Nvidia sera sûrement proprio).
Le but d'OpenAI (au moins dans la déclaration, hein) est de collaborer de manière ouverte (brevets, publications et plus), pour la création d'une intelligence artificielle ([voir ici].
Nvidia est malheureusement très propriétaire, mais les bibliothèques libres de deep learning comme Keras, Theano ou TensorFlow sont souvent utilisés avec CUDA, le langage spécifique Nvidia, car son concurrent ouvert OpenCL est malheureusement un peu à la ramasse et moins implémenté, en tout cas pas sur du matériel de ce calibre (ni même des choses un peu plus modeste comme une carte TitanX).
Pour le reste (compte github etc…), relis mon post ci-dessus !
Pour info OpenAI c'est ceux qui font OpenAI gym une invitation à coder des IA pour résoudre des jeux.
J'ai pas vérifié dans les détails mais normalement tout ce qu'ils font est OpenSource. (compte github)
Une des dernières choses que j'ai vu passer d'eux est universe.
Je ne sais pas si quelqu'un, par ici, a déjà expérimenté tout ça ?
A la limite dire que ce n'est pas très fair-play, OK, mais il ne faut pas aller plus loin.
C'est ce que je voulais exprimer. Mais effectivement je suis allé légèrement plus loin en donnant une connotation négative au fait que ça risquait de déséquilibrer un éco-système. Mais effectivement une crise peut aussi être un moment de maturation et consolidation (par exemple les acteurs commerciaux autour de Joomla! vont devoir faire un choix clair pour le libre (pour info, le nom de la fondation qui s'occupe de Joomla! est Open Source Matters) ou consolider les modèles économiques…
le libre ne dit rien sur le futur (MAJ, support…)
Ok je te suis sur le fait que les mise à jour n'ont pas forcément à être gratuites, mais bien, elles aussi, GPL.
Après il y a la lettre de la loi et l'esprit de la loi… c'est un équilibre difficile, car si l'on donne trop d'importance à "l'esprit" on tombe dans l'arbitraire, mais si on ne reste que sur la lettre on risque de louper l'ajustement au réel. Mais effectivement parfois on sur-interprète l'esprit où on y mêle d'autres idées, peut être bonnes mais pas liées et qui donc n'entre pas dans le consensus autour d'un concept, ici le logiciel libre.
Je suis désolé que tu ais un ton si agressif !
Perso je n'ai jamais parlé de warez ou défendu qui parlait de ça…
Relis calmement, et relis aussi le contenu du journal. L'un ne va pas sans l'autre.
Tu forces vraiment le trait. Ce n'est pas parce-que j'ai argumenté dans un sens que je suis 100% d'accord avec ce que dit le journal ou le commentaire initial. (c'est en ce sens que j'ai une impression d'agressivité).
Tu m'attribue des positions qui ne sont pas les miennes !
ce n'est pas parce-qu'une chose est possible qu'elle est souhaitable.
et c'est la où je réagis : tu donnes un droit et après dit que ce n'est pas souhaitable que ce droit soit utilisé, vraiment? C'est bien ma critique de ton commentaire : pour toi, donner de droits c'est juste pour faire joli mais tu ne souhaites pas que ce droit soit utilisé, je trouve ça juste faux-cul.
Désolé mais je ne te donnes pas entièrement raison. Le droit est avant tout une garantie, tu pourras l'utiliser pour éviter des situations injuste (par exemple les prix de l'abonnement deviennent exorbitants, ou des mises à jour de sécurité manquent) mais tu peux aussi décider de ton comportement pour rendre le monde plus juste (ex: je trie mes déchets même si j'ai le droit de ne pas le faire).
Ceci dit je comprends aussi ce que tu veux dire, ce n'est pas tabou et je suis d'accord que l'espèce de contrat tacite/statut-quo (téléchargement payant mais licence libre) n'est pas très robuste, et que faire payer les mise à jour n'est pas non plus très en accord avec la philosophie du libre.
il me semble que la force de la clé se mesure dans son nombre de bits mais aussi dans sa non-prédictibilité,c'est le coté aléatoire de la force
La «force» de la clé, dans le sens la difficulté à la cassée, est effectivement lié (entre autre) au nombre de bits, mais normalement GnuPG choisis déjà un nombre de bits suffisant. Ensuite je ne sais pas ce que tu entends pas "coté aléatoire de la force", mais pour générer un clef, il faut effectivement une source d'aléa qui souvent, pour aller plus vite, est combinée avec un générateur de nombre pseudo-aléatoires (obtenu par des opérations mathématiques chaotiques). Pour une utilisation personnelle (on ne génère une clef que de temps en temps), ce que propose un PC est plus que suffisant. Mais bien sur on se rappelle que Debian avait eu un bug dans le générateur pseudo-aléatoire.
la longueur de la clé dépend de la loi de moore
Oui, dans le sens où pour casser un clé (découvrir la clé secrète à partir de la clé publique) en force brute, c'est une affaire de puissance de calcul. Mais il y a aussi des algorithme différents qui peuvent être plus difficiles à casser.
quelle est la confiance dans le programme qui génère cette clé ?
La confiance doit être absolument totale. C'est pour cela qu'il n'y a de vrai confiance qu'avec un logiciel libre, suffisamment populaire pour avoir été audité, dont la signature a été vérifiée après téléchargement.
En ce sens quand WhatsApp, par exemple, chiffre les communications, rien ne me dit qu'il n'ont pas mon certificat, puisque c'est leur logiciel propriétaire qui me le fournit.
Je suis désolé que tu ais un ton si agressif !
Perso je n'ai jamais parlé de warez ou défendu qui parlait de ça…
Je suis complètement d'accord que c'est dans les conditions du libre de pouvoir faire un magasin alternatif et je n'ai jamais clamé qu'il y avait quelque chose d'illégal. J'ai parlé de fair-play, notion à rapprocher plutôt de politesse où savoir vivre, qui n'est aucunement une obligation légale.
Il n'empêche que l'action de faire un club des club, peut déséquilibrer un éco-système et que ce n'est pas parce-qu'une chose est possible qu'elle est souhaitable. Et en l'occurrence les intentions semble bien mercantiles, mais je redis c'est tout à fait possible en effet.
Après moi je ne suis absolument pas impliqué dans la communauté Joomla! et je suis plutôt curieux de voir ce qu'il va se passer.
# Traversée de NAT avec pagekite
Posté par Alex G. . En réponse au journal Aide à distance. Évalué à 4. Dernière modification le 15 mars 2017 à 21:40.
Tu as un petit logiciel open source qui permet la traversée de NAT : pagekite
L'auteur te propose un hébergement sur abonnement, mais c'est opensource
Tu peux assez facilement le coupler à VNC. Par contre je n'ai pas testé.
PS: c'est équivalent à utiliser un VPN sur un serveur publique par contre.
[^] # Re: Petits outils pratiques
Posté par Alex G. . En réponse à la dépêche L’expression graphique sous GNU/Linux. Évalué à 1. Dernière modification le 13 mars 2017 à 14:45.
Ah je connaissais pas. Perso, j'utilise agave pour ça.
[^] # Re: il en manque
Posté par Alex G. . En réponse au journal Réduire les salaires sans sacrifier la qualité. Évalué à 2.
Attention toutefois que dans certains cas l'employé n'a pas vraiment la maîtrise de tous les paramètres qui lui permettrait de faire valoir son droit.
Par exemple, je dois réussir un projet dans les temps mais mon employeur lui même met des battons dans les roues ou change les spécifications sans arrêt.
[^] # Re: Hypothèse fondamentale discutable
Posté par Alex G. . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 2.
Tu as raison. Ceci dit suivant la capacité / rapidité de compréhension du client, tu as parfois l'impression de "perdre" (surtout dans les cas ou tu es au forfait en fait…)
Mais ceci dit j'aime aussi la discussion avec les gens qui ont une "autre logique", ça amène aussi à se reposer parfois des questions plus fondamentales, alors qu'on était prisonnier d'un détail logique. Ça amène aussi des découvertes par sérendipité (une réponse illogique qui amène à se rendre compte que le besoin est un autre).
[^] # Re: Découpages, responsabilités et API
Posté par Alex G. . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 1.
Ah oui j'oubliais de dire que tout cela est aussi inhérent à ce que je nomme "métier de la connaissance" (voir Knowledg worker. On n'appréhende qu'un système ou un concept qu'avec le temps, qu'avec sa manipulation. Parfois ceci change complètement notre vision par rapport à la vision initiale. C'est la même chose pour l'API et le découpage du code, c'est souvent à la fin de projet qu'on a une idée plus claire de comment il aurait fallu faire…
Et c'est bien le problème que tente d'adresser les méthodes agiles.
# Découpages, responsabilités et API
Posté par Alex G. . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 1.
Tout d'abord merci pour ce journal, je trouve vraiment intéressant de prendre du recul comme ça. De plus le développement de projet au forfait n'est vraiment pas un métier facile.
Les API bien faite c'est vraiment le Graal, ce qui rende le produit évolutif et perso je pense qu'il faut au contraire pouvoir les casser pour arriver petit à petit à la bonne convergence. Seule règle que je trouve intéressante : les API de haut niveau devrait parler en langage métier (utiliser les mots / les concepts) c'est ce qui bougera le moins. Bien sur on a souvent besoin d'aller dans plus de détails technique (par exemple on a pas seulement des utilisateurs mais on doit se connecter à une BDD ou un LDAP…) doivent la encore refléter le mots de cet univers technique et si possible être dé-corrélées.
Concernant les tests, j'ai déjà essayé de faire des tests qui produisaient en sorti un scénario : je suis tel utilisateur, je fais ça puis ça, il se passe ça, etc… j'ai vu que malheureusement, comme j'ai dit dans un commentaire précédent, les clients n'ont souvent pas la volonté de vérifier tout ça ou pas la compétence d'en vérifier la cohérence. Le dialogue de personne à personne, l'écoute et l'intuition du besoin et du métier, la capacité de raisonnement et de créativité restent souvent les meilleurs facteurs de succès.
Le découpage en responsabilité et composants est également important et là encore très difficile à juger du premier coup. Par exemple je pourrais souvent, au début, mettre utilisateurs, groupes et permissions ensemble, mais si ça se complexifié ça devient un poids. De plus il faut éviter les dépendances croisées (A dépend de B qui dépend de A) qui sont une plaie pour les évolutions (il faut un A' qui dépend de A et B et éventuellement un B' qui dépend aussi de A et B) mais c'est très difficile de prendre la décision de refactorer au bon moment. Car sinon on va être dans l'over-engineering. Mais en pratique on se rend souvent compte trop tard, qu'à force d'entorses, on aurait dû séparer en plusieurs responsabilités. C'est de la dette technique et peu de client acceptent de payer pour ça (ou il faut vraiment une relation de confiance).
Tout cela sans compter que dans mon expérience sur une équipe de dév il y aura souvent 60% des gens qui n'auront pas une grande attention à ces discours, les trouverons obscurs ou superflus, ou simplement auront une petit flemme de bien faire et ne suivront donc que partiellement ces consignes…
Bref, je ne pense pas qu'il y ai de silver bullet. Par contre effectivement avoir une personne qui, dans l'équipe, tient l'œil sur ces points, mener des réflexions ensemble là dessus, est toujours intéressant et peut porter à un mieux.
[^] # Re: Hypothèse fondamentale discutable
Posté par Alex G. . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 2.
En fait mon expérience perso est que ce qui bouffe pas mal du temps dans la conception d'un projet c'est que le développeur n'est pas seulement un codeur (un traducteur en code machine) mais extrêmement souvent le gardien de la logique et de la cohérence de l'application. Il doit perdre du temps à expliquer au client pourquoi telle ou telle chose n'est pas souhaitable, lui montrer les incohérence qu'elle produit etc. (et c'est long et difficile, ce qui explique que parfois il n'a plus trop envie de communiquer avec le client et cherche à répondre lui même au questions comme noté dans la technique n°1). Perso je pense que le plus gros gain de temps (et de confort) c'est quand on a un client qui a un esprit logique et ne rebute pas à affronter les problèmes. (On pourrait imaginer un test de logique fait au client avant de lui fournir un devis :-P), et en tout cas un dialogue fluide (réactivité aux questions / réponses, points régulier) est plus qu'indispensable.
Ceci dit la technique n°3 (commencer/prototyper les interfaces) est sûrement intéressante (mais peut conduire à des promesses ensuite difficile à tenir, quand on a occulté une difficulté technique).
[^] # Re: juste une remarque
Posté par Alex G. . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 1.
Pas forcément, si c'est les valeur RVB : 62, 191, 151 est bleu :-P
[^] # Re: Mouais
Posté par Alex G. . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 1.
Tu confonds pas gnome-terminal et GNOME shell ?
# Fonctionnalité intéressantes
Posté par Alex G. . En réponse à la dépêche Sortie de LibreOffice 5.3. Évalué à 7.
Sans l'avoir utilisé, je trouve la liste de nouvelles fonctionnalités intéressante car elles étaient attendues de ma part. Je suis ravi en particulier de savoir qu'il y a une meilleure gestion de la couleur, enfin ! Les styles de tableau c'est aussi utile. Les styles en preview, ça peut aider à les repérer rapidement visuellement et à rendre la fonctionnalité plus intuitive pour les utilisateurs moins aguerris.
# PyInfra
Posté par Alex G. . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 2.
Perso après avoir utilisé Ansible sur un projet important. Je me trouve un peu limité par ce qu'il propose avec YAML / Jinja (pour les itérations, les valeurs par défaut, etc…). Et, détail, je suis un peu perdu dans mon éditeur avec 100 fichiers qui s'appellent main.yaml !
pyinfra reprend la structure et les termes de Ansible, mais les fichiers sont en python. On a aussi l'aspect idempotent. Je trouve ça vraiment tentant (mais n'ai pu encore tester).
Un autre aspect intéressant est que contrairement à Ansible, il envoie des commandes shell (et non uniquement des scripts python exécutés sur la machine distance comme Ansible) ce qui semble plus efficace pour pas mal de tâches simples.
Je ne sais pas si l'un de vous à pu tester sur des projets un peu importants ?
[^] # Re: "Le Cloud Computing" (ou Infonuagique en français)
Posté par Alex G. . En réponse au journal C'est quoi le "cloud computing" ? 1/2. Évalué à 1.
Un problème en français c'est qu'on ne peut pas (ou on n'ai pas habitué à) coller les mots côte à côte comme en anglais. Nuag-ique ça devient un peu pompeux (et c'est un néologisme) au lieu de juste informatique nuage.
[^] # Re: Cloud et Grid
Posté par Alex G. . En réponse au journal C'est quoi le "cloud computing" ? 1/2. Évalué à 1.
En fait je suis d'accord avec toi, je plaçais plus ou moins Google et Amazon dans la même catégorie (mais Amazon a inventé le concept commercial).
# Cloud et Grid
Posté par Alex G. . En réponse au journal C'est quoi le "cloud computing" ? 1/2. Évalué à 5.
À notre que le cloud computing est venu de Amazon à un moment où coté universitaires ont parlait du grid computing (avoir de la puissance de calcul comme on a de l'électricité). On pourrait voir le cloud comme la réponse des ingénieurs (de chez Amazon) a ces concepts fumeux qui semblait devoir mettre 300 ans à émerger…
Perso j'ai toujours admiré l'avance incroyable de Amazon quand ils ont lancé ce concept (et c'était tout de suite concret avec EC2). Google a essayé de suivre rapidement avec Google App Engine. Et en parallèle on a commencé à avoir le lavage marketing du terme : tout ceux qui ne faisait pas de Cloud et étaient à des années d'en faire (genre Microsoft ou Orange), on commencé à dire qu'ils faisait du Cloud, en confondant service mutualisé et Cloud. Les hébergeurs vendaient leur VPS comme "Cloud", et ce genre de confusion continue encore aujourd'hui.
Comme tout les technologies qui suivent le Cycle du hype, la techno en elle même a des cas d'usage, mais n'est pas forcément utile pour toutes les applications. Elle est clairement utile pour des services avec pleins d'utilisateurs: le rêve de beaucoup de startup et la réalité de peu d'entre elles.
[^] # Re: Euh ???
Posté par Alex G. . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 1.
Perso je trouve ça intéressant aussi pour le serveur à serveur. Si on veut un web décentralisé, il faudra certainement explorer ces techniques où la charge est répartie de serveur en serveur, surtout si les accès sont contrôlés (ainsi je peux faire ma recherche dans mes documents du boulot, ceux de mon projet open-source et ceux de mon groupe d'activiste pour le contrôle des chats pour internet).
[^] # Re: XML sapu et autres billevesées
Posté par Alex G. . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 7.
Oui c'est exactement ce genre d'abus qui a rendu impopulaire XML.
Perso je trouve XSLT immonde par exemple (utiliser XML pour faire un langage de programmation), mais je sais qu'il a ses défenseurs. Il y a également l'utilisation de XML pour des fichiers de configurations édités par des humains, qui pourraient par ailleurs être super simples.
Les spécifications de type SOAP ont également joué leur part (comment tout ré-inventer de manière lourde et imbuvable).
En soit XML c'est bien qu'en on en a des problématique qui s'y prêtent (j'apprécie en particulier les espaces de noms), mais si c'est pour une édition par des humains, je préfère YAML.
En particulier pour RDF je préfère des notations plus simples.
# Wow
Posté par Alex G. . En réponse au journal [Bookmark] Pourquoi Kakoune, la quête d'un meilleur éditeur de code. Évalué à 3.
Ça me donne vraiment envie d'essayer.
En effet d'un coté je suis assez à l'aise avec vim, mais j'utilise plutôt Geany au quotidien, pour le coté "capacité de découverte" justement, n'étant pas fan de passer ma vie dans les manuels.
Là le coté interactif, l'auto-complétion etc… me donne envie d'essayer.
[^] # Re: Décevant
Posté par Alex G. . En réponse au journal LibreOffice fait évoluer son interface. Évalué à 4.
J'avoue que perso je me réjouis plus de l'enrichissement de la barre latérale, et je trouve qu'elle a vraiment amélioré ma productivité.
Coté ruban, je ne vois vraiment pas l'intérêt d'encombrer l'écran en hauteur, alors que les écrans sont majoritairement en 16/9, et que le A4 est plus haut que large.
Le ruban apporte certes le groupe de fonctionnalité et une taille d'icône proportionnelle à la fréquence d'utilisation. Mais j'avoue que n'utilisant pas fréquemment MS Office, j'ai du mal à trouver ce que je veux, la logique de placement n'étant pas du tout intuitive pour moi (qui suis pourtant un utilisateur assez avancé des suites bureautiques).
J'espère quand même qu'il y aura une certaine logique entre le ruban et la barre latérale.
[^] # Re: OpenAI - AI et logiciel libre
Posté par Alex G. . En réponse au journal Un super ordinateur d'IA pour OpenAI. Évalué à 2.
Ah oui, pas con :-)
[^] # Re: OpenAI - AI et logiciel libre
Posté par Alex G. . En réponse au journal Un super ordinateur d'IA pour OpenAI. Évalué à 1.
Ok mais OpenAI n'est pas du tout NVidia que je sache, voir OpenAI
Un des fondateur est Elon Musk.
Nvidia se fait un coup de pub en leur offrant leur très jolie bête (la puissance de calcul est juste énorme), eux vont l'utiliser pour faire tourner des simulations qui à priori utilise du logiciel libre (pas que vu que déjà le driver Nvidia sera sûrement proprio).
Le but d'OpenAI (au moins dans la déclaration, hein) est de collaborer de manière ouverte (brevets, publications et plus), pour la création d'une intelligence artificielle ([voir ici].
Nvidia est malheureusement très propriétaire, mais les bibliothèques libres de deep learning comme Keras, Theano ou TensorFlow sont souvent utilisés avec CUDA, le langage spécifique Nvidia, car son concurrent ouvert OpenCL est malheureusement un peu à la ramasse et moins implémenté, en tout cas pas sur du matériel de ce calibre (ni même des choses un peu plus modeste comme une carte TitanX).
Pour le reste (compte github etc…), relis mon post ci-dessus !
# OpenAI - AI et logiciel libre
Posté par Alex G. . En réponse au journal Un super ordinateur d'IA pour OpenAI. Évalué à 4.
Pour info OpenAI c'est ceux qui font OpenAI gym une invitation à coder des IA pour résoudre des jeux.
J'ai pas vérifié dans les détails mais normalement tout ce qu'ils font est OpenSource. (compte github)
Une des dernières choses que j'ai vu passer d'eux est universe.
Je ne sais pas si quelqu'un, par ici, a déjà expérimenté tout ça ?
[^] # Re: Mauvaise comparaison
Posté par Alex G. . En réponse au journal Joomla et les clubs à abonnement payant. Évalué à 2.
C'est ce que je voulais exprimer. Mais effectivement je suis allé légèrement plus loin en donnant une connotation négative au fait que ça risquait de déséquilibrer un éco-système. Mais effectivement une crise peut aussi être un moment de maturation et consolidation (par exemple les acteurs commerciaux autour de Joomla! vont devoir faire un choix clair pour le libre (pour info, le nom de la fondation qui s'occupe de Joomla! est Open Source Matters) ou consolider les modèles économiques…
Ok je te suis sur le fait que les mise à jour n'ont pas forcément à être gratuites, mais bien, elles aussi, GPL.
Après il y a la lettre de la loi et l'esprit de la loi… c'est un équilibre difficile, car si l'on donne trop d'importance à "l'esprit" on tombe dans l'arbitraire, mais si on ne reste que sur la lettre on risque de louper l'ajustement au réel. Mais effectivement parfois on sur-interprète l'esprit où on y mêle d'autres idées, peut être bonnes mais pas liées et qui donc n'entre pas dans le consensus autour d'un concept, ici le logiciel libre.
[^] # Re: Mauvaise comparaison
Posté par Alex G. . En réponse au journal Joomla et les clubs à abonnement payant. Évalué à 1.
Tu forces vraiment le trait. Ce n'est pas parce-que j'ai argumenté dans un sens que je suis 100% d'accord avec ce que dit le journal ou le commentaire initial. (c'est en ce sens que j'ai une impression d'agressivité).
Tu m'attribue des positions qui ne sont pas les miennes !
Désolé mais je ne te donnes pas entièrement raison. Le droit est avant tout une garantie, tu pourras l'utiliser pour éviter des situations injuste (par exemple les prix de l'abonnement deviennent exorbitants, ou des mises à jour de sécurité manquent) mais tu peux aussi décider de ton comportement pour rendre le monde plus juste (ex: je trie mes déchets même si j'ai le droit de ne pas le faire).
Ceci dit je comprends aussi ce que tu veux dire, ce n'est pas tabou et je suis d'accord que l'espèce de contrat tacite/statut-quo (téléchargement payant mais licence libre) n'est pas très robuste, et que faire payer les mise à jour n'est pas non plus très en accord avec la philosophie du libre.
[^] # Re: prédictibilité et confiance
Posté par Alex G. . En réponse au journal De la confiance dans le monde OpenPGP. Évalué à 1.
La «force» de la clé, dans le sens la difficulté à la cassée, est effectivement lié (entre autre) au nombre de bits, mais normalement GnuPG choisis déjà un nombre de bits suffisant. Ensuite je ne sais pas ce que tu entends pas "coté aléatoire de la force", mais pour générer un clef, il faut effectivement une source d'aléa qui souvent, pour aller plus vite, est combinée avec un générateur de nombre pseudo-aléatoires (obtenu par des opérations mathématiques chaotiques). Pour une utilisation personnelle (on ne génère une clef que de temps en temps), ce que propose un PC est plus que suffisant. Mais bien sur on se rappelle que Debian avait eu un bug dans le générateur pseudo-aléatoire.
Oui, dans le sens où pour casser un clé (découvrir la clé secrète à partir de la clé publique) en force brute, c'est une affaire de puissance de calcul. Mais il y a aussi des algorithme différents qui peuvent être plus difficiles à casser.
La confiance doit être absolument totale. C'est pour cela qu'il n'y a de vrai confiance qu'avec un logiciel libre, suffisamment populaire pour avoir été audité, dont la signature a été vérifiée après téléchargement.
En ce sens quand WhatsApp, par exemple, chiffre les communications, rien ne me dit qu'il n'ont pas mon certificat, puisque c'est leur logiciel propriétaire qui me le fournit.
[^] # Re: Mauvaise comparaison
Posté par Alex G. . En réponse au journal Joomla et les clubs à abonnement payant. Évalué à 2.
Je suis désolé que tu ais un ton si agressif !
Perso je n'ai jamais parlé de warez ou défendu qui parlait de ça…
Je suis complètement d'accord que c'est dans les conditions du libre de pouvoir faire un magasin alternatif et je n'ai jamais clamé qu'il y avait quelque chose d'illégal. J'ai parlé de fair-play, notion à rapprocher plutôt de politesse où savoir vivre, qui n'est aucunement une obligation légale.
Il n'empêche que l'action de faire un club des club, peut déséquilibrer un éco-système et que ce n'est pas parce-qu'une chose est possible qu'elle est souhaitable. Et en l'occurrence les intentions semble bien mercantiles, mais je redis c'est tout à fait possible en effet.
Après moi je ne suis absolument pas impliqué dans la communauté Joomla! et je suis plutôt curieux de voir ce qu'il va se passer.