Pour le back-end du logiciel, on pense partir sur Pyhton/MongoDB.
Le code "métier" (l'intelligence du logiciel, qui exploite les concepts "métier") aura besoin d'objets et on envisage l'utilisation d'un ODM. Ca serait a priori MongoEngine. Pour gérer Python3/Mongo3, il y a pas l'embarras du choix, et celui-ci semble bien vivant. Et comme c'est pas non plus hyper compliqué, je me dis qu'on devrait pouvoir contribuer si ça bloque par endroits, s'il manque des choses. En tout cas ça devrait être plus simple et plus sympa de le modifier que de refaire cette couche-là de zéro.
Le back-end fournit une API REST. Pour ça, on envisage Falcon. Sinon, Flask. Falcon est dit plus performant (c'est pas forcément critique pour nous) et plus simple car dédié à la fourniture d'API, contrairement à Flask qui est "généraliste".
Je parle pas trop de tout ça dans l'annonce parce que je veux pas vendre du rêve : il est plutôt prévu que le stagiaire bosse sur le front-end. Mais si ça l'intéresse, il pourra voir le back-end, discuter les choix, etc. En plus l'API va évoluer au fil du développement comme les deux blocs back-end et front-end seront développés en même temps.
Le front-end exploite l'API pour fournir l'interface graphique. On pense utiliser Python ici aussi parce qu'on aime bien (argument de poids). Django semble un peu overkill (on a pas besoin de base de donnée de ce côté, par exemple), donc plutôt Flask. Là-dessus, il y aura une couche JS encore à définir, et probablement du Bootstrap. Encore une fois, rien n'est arrêté et les propositions et opinions du stagiaire nous intéressent.
Dit comme ça, ça peut paraître flou mais c'est clair dans notre tête. On a pas mal avancé dans l'architecture :
Le minimum légal, qui doit être de 554,40€, sauf erreur.
(Le stagiaire reçoit en plus, comme les salariés, un ticket resto par jour d'une valeur de 8€. Je suppose que comme pour les salariés, 4,5€ sont à la charge de l'employeur et 3,5€ déduits du salaire. Et je suppose aussi que c'est facultatif mais que même si comme moi on aime pas le principe des TR, on les prend parce que c'est toujours ça…)
C'est même probablement utile pour eux d'avoir de temps en temps un "dérapage", quelqu'un qui dit tout haut ce qu'on n'ose dire tout bas, ce qui permet de flatter les cons tout en continuant la "dédiabolisation" pour ratisser plus large.
Un peu comme la Morano à l'UMP. On peut toujours lui demander ou faire des excuses hypocrites pour elle, au final, le message est passé.
On peut trouver le coup de gueule du développeur un peu simpliste mais c'est son problème. On peut aussi le trouver un peu percutant, et après tout, pourquoi pas s'exprimer comme ça ?
L'analyse du scrutin, de l'état de la démocratie, du rôle des médias, des stratégies des partis dominants, etc. mériterait bien plus de lignes, mais ce n'est pas le propos. Ça fait du bien aussi d'entendre des choses simples ("La jeunesse emmerde le Front National", etc.) de temps en temps, tellement il semblerait que ça soit pas évident pour tout le monde.
Il y a sûrement pas de quoi s'agacer, et encore moins venir râler ici pour le dire…
Pris au pied de la lettre, ça pourrait rendre le logiciel non libre, à mon sens. Au développeur de clarifier, comme le suggère une réponse.
Quand je vois les agences de comm qui te sortent du "digital" à tire-larigot, je me dis qu'elles sont quand-même bien branques si elles font tout avec les doigts au lieu d'utiliser des ordinateurs.
C'est peut-être dommage de faire signer des candidats et pas des listes. Quand je vote, c'est pour un programme, pas pour un candidat [1].
En tant que citoyen, voire militant, je voudrais que la décision soit débattue au sein de l'équipe de campagne par les citoyens/militants impliqués, pas que tel ou tel membre s'engage en son nom.
Sur certaines listes, tous les candidats vont signer en leur nom, sur d'autres, seule la tête de liste le fera, et donc l'indicateur "nombre de signataire" est biaisé.
Je sais bien qu'on subit la personnalisation de la politique et qu'on fait avec. Et j'imagine que l'idée, c'est qu'on puisse exhiber sa signature à un élu félon qui se dédirait en votant des textes scélérats. Mais on devrait tout aussi bien pouvoir lui exhiber son programme, en lui explicitant en quoi il le contredit (et en lui demandant "le changement, c'est quand ?").
[1] En fait, ce serait plutôt pour un programme et une stratégie. Certaines listes ou formations politiques portent des programmes sensiblement identiques mais ont des stratégies divergentes en matière de communication, alliances, etc. Et parfois contre un candidat si je sais qu'il ne respectera pas le programme qu'il présente.
Oui. Merci au rédacteur du journal d'avoir pris le temps de détailler, mais pour ma part, je n'ai plus de lecteur flash depuis fort longtemps sur ma machine et ça se passe bien.
J'ai parfois des remarques pour des contenus qui passent pas (vidéos (même youtube embarquées), grooveshark/deezer, etc.), mais je le vis plutôt bien.
Dans v42, tu peux activer l'ancienne interface avec une préférence. Dans v43 tu ne peux plus.
OK. Je pensais l'avoir fait avec une extension (Classic Theme Restorer) mais peut-être que c'était avec l'option de config.
Pour ce qui est du moteur par défaut, tu peux toujours le changer dans les paramètres, facilement accessibles dans l'interface.
Oui, bien sûr, mais ce qui m'ennuie c'est que chaque nouvelle recherche utilise le moteur par défaut et pas le dernier moteur utilisé. A la réflexion, les deux valeurs (moteur par défaut ou moteur précédent) se défendent, et je suis même pas sûr de savoir laquelle occasionne chez moi le plus de clics. Peut-être que c'est mieux avec le moteur par défaut.
Quand j'explore les paquets debian, j'utilise plein de fois le moteur Debian packages à la suite, donc j'aime bien qu'il reste sélectionné. Pour un cas comme ça, c'était mieux avant.
Je suis pas sûr de comprendre ce qui va changer dans la v43.
Sur une machine, j'ai la v38 sans modification, donc le nouveau comportement par défaut. C'est vrai que ça marche pas si mal. Je regrette l'absence des noms en face des icônes, c'est un peu nul si tu as Wikipedia EN et FR et les icônes sont identiques. Des fois je mélange même avec Wiktionary. Sur la capture d'écran, on dirait qu'au moins quand une icône est sélectionnée, le nom du moteur apparait au-dessus. C'est pas idéal mais c'est un moindre mal. Sur ma v38, c'est pas le cas.
En contrepartie, dans l'ancien modèle, je m'emmêle un peu les pinceaux entre la navigation dans les suggestions de recherche et la sélection du moteur, alors que dans le nouveau, on peut s'en sortir avec la flèches haut/bas pour les suggestions et la touche tab pour le moteur. De ce point de vue, c'est un progrès.
Finalement, ce que je regrette, c'est surtout le retour systématique au moteur par défaut. C'est dommage de pas pouvoir supprimer ça, ne serait-ce qu'avec une clé dans about:config. Je pense que je vais me mettre aux mots-clés, et au final, j'aurais peut-être une utilisation aussi bien sinon meilleure qu'avant.
Ouais, je sais que j'abuse du terme, c'est pour ça que j'ai précisé. Mais ça reste du dédié, mon courrier est pas dans les serveurs de courriel de Gandi et encore moins chez Google (sauf celui que j'envoie ou reçoit de qqn chez gmail…). Bien sûr, un admin de chez Gandi peut aller le lire s'il a du temps à perdre.
Ça reste plus simple pour la NSA d'aller lire le courrier chez Google que de se taper tous les petits serveurs à gérer, avec leurs différentes configs.
C'est mon compromis entre sécurité et fiabilité/conso énergétique.
En tout cas pour le reste du propos, ça changeait pas grand chose, donc j'ai cité mon exemple pour réagir sur l'invitation à l'auto-hébergement.
Installer sur un dédié, c'est pas auto-héberger, mais c'est déjà décentraliser, c'est une part du boulot de fait. Je le verrais peut-être différemment si j'hébergeais ça dans un VM chez Amazon.
Franchement, mettre mon courriel principal et unique chez moi, j'oserais pas. Entre la box de merde, la potentielle coupure de courant pendant les vacances, les déménagements de temps en temps, et tout… Trop chiant.
Et puis il y aurait des choses à dire sur l'auto-hébergement. Chacun son serveur chez soi, bonjour le coût énergétique. Il faudrait trouver un niveau intermédiaire de localisation. A l'échelle d'une petite communauté avec un gars qui s'y connaît, c'est bien. Quand je plaquerai tout, j'irai faire sysadmin dans le Larzac.
GitLab, par exemple, je vois pas de paquet Debian, même expérimental.
Au boulot, j'ai installé Gitolite et Redmine. J'ai pas encore essayé le lien entre les deux, mais j'espère que ça fera le boulot (et que Redmine se cassera pas trop à la prochaine grosse MàJ).
Dans mon précédente message, je yakafokone un peu, et j'oublie de dire merci pour le boulot de Framasoft.
L'auto-hébergement, c'est bien. En fait, c'est peut-être même Le Bien. Mais c'est chiant.
J'auto-héberge (chez Gandi, pas chez moi) ma messagerie, mes listes, mon web, depuis quelques années.
A installer, c'était du boulot (cf. les dépêches tuto sur DLFP), et pas du boulot simple, en tout cas pour la messagerie, du boulot pour geek qui avait le temps.
Au quotidien, ça marche plutôt bien.
A maintenir, ça peut être lourd. Typiquement, le passage à Jessie, on le repousse parce que ça va être du boulot, donc du temps, et que maintenant, on est toujours des geeks mais on a plus le temps. (Et Roundcube a disparu des dépôts…)
De même, je mettrais bien en place du Frama* au boulot pour remplacer le WeTransfer, le Doodle, etc. Mais je veux pas me rajouter une dépendance de plus. Je peux mettre en place un truc vite fait, dire à tout le monde de l'utiliser parce que c'est bien (voire Le Bien) et parce que c'est plus la classe pour la boîte d'avoir un truc personnalisé. Mais je peux pas justifier de passer trop de temps dessus pour la maintenance alors qu'il y a des trucs gratuits "kivonbien".
Si je dois surveiller les releases et faire les MàJ à la main, c'est pas jouable.
Bref, tout ça pour dire que pour installer ça sur mon serveur ou celui du boulot, la condition, c'est le paquet Debian. Ça change tout. Si le paquet est présent (et bien fait), l'administration, ça revient à "aptitude install" une fois et c'est fini. Et là, c'est vraiment royal, ça rend le truc auto-hébergeable par Kevin sur son RaspberryPi.
Et ça évite que dans quelques mois on ait plein d'instances en ligne avec une faille de sécurité parce que personne a mis à jour depuis l'installation.
Au début de chaque heure, un géant tire sur la corde et celle-ci s'allonge de façon élastique. À chaque fois la corde s'allonge de 100m de façon homogène.
À l'issue de la première heure, l'escargot à parcouru 1m, le géant tire sur la corde, celle-ci passe à 200m. Puisque la déformation est homogène, l'escargot se trouve maintenant à 2m du point de départ.
Donc c'est à la fin de chaque heure, que le géant tire. Et c'est l'escargot qui joue en premier.
Demander aux utilisateurs de comprendre les tenants et aboutissants de ça, c'est ridicule. Demander aux admins de virer les polices emmerdantes, ça me semble plus accessible, déjà. Ou donner des templates avec les bonnes polices. Ou oser demander à la boîte qui reçoit pour des millions d'euros annuels d'argent public de faire une petite adaptation pour simplifier la vie de ses usagers…
Pour les demandes de certificat d'immatriculation, j'ai constaté la même chose, mais en cherchant sur internet la référence CERFA tu trouves des .pdf que tu peux ouvrir avec ton logiciel habituel, imprimer, et remplir à la main.
J'ai peut-être mal cherché parce que j'ai imprimé la version 01 au lieu de la 02. J'ose croire que ça ira quand même.
L'objectif de ce CMS est d'être simple à utiliser, avec un maximum de fonctionnalités utiles, le back-office est simple et son utilisation fluide.
Ça fait un peu copier-coller des dernières annonces de sortie de CMS.
Avec un tout petit peu de recul (j'ai une expérience limitée des CMS), un de mes critères de choix concernerait la maintenance :
- est-ce que le développement va suivre dans le temps ?
- est-ce que les mises à jour sont fréquentes ? difficiles ?
J'aurais tendance à privilégier un "gros" par sécurité, quitte à ce que ça soit un poil plus lourd à configurer, si ça me garantit mieux l'avenir.
Sur un serveur Debian, je serais même tenté d'utiliser un logiciel disponible dans les dépôts, mais je crois que les développeurs ne le recommandent pas parce que c'est vite obsolète et pas forcément backporté.
# Précisions sur le projet
Posté par jihele . En réponse au message Offre de stage M2 / PFE : Conception / développement d'une interface web (Bordeaux). Évalué à 3.
Pour le back-end du logiciel, on pense partir sur Pyhton/MongoDB.
Le code "métier" (l'intelligence du logiciel, qui exploite les concepts "métier") aura besoin d'objets et on envisage l'utilisation d'un ODM. Ca serait a priori MongoEngine. Pour gérer Python3/Mongo3, il y a pas l'embarras du choix, et celui-ci semble bien vivant. Et comme c'est pas non plus hyper compliqué, je me dis qu'on devrait pouvoir contribuer si ça bloque par endroits, s'il manque des choses. En tout cas ça devrait être plus simple et plus sympa de le modifier que de refaire cette couche-là de zéro.
Le back-end fournit une API REST. Pour ça, on envisage Falcon. Sinon, Flask. Falcon est dit plus performant (c'est pas forcément critique pour nous) et plus simple car dédié à la fourniture d'API, contrairement à Flask qui est "généraliste".
Je parle pas trop de tout ça dans l'annonce parce que je veux pas vendre du rêve : il est plutôt prévu que le stagiaire bosse sur le front-end. Mais si ça l'intéresse, il pourra voir le back-end, discuter les choix, etc. En plus l'API va évoluer au fil du développement comme les deux blocs back-end et front-end seront développés en même temps.
Le front-end exploite l'API pour fournir l'interface graphique. On pense utiliser Python ici aussi parce qu'on aime bien (argument de poids). Django semble un peu overkill (on a pas besoin de base de donnée de ce côté, par exemple), donc plutôt Flask. Là-dessus, il y aura une couche JS encore à définir, et probablement du Bootstrap. Encore une fois, rien n'est arrêté et les propositions et opinions du stagiaire nous intéressent.
Dit comme ça, ça peut paraître flou mais c'est clair dans notre tête. On a pas mal avancé dans l'architecture :
[^] # Re: Remuneration?
Posté par jihele . En réponse au message Offre de stage M2 / PFE : Conception / développement d'une interface web (Bordeaux). Évalué à 4.
Le minimum légal, qui doit être de 554,40€, sauf erreur.
(Le stagiaire reçoit en plus, comme les salariés, un ticket resto par jour d'une valeur de 8€. Je suppose que comme pour les salariés, 4,5€ sont à la charge de l'employeur et 3,5€ déduits du salaire. Et je suppose aussi que c'est facultatif mais que même si comme moi on aime pas le principe des TR, on les prend parce que c'est toujours ça…)
[^] # Re: Pas très intéressant ...
Posté par jihele . En réponse au journal Notepad++ et FN ; ou quand un développeur parle d'autre chose que de développement. Évalué à 4.
C'est même probablement utile pour eux d'avoir de temps en temps un "dérapage", quelqu'un qui dit tout haut ce qu'on n'ose dire tout bas, ce qui permet de flatter les cons tout en continuant la "dédiabolisation" pour ratisser plus large.
Un peu comme la Morano à l'UMP. On peut toujours lui demander ou faire des excuses hypocrites pour elle, au final, le message est passé.
[^] # Re: Pas très intéressant ...
Posté par jihele . En réponse au journal Notepad++ et FN ; ou quand un développeur parle d'autre chose que de développement. Évalué à 6.
On peut trouver le coup de gueule du développeur un peu simpliste mais c'est son problème. On peut aussi le trouver un peu percutant, et après tout, pourquoi pas s'exprimer comme ça ?
L'analyse du scrutin, de l'état de la démocratie, du rôle des médias, des stratégies des partis dominants, etc. mériterait bien plus de lignes, mais ce n'est pas le propos. Ça fait du bien aussi d'entendre des choses simples ("La jeunesse emmerde le Front National", etc.) de temps en temps, tellement il semblerait que ça soit pas évident pour tout le monde.
Il y a sûrement pas de quoi s'agacer, et encore moins venir râler ici pour le dire…
Pris au pied de la lettre, ça pourrait rendre le logiciel non libre, à mon sens. Au développeur de clarifier, comme le suggère une réponse.
[^] # Re: Valérie Pécresse
Posté par jihele . En réponse à la dépêche Candidats.fr régionales 2015, sensibilisons les candidats aux enjeux du Logiciel Libre. Évalué à 2.
Quand je vois les agences de comm qui te sortent du "digital" à tire-larigot, je me dis qu'elles sont quand-même bien branques si elles font tout avec les doigts au lieu d'utiliser des ordinateurs.
Au moins, tu as échappé à ça…
# Candidat ou programme ?
Posté par jihele . En réponse à la dépêche Candidats.fr régionales 2015, sensibilisons les candidats aux enjeux du Logiciel Libre. Évalué à 9.
C'est peut-être dommage de faire signer des candidats et pas des listes. Quand je vote, c'est pour un programme, pas pour un candidat [1].
En tant que citoyen, voire militant, je voudrais que la décision soit débattue au sein de l'équipe de campagne par les citoyens/militants impliqués, pas que tel ou tel membre s'engage en son nom.
Sur certaines listes, tous les candidats vont signer en leur nom, sur d'autres, seule la tête de liste le fera, et donc l'indicateur "nombre de signataire" est biaisé.
Je sais bien qu'on subit la personnalisation de la politique et qu'on fait avec. Et j'imagine que l'idée, c'est qu'on puisse exhiber sa signature à un élu félon qui se dédirait en votant des textes scélérats. Mais on devrait tout aussi bien pouvoir lui exhiber son programme, en lui explicitant en quoi il le contredit (et en lui demandant "le changement, c'est quand ?").
[1] En fait, ce serait plutôt pour un programme et une stratégie. Certaines listes ou formations politiques portent des programmes sensiblement identiques mais ont des stratégies divergentes en matière de communication, alliances, etc. Et parfois contre un candidat si je sais qu'il ne respectera pas le programme qu'il présente.
[^] # Re: Oups...
Posté par jihele . En réponse à la dépêche Parution de 0 A.D. alpha 19 Syllepsis. Évalué à 5.
Les unités qui capturent ne sont pas encore animées et semblent ne rien faire.
?
plus variés et impressionnants les uns que les autres ?
# Pilotes 3D en version beta
Posté par jihele . En réponse au journal burn, cpu, burn !. Évalué à 8. Dernière modification le 26 novembre 2015 à 09:11.
Ce n'est pas un bug, c'est une fonctionnalité 3D rudimentaire.
Il faut que tu essayes de faire le point à l'infini avec tes yeux et tu devrais voir des formes en 3D.
D'autres exemples ici.
[^] # Re: Tout ce travail
Posté par jihele . En réponse au journal flash player à jour avec debian sid. Évalué à 2.
Oui. Merci au rédacteur du journal d'avoir pris le temps de détailler, mais pour ma part, je n'ai plus de lecteur flash depuis fort longtemps sur ma machine et ça se passe bien.
J'ai parfois des remarques pour des contenus qui passent pas (vidéos (même youtube embarquées), grooveshark/deezer, etc.), mais je le vis plutôt bien.
# Moi, je sais
Posté par jihele . En réponse au journal Facebook Notifications. Évalué à 4.
Deuxième fois : https://linuxfr.org/users/xinfe
[^] # Re: Forcément...
Posté par jihele . En réponse au journal Jeux compatibles Debian Jessie pour enfants de 3 à 10 ans. Évalué à 3.
Essaye en ligne de commande:
dpkg -i le_nom_du_paquet
[^] # Re: Champs de recherche
Posté par jihele . En réponse à la dépêche Firefox ? 42 !. Évalué à 3.
OK. Je pensais l'avoir fait avec une extension (Classic Theme Restorer) mais peut-être que c'était avec l'option de config.
Oui, bien sûr, mais ce qui m'ennuie c'est que chaque nouvelle recherche utilise le moteur par défaut et pas le dernier moteur utilisé. A la réflexion, les deux valeurs (moteur par défaut ou moteur précédent) se défendent, et je suis même pas sûr de savoir laquelle occasionne chez moi le plus de clics. Peut-être que c'est mieux avec le moteur par défaut.
Quand j'explore les paquets debian, j'utilise plein de fois le moteur Debian packages à la suite, donc j'aime bien qu'il reste sélectionné. Pour un cas comme ça, c'était mieux avant.
[^] # Re: Champs de recherche
Posté par jihele . En réponse à la dépêche Firefox ? 42 !. Évalué à 2.
Je suis pas sûr de comprendre ce qui va changer dans la v43.
Sur une machine, j'ai la v38 sans modification, donc le nouveau comportement par défaut. C'est vrai que ça marche pas si mal. Je regrette l'absence des noms en face des icônes, c'est un peu nul si tu as Wikipedia EN et FR et les icônes sont identiques. Des fois je mélange même avec Wiktionary. Sur la capture d'écran, on dirait qu'au moins quand une icône est sélectionnée, le nom du moteur apparait au-dessus. C'est pas idéal mais c'est un moindre mal. Sur ma v38, c'est pas le cas.
En contrepartie, dans l'ancien modèle, je m'emmêle un peu les pinceaux entre la navigation dans les suggestions de recherche et la sélection du moteur, alors que dans le nouveau, on peut s'en sortir avec la flèches haut/bas pour les suggestions et la touche tab pour le moteur. De ce point de vue, c'est un progrès.
Finalement, ce que je regrette, c'est surtout le retour systématique au moteur par défaut. C'est dommage de pas pouvoir supprimer ça, ne serait-ce qu'avec une clé dans about:config. Je pense que je vais me mettre aux mots-clés, et au final, j'aurais peut-être une utilisation aussi bien sinon meilleure qu'avant.
[^] # Re: Champs de recherche
Posté par jihele . En réponse à la dépêche Firefox ? 42 !. Évalué à 2.
Il dit que c'est à partir de la v43 que ça marchera plus :
Je pense jamais à Alt+Entrée, merci pour la piqûre de rappel.
[^] # Re: Champs de recherche
Posté par jihele . En réponse à la dépêche Firefox ? 42 !. Évalué à 4.
Je suis assez d'accord avec le commentaire. Avec l'ancienne version, je peux faire mes recherches sans toucher la souris :
Ctrl+T
Ctrl+K
Entrer les termes à rechercher
Alt+Flèche Haut/Bas pour sélectionner le moteur
Le dernier moteur utiliser reste actif pour la recherche suivante.
Ça m'embête que ce fonctionnement soit cassé.
# gksudo
Posté par jihele . En réponse au message Comment lancer une application par des lignes de commande ? [Résolu]. Évalué à 2.
Je crois que gksudo c'est mieux, mais je ne suis pas le mieux placé pour expliquer la différence.
http://askubuntu.com/questions/11760/what-is-the-difference-between-gksudo-nautilus-and-sudo-nautilus
https://help.ubuntu.com/community/RootSudo#Graphical_sudo
[^] # Re: Sauf que .... ils existent toujours en nous
Posté par jihele . En réponse au journal Journal qui dénonce. Évalué à 10.
Ah ouais, j'avais jamais remarqué les yeux bridés.
# Soutenons les biens communs
Posté par jihele . En réponse à la dépêche Consultation « République numérique », soutenez les propositions de vos organisations préférées. Évalué à 2.
Je ne crois pas avoir vu passer le lien.
Liste plus complète d'organisations : http://soutenonslesbienscommuns.org/
Leurs contributions : http://soutenonslesbienscommuns.org/contributions/
[^] # Re: Auto-hébergement
Posté par jihele . En réponse à la dépêche Dégooglisons Internet, saison 2 : ils ne savaient pas que c'était impossible, alors ils l'ont fait !. Évalué à 5.
Ouais, je sais que j'abuse du terme, c'est pour ça que j'ai précisé. Mais ça reste du dédié, mon courrier est pas dans les serveurs de courriel de Gandi et encore moins chez Google (sauf celui que j'envoie ou reçoit de qqn chez gmail…). Bien sûr, un admin de chez Gandi peut aller le lire s'il a du temps à perdre.
Ça reste plus simple pour la NSA d'aller lire le courrier chez Google que de se taper tous les petits serveurs à gérer, avec leurs différentes configs.
C'est mon compromis entre sécurité et fiabilité/conso énergétique.
En tout cas pour le reste du propos, ça changeait pas grand chose, donc j'ai cité mon exemple pour réagir sur l'invitation à l'auto-hébergement.
Installer sur un dédié, c'est pas auto-héberger, mais c'est déjà décentraliser, c'est une part du boulot de fait. Je le verrais peut-être différemment si j'hébergeais ça dans un VM chez Amazon.
Franchement, mettre mon courriel principal et unique chez moi, j'oserais pas. Entre la box de merde, la potentielle coupure de courant pendant les vacances, les déménagements de temps en temps, et tout… Trop chiant.
Et puis il y aurait des choses à dire sur l'auto-hébergement. Chacun son serveur chez soi, bonjour le coût énergétique. Il faudrait trouver un niveau intermédiaire de localisation. A l'échelle d'une petite communauté avec un gars qui s'y connaît, c'est bien. Quand je plaquerai tout, j'irai faire sysadmin dans le Larzac.
[^] # Re: Auto-hébergement
Posté par jihele . En réponse à la dépêche Dégooglisons Internet, saison 2 : ils ne savaient pas que c'était impossible, alors ils l'ont fait !. Évalué à 2.
GitLab, par exemple, je vois pas de paquet Debian, même expérimental.
Au boulot, j'ai installé Gitolite et Redmine. J'ai pas encore essayé le lien entre les deux, mais j'espère que ça fera le boulot (et que Redmine se cassera pas trop à la prochaine grosse MàJ).
Dans mon précédente message, je yakafokone un peu, et j'oublie de dire merci pour le boulot de Framasoft.
# Auto-hébergement
Posté par jihele . En réponse à la dépêche Dégooglisons Internet, saison 2 : ils ne savaient pas que c'était impossible, alors ils l'ont fait !. Évalué à 8.
L'auto-hébergement, c'est bien. En fait, c'est peut-être même Le Bien. Mais c'est chiant.
J'auto-héberge (chez Gandi, pas chez moi) ma messagerie, mes listes, mon web, depuis quelques années.
A installer, c'était du boulot (cf. les dépêches tuto sur DLFP), et pas du boulot simple, en tout cas pour la messagerie, du boulot pour geek qui avait le temps.
Au quotidien, ça marche plutôt bien.
A maintenir, ça peut être lourd. Typiquement, le passage à Jessie, on le repousse parce que ça va être du boulot, donc du temps, et que maintenant, on est toujours des geeks mais on a plus le temps. (Et Roundcube a disparu des dépôts…)
De même, je mettrais bien en place du Frama* au boulot pour remplacer le WeTransfer, le Doodle, etc. Mais je veux pas me rajouter une dépendance de plus. Je peux mettre en place un truc vite fait, dire à tout le monde de l'utiliser parce que c'est bien (voire Le Bien) et parce que c'est plus la classe pour la boîte d'avoir un truc personnalisé. Mais je peux pas justifier de passer trop de temps dessus pour la maintenance alors qu'il y a des trucs gratuits "kivonbien".
Si je dois surveiller les releases et faire les MàJ à la main, c'est pas jouable.
Bref, tout ça pour dire que pour installer ça sur mon serveur ou celui du boulot, la condition, c'est le paquet Debian. Ça change tout. Si le paquet est présent (et bien fait), l'administration, ça revient à "aptitude install" une fois et c'est fini. Et là, c'est vraiment royal, ça rend le truc auto-hébergeable par Kevin sur son RaspberryPi.
Et ça évite que dans quelques mois on ait plein d'instances en ligne avec une faille de sécurité parce que personne a mis à jour depuis l'installation.
# Premier terme ?
Posté par jihele . En réponse au journal [Énigme] L'escargot et le géant. Évalué à 7.
Donc c'est à la fin de chaque heure, que le géant tire. Et c'est l'escargot qui joue en premier.
[^] # Re: Déjà ils proposent un PDF ..;
Posté par jihele . En réponse au journal À quoi sert le RGI ?. Évalué à 9.
Demander aux utilisateurs de comprendre les tenants et aboutissants de ça, c'est ridicule. Demander aux admins de virer les polices emmerdantes, ça me semble plus accessible, déjà. Ou donner des templates avec les bonnes polices. Ou oser demander à la boîte qui reçoit pour des millions d'euros annuels d'argent public de faire une petite adaptation pour simplifier la vie de ses usagers…
[^] # Re: Déjà ils proposent un PDF ..;
Posté par jihele . En réponse au journal À quoi sert le RGI ?. Évalué à 2.
Pour les demandes de certificat d'immatriculation, j'ai constaté la même chose, mais en cherchant sur internet la référence CERFA tu trouves des .pdf que tu peux ouvrir avec ton logiciel habituel, imprimer, et remplir à la main.
J'ai peut-être mal cherché parce que j'ai imprimé la version 01 au lieu de la 02. J'ose croire que ça ira quand même.
[^] # Re: encore un ?
Posté par jihele . En réponse à la dépêche Sortie du CMS doorGets 7.0. Évalué à 2.
Moi aussi j'ai un peu souri en lisant ça :
Ça fait un peu copier-coller des dernières annonces de sortie de CMS.
Avec un tout petit peu de recul (j'ai une expérience limitée des CMS), un de mes critères de choix concernerait la maintenance :
- est-ce que le développement va suivre dans le temps ?
- est-ce que les mises à jour sont fréquentes ? difficiles ?
J'aurais tendance à privilégier un "gros" par sécurité, quitte à ce que ça soit un poil plus lourd à configurer, si ça me garantit mieux l'avenir.
Sur un serveur Debian, je serais même tenté d'utiliser un logiciel disponible dans les dépôts, mais je crois que les développeurs ne le recommandent pas parce que c'est vite obsolète et pas forcément backporté.