Je pense très honnêtement que le prochain axe d’amélioration de darktable est là-dessus. Le problème, c’est que les ergonomes dans le monde open-source, c’est rarissime – et ça demande d’être assez résistant pour se prendre les déluges de commentaires de powerusers qui ne supportent pas qu’on supprime ou même qu’on rende un peu plus difficile d’accès des options qu’ils sont les seuls à utiliser, cf le cas de Gnome par exemple.
Ton exemple est intéressant. J'ai un collègue qui est passé de Windows à GNU/Linux (bon ok j'y suis pour quelque chose). Il a essayé différents desktops dont KDE. Je pensais, bidouilleur qu'il est (c'est un power user en puissance), qu'il allait l'adorer avec toutes les capacités et options de cet environnement de bureau … ben non, c'est Cinnamon qui a eu son cœur. Il a préféré, dans le cadre de son boulot, d'avoir un environnement qui lui permet de faire son boulot efficacement et surtout sans fioritures.
Pour aller dans le sens de tes propos, dans les boites où je suis passé, les ergonomes et concepteur d'interfaces étaient plutôt rare et c'était souvent les dev qui bossaient là dessus … avec le résultat que l'on peut imaginer ; on ne s'invente pas designeur comme ça. Et lorsqu'il y en avait, en général leurs travaux étaient peu estimés aussi bien par leur hiérarchie que par les autres dev. Et ils étaient en général mal payés. Donc, je ne suis pas surpris que l'on trouve difficilement des ergonomes ou designeurs dans les projets open-source. N'empêche que c'est par leur contact que j'ai pris connaissance que designeur est un métier à part entière qui ne s'improvise pas … j'ai pu voir à quel point aussi j'avais des goût de chiottes.
Je pense que le soucis de comm' entre Aurélien et certains autres dev de darktable vient ppeut être d'un manque d'organisation structurelle formalisée. Les gros projets ou fondations en open-source ont, pour palier à ce que semble vivre l'équipe darktable, mis en place une organisation afin de faciliter les échanges, les modifs et surtout l'arrivée des nouveaux venus. On peut citer celle de la fondation Apache. Et comme pour tout, une organisation n'est jamais figée dans le marbre, elle change et vit au fur et à mesure qu'un projet ou fondation grossit.
Et que penses tu du fork d'Aurélien Pierre de darktable, r-darktable, en réponse à la lourdeur de l'ergonomie de darktable, en particulier de la table lumineuse ?
Selon ses dires, si j'ai bien compris, l'IHM est actuellement et principalement développé par des personnes qui ne comprennent pas les besoins des photographes et en particulier professionnels (qu'elles semblent même mépriser d'après lui). Elles codent des trucs que personne ne demande ou qui n'adresse aucun pb réel. Or ceci, avec le fait que Gtk est un toolkit d'un âge révolu (mono CPU, pas GPU), + avec une base de données qui est utilisée pour stocker toutes les informations des RAW ainsi que leur catégorisation (alors qu'elle ne devrait être utilisée à la rigueur que comme cache), aboutit à une lourdeur excessive de l'IHM. Par exemple, Aurélien cite qu'à chaque déplacement de souris sur une image, de multiples requêtes SQL ont lieu sur la base de données !
Oui c'est exactement ça (en tout cas c'est ce que j'observe autour de moi et avec moi même) ; on peut dire que c'est l'exercice de la maturité avec l'expérience dans bcp de domaines.
Et comme le disait un ancien collègue :
il est plus simple de faire compliqué mais plus compliqué de faire simple
Désolé je n'ai pas d'exemple concret et ce qui suit est issue de ma mémoire. J'ai la flegme de vérifier, j'ai d'autre chat à fouetter que de débattre sur des sujets sclérosés. Je laisse les autres infirmer ou confirmer mes dires.
De ce que je m'en souvient, la distinction entre libre et open-source viendrait fin des années 90, voir début des années 2000. Pour comprendre, il ne faut pas voir les termes libre et open-source comme un simple qualificatif porté sur du code par une licence.
La différence entre les deux est que, pour résumé succinctement, le libre se veut politique tandis que l'open-source refuse toute considération politique et ne se focalise que sur les aspects techniques/technologiques. Pour donner un exemple qui fâche, les licences BSD ou Apache ne sont pas considérées comme libre mais comme open-source. Par exemple, historiquement, la licence BSD était pour permettre aux étudiants de l'Université de Berkeley de pouvoir, une fois leur diplôme en poche, récupérer leurs travaux pour monter leur propre boite et en faire un produit propriétaire et fermé si besoin est. D'un point de vue purement technique, on peut dire donc que la licence BSD est libre, voir même plus libre que la GPL. Mais ce serait omettre les autres aspects derrière les critères de ces licences et de qui les a faite. La licence GPL, puis AGPL, a été faite avec une arrière pensée politique dans laquelle la (ou les) communauté(s) des dév libre(s) sont à protéger face au monde propriétaire et fermé. Dans la mouvance du libre, le monde du propriétaire est vue comme de l'obscurantisme dans lequel les outils, les techniques et les savoirs sont accaparés en vue d'acquérir du pouvoir sur les autres et de fermer à ceux-ci toute aptitude à l'appropriation, à l'amélioration, bref, au progrès de tous par tous (oui je sais j'y vais fort mais je ne l'invente pas). Le libre est donc idéologique là où l'open-source se veut apolitique.
Autrement dit si un code libre est open-source, un code open-source n'est pas nécessairement libre. Le libre ici ajoute ici une dimension politique.
Je rajoute aussi une petite touche vécue du côté de chez moi, près de Grenoble. Un copain qui habite en montagne a fait l'achat d'une petite voiture électrique (la Zoé pour ne pas la nommer) juste pour pouvoir faire l'aller-retour de chez lui à son boulot dans la vallée. Son autonomie lui permet de ne pouvoir la charger que le soir chez lui pour le lendemain.
Et il y a ce site aussi, un calculateur et comparateur qui permet de connaître le coût en équivalent CO2 de la voiture électrique de sa fabrication à son traitement en fin de vie : https://climobil.connecting-project.lu
Qu'en est-il de l'ajout d'applications, je n'ai pas trouvé de doc expliquant comment créer une application custom
Oui c'est vrai et c'est bien malheureux. C'est ce qui manque peut-être le plus. Pour créer une application pour Silverpeas, le mieux est probablement de s'inspirer d'un projet existant assez récent dans Silverpeas-Components. Il y a SuggestionBox qui est une application assez récente. Sinon Almanach qui a été remaniée pas mal et qui respecte les canons actuels en terme de codage dans Silverpeas.
Le code d'une application de Silverpeas est un projet qui se décompose en trois sous-projets :
- la configuration (sous projet <nom application>-configuration) qui comprend les règles de migration des données en base de données (tables, contraintes, …), le descripteur applicatif (dans le dossier xmlcomponents) qui définit entre autre les paramètres d'instances de l'application, des fichiers de propriétés qui définissent des paramètres de configuration globaux à l'application, le descripteur de logging, etc.
- le code métier (sous projet <nom application>-library)
- et l'IHM Web (sous projet <nom application>-war)
Avec Silverpeas 6, les mises à jour se font assez simplement. Il faut spécifier la nouvelle version dans le fichier $SILVERPEAS_HOME/bin/silverpeas.gradle, par exemple ici la version 6.2 :
/* Silverpeas version to install */version='6.2'...
Puis lancer la commande de mise à jour :
$ ./silverpeas clean install
L'instruction clean est pour nettoyer l'installation précédente et ainsi forcer, avec la commande install, de récupérer, configurer puis installer la version spécifiée dans le fichier silverpeas.gradle.
Maintenant, la mise à jour de Silverpeas 5 à la version 6 requière des manipulations manuelles pour les raisons suivantes :
- le nom de certaines propriétés de configuration et de paramétrage de composants ont changé,
- l'organisation du dossier home de Silverpeas (dossier d'installation) est différente entre les deux versions et requière donc de déplacer des fichiers d'une version vers l'autre avec les modifications nécessaires (point précédent);
- le serveur applicatif d'exécution passe de JBoss 6 à Wildfly >= 8
En général, les organisations qui souhaitent passer d'une version majeur à l'autre demandent une prestation.
Maintenant, pour 50 personnes connectés ensemble, une machine avec 8Go de RAM environ devrait suffire. Pour les CPU, ceux actuels sont largement suffisants. C'est surtout la mémoire qui est importante. Pour ce qui est de l'espace disque, c'est selon la quantité de données qui sera poussée dans Silverpeas.
En effet, pour donner au moulin de quoi moudre, à Grenoble le plus grand danger du cycliste n'est pas la voiture … mais les autres vélos ! En tout cas, c'est comme ça que je le ressent lorsqu'y vais en vélo. Il y en a qui ont du mal à comprendre que lorsqu'il y a du monde sur les pistes cyclables, il faut savoir adapter son coup de pédale. Et je ne parle même pas de certains parents avec leurs enfants à vélo qui les laisse bousculer les autres cyclistes sans rien dire.
Il y a d'ailleurs cette phrase de Graeme W. Gill, l'auteur d'ArgyllCMS et d'ArgyllPro, qui m'a interpellé :
As best I can tell (from the long and unsatisfactory thread I pursed on the Wayland Developers list some little time ago), the core issue with Wayland and Color is social, not technical:
1. none of the key developers have the faintest idea what Color or Color Management is, and (worse): 2. they have no idea why it would be at all important.
C'est de cette discussion qu'Aurélien Pierre faisait, je pense, référence lorsqu'il a parlé du problème de Wayland d'avec la colorimétrie.
Apparemment c'est plus compliqué que juste de la calibration et du profilage colorimétrique … d'ailleurs le problème relèverait plus du profilage puisque c'est lui qui gère les conversions entre espace et profil colorimétrique. En fait, ce serait plus un problème de compréhension de ce que sont les profils ICC, ce que décrivent les espaces colorimétriques, des capacités des écrans et des imprimantes, etc. Il faudrait que je retrouve où Aurélien Pierre en parle de ça (c'est soit sur l'une de ses vidéos sur Youtube, soit dans une de ses réponses dans les forums darktable ou sur pixls ; en tout cas je n'ai pas trouvé dans son blog sur son site photo).
Xorg n'est plus développé ? Dommage pour ceux qui font de la retouche photo ou vidéo sur *BSD ou GNU/Linux parce que les codeurs de Wayland sont à mille lieux des problématiques de colorimétrie ; apparemment, d'après Aurélien Pierre, un des contributeurs de Darktable, ces questions leur passeraient largement au dessus de leur compréhension. Et c'est dommage pour un système graphique …
De mon côté, lorsque je ne télétravaille pas, je fais 27km en vélo (non VAE) pour aller au boulot. Le retour, je le fais en train + vélo (il reste 6km). Lorsqu'il fait mauvais, je vais à la gare en vélo et je prend le train. Bon quand il neige ou quand il tempête, j'avoue je vais prendre le train mais en voiture (si trop de neige, je reste en télétravail) ou je prend le car à 5mn de chez moi.
Sur mon trajet, je croise pas mal de personnes en vélos, surtout par beau temps. Je trouve les VAE formidables :
- je trouve des personnes qui se sont mis à se déplacer en vélo en lieu et place de la voiture grâce aux VAE,
- des copains qui font du VTT de descentes peuvent, entre midi et deux, se faire plaisir parce que l'assistance électrique sur leur VTT leur permet d'aller là où en temps normal ils ne pourraient pas à cause de la contrainte horaire.
- des personnes en difficulté physique ou âgées ont pu (re)prendre plaisir en vélos grâces aux VAE
Ouep, l'enfer des outils de build s'ouvre dès que l'on veut construire un logiciel destiné à plusieurs plate-formes d'exécution. Il y a eu des langages mutli plate-formes qui ont été développées (Lisp, Smalltalk, Java, …) pour éviter, entre autre, ce genre de problèmes, mais ça n'a jamais vraiment marché parce qu'il y a toujours une plate-forme, le vent en poupe, qui ne joue pas leur jeu. Ou alors ça ne rempli pas les contraintes du logiciel (le plus souvent la performance) sur une ou plusieurs plate-formes cibles (mais ce critère relève peu ou prou aussi du premier, à savoir de jouer le jeu ; voir l'exemple raté des machines Lisp).
Dans mon cas, après avoir développé en C++ jusqu'en 2003 où on utilisait massivement des Makefiles, je me suis mis à Java jusqu'à encore aujourd'hui. Au début, on utilisait Ant (qui, comme tu l'as si bien écris, est du Makefile en XML). Maintenant on utilise Maven et bien que non exempte de défauts, je trouve que c'est un outil formidable surtout sur des gros, très gros projets ou lorsque les projets sont composés de plusieurs langages et ressources (Java, Groovy, Javascript, CSS, …). On utilise aussi du Gradle mais là c'est plus comme base pour concevoir des installateurs et configurateurs d'applications sur serveurs que comme système de build. A côté de ça je fais aussi un peu d'Haskell. Ce dernier a son propre outil de build (pardon ses propres outils de build) et ce n'est pas plus mal (j'adore slack). Les pires systèmes de build que j'ai pu utiliser restent quand même ceux du monde Javascript … Le meilleur que j'ai trouvé est celui du monde Smalltalk : il n'y en a pas ! Ou plus exactement, comme il ne s'appuie pas sur une approche de programmation et de construction orientée fichier, les problèmes adressés ne sont pas les mêmes et, au regard de ma piètre expérience avec, j'ai m'y suis pris beaucoup moins la tête. Mais je m'égare …
Pour répondre à ta question, dans mon ancienne boite, j'ai vu des équipes qui développaient des projets multi plate-formes (desktop, mobile Androïd, …) utiliser Maven comme outil de build centralisé. Par contre, ne m'étant jamais vraiment intéressé à ce problème, je ne leur ai jamais demandé leur retour là dessus. En tout cas, il semble qu'il existe des plugins Maven pour construire des projets iOS : j'ai trouvé ça https://github.com/letsdev/maven-ios-plugin
Est ce que finalement ce qui arrive à grenouille.com et autres sites dits communautaires n'est pas tout simplement le symptôme du consumérisme coloré d'individualisme exacerbé, associé au tout centralisé sur le Web (GAFA like) ?
A la lecture de la dépêche, si je comprend bien :
- on a des VM modèles qui définissent un environnement GNU/Linux minimal
- à partir d'un de ces modèles, on peut avoir un environnement virtuel plus complet comprenant un ensemble de programmes précis
- à partir des ces environnement, on peut lancer des programmes eux même dans une VM à part
Je suppute, du fait de la lourdeur inhérentes aux VM, que QubesOS se destine avant tout aux serveurs.
Pourquoi QubesOS repose t'il sur une architecture à VM ? Pourquoi pas plutôt sur une architecture à conteneurs (LXC, docker, …) qui est bien plus légère ? Qu'est ce que de nos jours une telle approche apporte comparée à celles des conteneurs ?
Et que pensez vous de keybase ?
S'il ne génère pas de mots de passe, on peut les stocker (ils sont chiffrés par le biais d'une pair de clé publique/privée) et même les partager avec d'autres personnes ; intéressant dans le cas d'associations où des crédences peuvent être communes à plusieurs personnes attitrées (pour le site web, la banque en ligne, etc.)
Malgré que le ton de ton commentaire me heurte, m'agresse, après un moment à prendre du recul face à celui-ci, je dois avouer que tu as raison.
Quitte à réaliser un paquet de test (qu'il soit sous forme d'un installateur ou d'une image Docker), autant le faire avec un jeu de données initiales, aussi succincte qu'il soit, qui permet d'avoir une idée rapide du logiciel. Je prend en compte ce point et je prendrai du temps pour le faire (bon, le temps c'est ce que j'ai peu et donc ça risque d'attendre quelques jours/semaines avant que ce soit fait)
ça me fait penser à un équivalent de Sharepoint … ce qui répond à des usages particuliers et nécessite beaucoup de temps pour être déployé
Bon si effectivement Sharepoint est un concurrent à Silverpeas, dire qu'il faut beaucoup de temps pour le déployer est, à mon humble opinion, très exagéré.
Rien qu'en suivant le Dockerfile, à défaut de la page d'installation de Silverpeas 6.0, qui sert à construire une image Docker de Silverpeas, permet d'avoir un aperçu rapide de ce qu'il en est. Il ne reste ensuite plus qu'à installer une base de données (avec PostgreSQL par exemple) et y reporter les paramètres de configuration dans un fichier $SILVERPAS_HOME/configuration/config.properties. Là de base, tu as un Silverpeas qui marche et qui soit utilisable.
Ensuite, certes, il faut ensuite se connecter en tant qu'administrateur, aller dans le back-office (Administration) afin de commencer à ajouter des utilisateurs, à créer des espaces de collaboration/de travail et y instancier des applications. Mais tout cela se fait facilement. De toute façon, c'est une étape nécessaire comme avec tous les outils de ce genre : paramétrer l'application à tes besoins.
Je ne connais pas le portail e-sup et ne saurait donc te répondre là dessus. Mais effectivement Silverpeas est un portail couplé à des applications de style GED, moteur de blog, de forum, et ainsi de suite. Ce sont par eux que les utilisateurs poussent de l'information et collaborent. Dans le cadre de Silverpeas, ces applications ne sont pas des programmes extérieurs mais des composants logiciels réalisés au-dessus du socle technique et métier de Silverpeas (Silverpeas Core) et donc sont des applications (fortement) intégrés.
Oui tu peux utiliser Silverpeas pour ton groupe de rock.
Pour te faire une idée, tu peux récupérer Silverpeas via l'installateur IzPack et l'essayer. Ensuite, si tu veux aller plus loin, il vaut mieux alors d'utiliser directement la distribution (l'archive zip avec le programme d'installation, de configuration et de lancement) ou l'image docker de Silverpeas. Il y a aussi un groupe de discussion si tu as besoins d'infos ou si tu as des problèmes (http://groups.google.com/group/silverpeas-users)
[^] # Re: r-darktable
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Sortie de darktable 4.0.0 : une présentation 100 % subjective. Évalué à 7.
Ton exemple est intéressant. J'ai un collègue qui est passé de Windows à GNU/Linux (bon ok j'y suis pour quelque chose). Il a essayé différents desktops dont KDE. Je pensais, bidouilleur qu'il est (c'est un power user en puissance), qu'il allait l'adorer avec toutes les capacités et options de cet environnement de bureau … ben non, c'est Cinnamon qui a eu son cœur. Il a préféré, dans le cadre de son boulot, d'avoir un environnement qui lui permet de faire son boulot efficacement et surtout sans fioritures.
Pour aller dans le sens de tes propos, dans les boites où je suis passé, les ergonomes et concepteur d'interfaces étaient plutôt rare et c'était souvent les dev qui bossaient là dessus … avec le résultat que l'on peut imaginer ; on ne s'invente pas designeur comme ça. Et lorsqu'il y en avait, en général leurs travaux étaient peu estimés aussi bien par leur hiérarchie que par les autres dev. Et ils étaient en général mal payés. Donc, je ne suis pas surpris que l'on trouve difficilement des ergonomes ou designeurs dans les projets open-source. N'empêche que c'est par leur contact que j'ai pris connaissance que designeur est un métier à part entière qui ne s'improvise pas … j'ai pu voir à quel point aussi j'avais des goût de chiottes.
Je pense que le soucis de comm' entre Aurélien et certains autres dev de darktable vient ppeut être d'un manque d'organisation structurelle formalisée. Les gros projets ou fondations en open-source ont, pour palier à ce que semble vivre l'équipe darktable, mis en place une organisation afin de faciliter les échanges, les modifs et surtout l'arrivée des nouveaux venus. On peut citer celle de la fondation Apache. Et comme pour tout, une organisation n'est jamais figée dans le marbre, elle change et vit au fur et à mesure qu'un projet ou fondation grossit.
# r-darktable
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Sortie de darktable 4.0.0 : une présentation 100 % subjective. Évalué à 8. Dernière modification le 11 juillet 2022 à 09:58.
Et que penses tu du fork d'Aurélien Pierre de darktable, r-darktable, en réponse à la lourdeur de l'ergonomie de darktable, en particulier de la table lumineuse ?
Selon ses dires, si j'ai bien compris, l'IHM est actuellement et principalement développé par des personnes qui ne comprennent pas les besoins des photographes et en particulier professionnels (qu'elles semblent même mépriser d'après lui). Elles codent des trucs que personne ne demande ou qui n'adresse aucun pb réel. Or ceci, avec le fait que Gtk est un toolkit d'un âge révolu (mono CPU, pas GPU), + avec une base de données qui est utilisée pour stocker toutes les informations des RAW ainsi que leur catégorisation (alors qu'elle ne devrait être utilisée à la rigueur que comme cache), aboutit à une lourdeur excessive de l'IHM. Par exemple, Aurélien cite qu'à chaque déplacement de souris sur une image, de multiples requêtes SQL ont lieu sur la base de données !
Des liens :
- son coup de gueule sur le dév actuel de l'IHM de darktable : https://www.youtube.com/watch?v=56e5Yc-IQ84
- l'explication de pourquoi son fork : https://github.com/aurelienpierre/R-Darktable/wiki/Why-a-fork-%3F
[^] # Re: Adage
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Software architecture considered harmful. Évalué à 8.
Oui c'est exactement ça (en tout cas c'est ce que j'observe autour de moi et avec moi même) ; on peut dire que c'est l'exercice de la maturité avec l'expérience dans bcp de domaines.
Et comme le disait un ancien collègue :
[^] # Re: Désinformation
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Conférence « Les libertés du logiciel et du matériel » avec Richard Stallman. Évalué à 10.
Désolé je n'ai pas d'exemple concret et ce qui suit est issue de ma mémoire. J'ai la flegme de vérifier, j'ai d'autre chat à fouetter que de débattre sur des sujets sclérosés. Je laisse les autres infirmer ou confirmer mes dires.
De ce que je m'en souvient, la distinction entre libre et open-source viendrait fin des années 90, voir début des années 2000. Pour comprendre, il ne faut pas voir les termes libre et open-source comme un simple qualificatif porté sur du code par une licence.
La différence entre les deux est que, pour résumé succinctement, le libre se veut politique tandis que l'open-source refuse toute considération politique et ne se focalise que sur les aspects techniques/technologiques. Pour donner un exemple qui fâche, les licences BSD ou Apache ne sont pas considérées comme libre mais comme open-source. Par exemple, historiquement, la licence BSD était pour permettre aux étudiants de l'Université de Berkeley de pouvoir, une fois leur diplôme en poche, récupérer leurs travaux pour monter leur propre boite et en faire un produit propriétaire et fermé si besoin est. D'un point de vue purement technique, on peut dire donc que la licence BSD est libre, voir même plus libre que la GPL. Mais ce serait omettre les autres aspects derrière les critères de ces licences et de qui les a faite. La licence GPL, puis AGPL, a été faite avec une arrière pensée politique dans laquelle la (ou les) communauté(s) des dév libre(s) sont à protéger face au monde propriétaire et fermé. Dans la mouvance du libre, le monde du propriétaire est vue comme de l'obscurantisme dans lequel les outils, les techniques et les savoirs sont accaparés en vue d'acquérir du pouvoir sur les autres et de fermer à ceux-ci toute aptitude à l'appropriation, à l'amélioration, bref, au progrès de tous par tous (oui je sais j'y vais fort mais je ne l'invente pas). Le libre est donc idéologique là où l'open-source se veut apolitique.
Autrement dit si un code libre est open-source, un code open-source n'est pas nécessairement libre. Le libre ici ajoute ici une dimension politique.
Voilà en grosse maille la différence.
[^] # Re: À propos de la voiture électrique
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Le pétrole, le GPL, la voiture électrique, et mon portefeuille. Évalué à 2.
Je rajoute aussi une petite touche vécue du côté de chez moi, près de Grenoble. Un copain qui habite en montagne a fait l'achat d'une petite voiture électrique (la Zoé pour ne pas la nommer) juste pour pouvoir faire l'aller-retour de chez lui à son boulot dans la vallée. Son autonomie lui permet de ne pouvoir la charger que le soir chez lui pour le lendemain.
[^] # Re: À propos de la voiture électrique
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Le pétrole, le GPL, la voiture électrique, et mon portefeuille. Évalué à 5. Dernière modification le 13 octobre 2021 à 09:53.
Et il y a ce site aussi, un calculateur et comparateur qui permet de connaître le coût en équivalent CO2 de la voiture électrique de sa fabrication à son traitement en fin de vie :
https://climobil.connecting-project.lu
[^] # Re: Upgrades
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Silverpeas 6.2 est sortie malgré le contexte pandémique. Évalué à 1. Dernière modification le 04 février 2021 à 18:15.
Oui c'est vrai et c'est bien malheureux. C'est ce qui manque peut-être le plus. Pour créer une application pour Silverpeas, le mieux est probablement de s'inspirer d'un projet existant assez récent dans Silverpeas-Components. Il y a
SuggestionBoxqui est une application assez récente. SinonAlmanachqui a été remaniée pas mal et qui respecte les canons actuels en terme de codage dans Silverpeas.Le code d'une application de Silverpeas est un projet qui se décompose en trois sous-projets :
- la configuration (sous projet
<nom application>-configuration) qui comprend les règles de migration des données en base de données (tables, contraintes, …), le descripteur applicatif (dans le dossier xmlcomponents) qui définit entre autre les paramètres d'instances de l'application, des fichiers de propriétés qui définissent des paramètres de configuration globaux à l'application, le descripteur de logging, etc.- le code métier (sous projet
<nom application>-library)- et l'IHM Web (sous projet
<nom application>-war)[^] # Re: Upgrades
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Silverpeas 6.2 est sortie malgré le contexte pandémique. Évalué à 2.
Avec Silverpeas 6, les mises à jour se font assez simplement. Il faut spécifier la nouvelle version dans le fichier
$SILVERPEAS_HOME/bin/silverpeas.gradle, par exemple ici la version 6.2 :Puis lancer la commande de mise à jour :
L'instruction
cleanest pour nettoyer l'installation précédente et ainsi forcer, avec la commandeinstall, de récupérer, configurer puis installer la version spécifiée dans le fichiersilverpeas.gradle.Maintenant, la mise à jour de Silverpeas 5 à la version 6 requière des manipulations manuelles pour les raisons suivantes :
- le nom de certaines propriétés de configuration et de paramétrage de composants ont changé,
- l'organisation du dossier home de Silverpeas (dossier d'installation) est différente entre les deux versions et requière donc de déplacer des fichiers d'une version vers l'autre avec les modifications nécessaires (point précédent);
- le serveur applicatif d'exécution passe de JBoss 6 à Wildfly >= 8
En général, les organisations qui souhaitent passer d'une version majeur à l'autre demandent une prestation.
Maintenant, pour 50 personnes connectés ensemble, une machine avec 8Go de RAM environ devrait suffire. Pour les CPU, ceux actuels sont largement suffisants. C'est surtout la mémoire qui est importante. Pour ce qui est de l'espace disque, c'est selon la quantité de données qui sera poussée dans Silverpeas.
[^] # Re: Problème de vocabulaire
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Accidentologie, sécurité routière et cyclisme. Évalué à 6.
En effet, pour donner au moulin de quoi moudre, à Grenoble le plus grand danger du cycliste n'est pas la voiture … mais les autres vélos ! En tout cas, c'est comme ça que je le ressent lorsqu'y vais en vélo. Il y en a qui ont du mal à comprendre que lorsqu'il y a du monde sur les pistes cyclables, il faut savoir adapter son coup de pédale. Et je ne parle même pas de certains parents avec leurs enfants à vélo qui les laisse bousculer les autres cyclistes sans rien dire.
[^] # Re: L'arlésienne CR3
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche darktable 3.2 : l’effet confinement !. Évalué à 8.
Pentax propose aussi le DNG avec ses boîtiers.
[^] # Re: X11 ?
Posté par Miguel Moquillon (site web personnel) . En réponse au journal umberwm, un gestionnaire de fenêtre en tuile pour X11. Évalué à 5.
Voici plus d'infos sur le sujet (lire les commentaires) :
https://discuss.pixls.us/t/wayland-color-management/10804
Il y a d'ailleurs cette phrase de Graeme W. Gill, l'auteur d'ArgyllCMS et d'ArgyllPro, qui m'a interpellé :
C'est de cette discussion qu'Aurélien Pierre faisait, je pense, référence lorsqu'il a parlé du problème de Wayland d'avec la colorimétrie.
[^] # Re: X11 ?
Posté par Miguel Moquillon (site web personnel) . En réponse au journal umberwm, un gestionnaire de fenêtre en tuile pour X11. Évalué à 3.
Apparemment c'est plus compliqué que juste de la calibration et du profilage colorimétrique … d'ailleurs le problème relèverait plus du profilage puisque c'est lui qui gère les conversions entre espace et profil colorimétrique. En fait, ce serait plus un problème de compréhension de ce que sont les profils ICC, ce que décrivent les espaces colorimétriques, des capacités des écrans et des imprimantes, etc. Il faudrait que je retrouve où Aurélien Pierre en parle de ça (c'est soit sur l'une de ses vidéos sur Youtube, soit dans une de ses réponses dans les forums darktable ou sur pixls ; en tout cas je n'ai pas trouvé dans son blog sur son site photo).
[^] # Re: X11 ?
Posté par Miguel Moquillon (site web personnel) . En réponse au journal umberwm, un gestionnaire de fenêtre en tuile pour X11. Évalué à 6.
Xorg n'est plus développé ? Dommage pour ceux qui font de la retouche photo ou vidéo sur *BSD ou GNU/Linux parce que les codeurs de Wayland sont à mille lieux des problématiques de colorimétrie ; apparemment, d'après Aurélien Pierre, un des contributeurs de Darktable, ces questions leur passeraient largement au dessus de leur compréhension. Et c'est dommage pour un système graphique …
# Sympa
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Reqman(2), un postman GPL qui utilise de simples fichiers YAML. Évalué à 2.
J'aime bien. Allez hop, c'est adopté !
# Ma vie ... mon quotidien
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Le VAE n'est PAS un truc de fainéant. Évalué à 10.
De mon côté, lorsque je ne télétravaille pas, je fais 27km en vélo (non VAE) pour aller au boulot. Le retour, je le fais en train + vélo (il reste 6km). Lorsqu'il fait mauvais, je vais à la gare en vélo et je prend le train. Bon quand il neige ou quand il tempête, j'avoue je vais prendre le train mais en voiture (si trop de neige, je reste en télétravail) ou je prend le car à 5mn de chez moi.
Sur mon trajet, je croise pas mal de personnes en vélos, surtout par beau temps. Je trouve les VAE formidables :
- je trouve des personnes qui se sont mis à se déplacer en vélo en lieu et place de la voiture grâce aux VAE,
- des copains qui font du VTT de descentes peuvent, entre midi et deux, se faire plaisir parce que l'assistance électrique sur leur VTT leur permet d'aller là où en temps normal ils ne pourraient pas à cause de la contrainte horaire.
- des personnes en difficulté physique ou âgées ont pu (re)prendre plaisir en vélos grâces aux VAE
# Mon expérience à deux balles
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 5.
Ouep, l'enfer des outils de build s'ouvre dès que l'on veut construire un logiciel destiné à plusieurs plate-formes d'exécution. Il y a eu des langages mutli plate-formes qui ont été développées (Lisp, Smalltalk, Java, …) pour éviter, entre autre, ce genre de problèmes, mais ça n'a jamais vraiment marché parce qu'il y a toujours une plate-forme, le vent en poupe, qui ne joue pas leur jeu. Ou alors ça ne rempli pas les contraintes du logiciel (le plus souvent la performance) sur une ou plusieurs plate-formes cibles (mais ce critère relève peu ou prou aussi du premier, à savoir de jouer le jeu ; voir l'exemple raté des machines Lisp).
Dans mon cas, après avoir développé en C++ jusqu'en 2003 où on utilisait massivement des Makefiles, je me suis mis à Java jusqu'à encore aujourd'hui. Au début, on utilisait Ant (qui, comme tu l'as si bien écris, est du Makefile en XML). Maintenant on utilise Maven et bien que non exempte de défauts, je trouve que c'est un outil formidable surtout sur des gros, très gros projets ou lorsque les projets sont composés de plusieurs langages et ressources (Java, Groovy, Javascript, CSS, …). On utilise aussi du Gradle mais là c'est plus comme base pour concevoir des installateurs et configurateurs d'applications sur serveurs que comme système de build. A côté de ça je fais aussi un peu d'Haskell. Ce dernier a son propre outil de build (pardon ses propres outils de build) et ce n'est pas plus mal (j'adore slack). Les pires systèmes de build que j'ai pu utiliser restent quand même ceux du monde Javascript … Le meilleur que j'ai trouvé est celui du monde Smalltalk : il n'y en a pas ! Ou plus exactement, comme il ne s'appuie pas sur une approche de programmation et de construction orientée fichier, les problèmes adressés ne sont pas les mêmes et, au regard de ma piètre expérience avec, j'ai m'y suis pris beaucoup moins la tête. Mais je m'égare …
Pour répondre à ta question, dans mon ancienne boite, j'ai vu des équipes qui développaient des projets multi plate-formes (desktop, mobile Androïd, …) utiliser Maven comme outil de build centralisé. Par contre, ne m'étant jamais vraiment intéressé à ce problème, je ne leur ai jamais demandé leur retour là dessus. En tout cas, il semble qu'il existe des plugins Maven pour construire des projets iOS : j'ai trouvé ça https://github.com/letsdev/maven-ios-plugin
# Et bitbucket ?
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Microsoft rachète Github. Évalué à 1.
Tout le monde ici discute de gitlab mais je m'étonne que personne ait cité bitbucket
# La fin du communautaire ?
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Fermeture définitive du site grenouille.com (news pas fraîche du tout). Évalué à 8.
Est ce que finalement ce qui arrive à grenouille.com et autres sites dits communautaires n'est pas tout simplement le symptôme du consumérisme coloré d'individualisme exacerbé, associé au tout centralisé sur le Web (GAFA like) ?
# Architecture à VM vs. architecture à conteneurs ?
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Qubes OS 4.0. Évalué à 6.
A la lecture de la dépêche, si je comprend bien :
- on a des VM modèles qui définissent un environnement GNU/Linux minimal
- à partir d'un de ces modèles, on peut avoir un environnement virtuel plus complet comprenant un ensemble de programmes précis
- à partir des ces environnement, on peut lancer des programmes eux même dans une VM à part
Je suppute, du fait de la lourdeur inhérentes aux VM, que QubesOS se destine avant tout aux serveurs.
Pourquoi QubesOS repose t'il sur une architecture à VM ? Pourquoi pas plutôt sur une architecture à conteneurs (LXC, docker, …) qui est bien plus légère ? Qu'est ce que de nos jours une telle approche apporte comparée à celles des conteneurs ?
# Et keybase ?
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Gestionnaires de mots de passe. Évalué à 1.
Et que pensez vous de keybase ?
S'il ne génère pas de mots de passe, on peut les stocker (ils sont chiffrés par le biais d'une pair de clé publique/privée) et même les partager avec d'autres personnes ; intéressant dans le cas d'associations où des crédences peuvent être communes à plusieurs personnes attitrées (pour le site web, la banque en ligne, etc.)
[^] # Re: Travailler le « pitch de l'ascenceur » ?
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Silverpeas 6.0 est (enfin) sorti !. Évalué à 2.
Malgré que le ton de ton commentaire me heurte, m'agresse, après un moment à prendre du recul face à celui-ci, je dois avouer que tu as raison.
Quitte à réaliser un paquet de test (qu'il soit sous forme d'un installateur ou d'une image Docker), autant le faire avec un jeu de données initiales, aussi succincte qu'il soit, qui permet d'avoir une idée rapide du logiciel. Je prend en compte ce point et je prendrai du temps pour le faire (bon, le temps c'est ce que j'ai peu et donc ça risque d'attendre quelques jours/semaines avant que ce soit fait)
[^] # Re: rapidement
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Silverpeas 6.0 est (enfin) sorti !. Évalué à 1.
ha si il y a une différence avec Dockerfile :
au lieu de taper :
Il faut taper :
Cette dernière instruction installe et configure Silverpeas (via le fichier $SILVERPEAS_HOME/configuration/config.properties)
[^] # Re: rapidement
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Silverpeas 6.0 est (enfin) sorti !. Évalué à 1.
Bon si effectivement Sharepoint est un concurrent à Silverpeas, dire qu'il faut beaucoup de temps pour le déployer est, à mon humble opinion, très exagéré.
Rien qu'en suivant le Dockerfile, à défaut de la page d'installation de Silverpeas 6.0, qui sert à construire une image Docker de Silverpeas, permet d'avoir un aperçu rapide de ce qu'il en est. Il ne reste ensuite plus qu'à installer une base de données (avec PostgreSQL par exemple) et y reporter les paramètres de configuration dans un fichier $SILVERPAS_HOME/configuration/config.properties. Là de base, tu as un Silverpeas qui marche et qui soit utilisable.
Ensuite, certes, il faut ensuite se connecter en tant qu'administrateur, aller dans le back-office (Administration) afin de commencer à ajouter des utilisateurs, à créer des espaces de collaboration/de travail et y instancier des applications. Mais tout cela se fait facilement. De toute façon, c'est une étape nécessaire comme avec tous les outils de ce genre : paramétrer l'application à tes besoins.
[^] # Re: équivalent de ESUP ?
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Silverpeas 6.0 est (enfin) sorti !. Évalué à 2.
Je ne connais pas le portail e-sup et ne saurait donc te répondre là dessus. Mais effectivement Silverpeas est un portail couplé à des applications de style GED, moteur de blog, de forum, et ainsi de suite. Ce sont par eux que les utilisateurs poussent de l'information et collaborent. Dans le cadre de Silverpeas, ces applications ne sont pas des programmes extérieurs mais des composants logiciels réalisés au-dessus du socle technique et métier de Silverpeas (Silverpeas Core) et donc sont des applications (fortement) intégrés.
[^] # Re: Travailler le « pitch de l'ascenceur » ?
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Silverpeas 6.0 est (enfin) sorti !. Évalué à -3.
Oui tu peux utiliser Silverpeas pour ton groupe de rock.
Pour te faire une idée, tu peux récupérer Silverpeas via l'installateur IzPack et l'essayer. Ensuite, si tu veux aller plus loin, il vaut mieux alors d'utiliser directement la distribution (l'archive zip avec le programme d'installation, de configuration et de lancement) ou l'image docker de Silverpeas. Il y a aussi un groupe de discussion si tu as besoins d'infos ou si tu as des problèmes (http://groups.google.com/group/silverpeas-users)