Ça ne marche pas bien chez moi, mais par hasard j'ai lu quelqu'un qui l'avait fait marcher accidentellement en changeant son écran. Il a certainement bougé l'antenne et c'est tombé en marche. À voir.
la nueva versión de la plataforma móvil KDE Plasma Mobile 21.12, basada en […] la pila de teléfonos ModemManager
Ça c'est une bonne nouvelle. Le fait que Plasma Mobile va se baser sur ModemManager me permettra probablement de migrer dessus. Je suis en train de développer une appli SMS pour le PinePhone et elle ne sait parler qu'à ModemManager pour le moment. Prendre en charge Ofono n'est pas une chose sur laquelle je voulais passer du temps en sachant que KDE allait s'en séparer (je l'avais lu par hasard sur un forum) et que, comme le dit l'article, le projet n'est plus très actif comparé à ModemManager. ModemManager et NetworkManager lèveront probablement plusieurs limitations actuelles de Plasma Mobile sur le PinePhone également avec Ofono et ConnMan.
Un autre blocage : Firefox ne fonctionnait pas sur Plasma Mobile la dernière fois que j'ai testé. J'espère que ça va s'améliorer si ça ne marche pas encore. Après, si Angelfish marche bien… mais bon, je suis quand même bien attaché à Firefox, son moteur de rendu encore un peu indépendant et ses extensions.
(Et puis, j'aime bien avoir une base Debian sur le téléphone. Malheureusement, il n'y a pas de variante KDE de Mobian actuellement)
Par exemple l’alignement d’un début de ligne avec un “milieu” d’une autre ligne n’est pas compatible avec le choix de la largeur des tabulations
C'est possible en faisant l'indentation avec les tabulations et l'alignement avec des espaces, non ? Bon de toute façon même si je le fais de temps en temps je crois que c'est rarement une bonne idée pour un tas de raisons.
Sinon, sur le formatage parfait… j'ai tendance à préférer le style recommandé par le langage. C'est souvent 4 espaces (Python, Java, Rust…). En Javascript c'est souvent 2 espaces, je trouve ça trop peu pour bien distinguer les blocs et je me retrouve souvent à jouer avec le curseur pour savoir si des blocs sont effectivement alignés, c'est loin d'être idéal. Donc dans mes codes perso, c'est 4 espaces aussi, c'est d'ailleurs plus cohérent avec les autres langages et je me demande si ce n'était pas la norme quand j'ai commencé à faire du Javascript. J'aimais bien 3 espaces à un moment mais quasi personne le fait et ça fait des alignement foireux, par exemple la ligne en dessous du "if (" se retrouve alignée avec la parenthèse ouvrante. Je trouve ça un peu moche. 4 c'est un peu le minimum confortable pour moi, et largement suffisant aussi donc c'est mon optimal. Finalement il y a des raisons objectives derrières mes préférences, mais je comprends qu'elles sont personnelles.
En théorie je n'ai rien contre l'indentation avec les tabulations, bien au contraire. Pourvu que le code ne se retrouve pas parfois indenté avec des tabulations, parfois avec des espaces. Je crois avoir lu un aveugle qui disait que l'indentation avec tabulations lui simplifiait la vie.
Globalement ma préférence va à des styles qui réduisent les erreurs de lecture et d'écriture au détriment de la place prise par le code, et c'est ça le plus important pour moi. Je préfère par exemple avoir systématiquement des accolades pour délimiter les blocs même quand elles sont optionnelles, en général. J'ai aussi tendance à passer des lignes vides assez largement dans mon code pour le faire « respirer », mais j'ai conscience que mes choix sont très arbitraires de ce côté là.
Ce qui pourrait se faire j'imagine, c'est d'avoir le formulaire avec un attribut « hidden » qu'on retire en js. Ça me semble pas mal. Ça marcherait même sans CSS.
In this installment we'll turn to the low- and no-JavaScript world
Il y a une promesse de faire sans Javascript, ou avec peu de Javascript, mais ça dépend en fait d'une bibliothèque à inclure. Donc ce n'est pas tant "sans javacript" que "utiliser javascript différemment".
D'un côté je suis content si ça permet de remplacer des choses actuellement écrites comme des SPA (avec React, Angular, ou autres) par des pages principalement HTML.
D'un autre côté, ça a l'air afficher des contrôles et des formulaires qui seront juste "silencieusement non fonctionnels" si Javascript est désactivé.
Ce serait bien à mon avis de respecter le principe "je n'affiche pas des trucs qui ne vont pas marcher", en créant les éléments qui dépendant de Javascript… en Javascript.
Par exemple, la semaine dernière, j'ai implémenté une petite barre de recherche sur une page qui affiche une liste de documents. Tout est implémenté en Javascript. La barre de recherche est donc insérée par le code Javascript lui-même. Les visiteurs sans Javascript auront une page totalement utilisable et ils pourront utiliser la recherche du navigateur à la place (toutes les infos sont dans la page, la barre de recherche ne fait que filtrer). Ils ne verront pas une barre de recherche qui s’avérera inopérante après essai infructueux (UI décevante).
En parfaite adéquation avec le « progressive enhancement » qui me parait un principe important.
Pour moi, si le principe est appliqué à toutes les contributions, ça tue effectivement l'utilité / l'intérêt des licences copyleft (pour les projets en copyleft), parce que ça veut dire que potentiellement la grosse majorité du code du projet et sous cette licence très permissive. Pour les projets sous licence copyfree je suppose qu'il y aurait des effets similaires.
Cela dit, si c'est un choix que tu fais toi en tant que contributeur individuel de placer ta contribution sous une licence très permissive, c'est tout à ton honneur je suppose !
Je me demande s'il n'y aurait pas un genre de CLA qui ferait moins peur, du style « j'autorise X à changer la licence de ma contribution, si j'ai (ou les ayants droits ont) été contacté et qu'on n'a pas donné de nouvelles / on ne s'est pas opposés dans les 6 mois, ou qu'on n'est plus joignables » (en légalement plus robuste).
Ah bah non, tu penses bien ? Pour ça il faudrait que TAC-Vérif soit libre, mais le libre ce n'est pas sécurisé parce que les gens peuvent lire le code source, ce qui transmettrait le covid plus facilement.
Un taboulé "français" simple est rapide à faire et très peu onéreux (< 1€ par repas), tout en étant riche côté nutritif.
Graines de couscous à faire gonfler dans de l'eau froide (même pas besoin de chauffer). Eau à raz de la semoule sèche (ça doit dépasser un tout petit peu mais c'est tout), un peu de sel, ça gonfle en 10 minutes. Décoller à la fourchette quand ça a commencé à gonfler.
Petits bouts de poivron, pois chiches, persil, menthe (éventuellement) raisins secs (éventuellement), ognons (éventuellement), concombre (éventuellement), carottes (éventuellement ; tu peux les faire cuire à l'eau bouillante pour les ramollir si tu veux), poivre (éventuellement). Huile d'olive. Éventuellement du jus de citron ou du vinaigre (balsamique ou non) si envie. Attention, le moment d'ajouter l'huile et/ou le jus de citron importe, il y en a un qu'il faut faire au dernier moment pour mieux conserver mais je ne sais plus lequel.
Un plat pas cher et adaptable au goût et au besoin.
On pourra plutôt partir sur un taboulé libanais avec beaucoup plus de persil (frais) et de la tomate, et plutôt du boulgour que de la semoule de blé. C'est potentiellement plus frais. On trouve des recettes sur internet, je n'en ai jamais fait.
C'est très difficile de ne pas manger assez de protéines. Il faut presque le vouloir. Il y en a partout.
Il faut un peu de tout (fer, vitamines, glucides (surtout lents), lipides, potassium, …). Avec des féculents de base (pâtes, riz, patates) des légumes (choux pour le potassium), fruits (agrumes pour la vitamine C) et des légumineuses (lentilles, pois chiches) on arrive déjà à avoir pas mal de choses. Du sel mais pas trop permet d'avoir sa dose de sodium et d'iode. De l'huile pour faire cuire les légumes et tu as de la graisse pour assimiler les vitamines des légumes.
Si tu ne manges pas que des fruits et des légumes et que tu manges pas que d'un seul ingrédient simple tu as probablement ton quotas de protéines variées.
Ça ne sonne pas ultra équilibré non plus. Au moins, le tacos bien gras rempli de frites a généralement quelques légumes.
Mais un bon sandwich peut contenir des ingrédients variés et équilibré sans problème et explosera à la fois le tacos et le jambon beurre en termes de nutrition, en plus de potentiellement les exploser en termes de goût. Points bonus si c'est avec du pain complet, le pain blanc c'est surtout plein de sucres rapides, ce qui n'est pas ultra top.
Après, il faut avoir les moyens s'acheter des ingrédients variés et avoir le temps de se préparer à manger. Le pauvre étudiant précaire qui doit travailler à côté des études pour payer le loyer et les factures manque des deux. La cantine est en théorie un bon moyen de manger varié et pas excessivement cher.
La rentabilité d'un service public, c'est hors sujet. Un service public c'est fait pour rendre service au public. Ça fait fonctionner un pays. C'est une dépense nécessaire. Et si c'est bien calculé, ça baisse les coûts pour tout le monde.
Je suis content de payer des impôts et qu'une partie de mon salaire soit des cotisations si le service public tient la route. Si.
La restauration universitaire est nécessaire. Comme beaucoup de services publics, la bonne question c'est "Comment ?", pas "Est-ce que ?" (et certainement pas privatiser les parties génératrices de revenus parce que sinon bien sûr, on finit par tout arrêter).
On peut parler de coût mais si le mot rentable apparait, on ne parle pas la bonne langue.
Sinon je suggère d'essayer le Vebab chez Gustavo, à base de seitan. Si vous habitez dans la région grenobloise et que vous n'avez pas encore essayé, laissez-vous tenter, c'est très bon et remplace avantageusement la pomme de terre bouillie non épluchée sans sel, même si vous n'êtes pas végé.
(après, la pomme de terre, c'est cool aussi, je ne dis pas)
Et puis, en tant que contributeur occasionnel à des projets libres, je trouve ça rafraîchissant de tomber sur une autre forge que GitHub. Encore mieux si je tombe sur un nom de domaine qui correspond au nom du projet : ça veut certainement dire que le projet contrôle l'hébergement de ses tickets et de ses requêtes de fusions et n'est pas à la merci de GitHub et de ses changements potentiels de direction pour ça.
Je haie la centralisation de GitHub. Je souhaiterais que ça n'existe pas. Je suis plus que content de me créer un compte sur des forges alternatives au besoin (sauf si elles cassent les pieds avec des contraintes débiles sur le mot de passe ou qu'elle force à avoir de la double authentification). Si quelqu'un n'est pas assez motivé pour envoyer un patch par mail ou se créer un compte sur la forge d'un projet pour proposer un patch ou rapporter un bug, peut-être que finalement ce n'était pas si important. D'ailleurs, on peut toujours rapporter un bug par mail aux dev si on est un utilisateur classique.
Si seulement on ne reproduisait pas les travers des réseaux sociaux centralisés jusqu'à dans nos développements et dans les projets libres… On peut toujours rêver.
J'imagine que ça ne correspond pas à 9 mois de travail continu.
Non, effectivement. Loin de là. On a pas mal été occupés sur le développement de Tracim lui-même. On a priorisé les nouvelles fonctionnalités, on a été pas mal pris par des demandes clients et aussi par la sortie de la version 3.10 qui est imminente. Ça a été plutôt rapide une fois qu'on s'y est mis :-)
Après effectivement, il faut s'approprier l'outil et ses concepts, trouver les bons réglages, faire les bonnes interconnexions avec la forge, un peu mimer ce qu'on avait avant pour ne pas perturber les manières de travailler, etc. Faut s'assurer que ça marche bien aussi. Dans ce genre de migration, il est « urgent de ne pas se dépêcher » :-)
Ça doit se compter en jours en temps de travail effectif, et il faut prendre en compte les context switches parce qu'on est trop peu pour se permettre de dédier une ou deux personnes à temps plein sur la mise en place de la nouvelle CI pendant plusieurs jours consécutifs.
Et puis, 11 personnes ce n'est pas 11 devs, et c'est encore moins 11 devs susceptibles de travailler sur la migration de la CI.
Je suis enthousiaste à plusieurs niveaux avec changement.
L'outillage est autrement plus pratique à utiliser au quotidien :
on a accès au conteneur qui exécute un job, donc on peut investiguer et aussi récupérer des sorties, par exemple les captures d'écran de Cypress, auquel on n'a jamais pu avoir accès avec Travis. D'ailleurs, on peut directement exécuter Cypress dans le conteneur pour essayer des choses
on a un vrai outil en ligne de commande pour faire un tas de choses, dont afficher le build en cours dans le terminal comme si ça se passait sur la machine
l'interface est ergonomique et efficace
on va pouvoir ajouter des ressources matérielles au besoin à moindre frais
Avec l'interface web de Travis, tout était lent. On ne sait pas pourquoi il y a un gros espace blanc en dessous des logs du build, ce qui empêche d'utiliser efficacement la barre de défilement du navigateur. Impossible d'utiliser les outils Unix efficacement pour disséquer les résultats présentés sur cette fichue page web. La page de résumé du statut de la CI sur GitHub n'est jamais à jour. Plus difficile d'investiguer : si le build n'est pas passé et que le problème n'est pas évident, tu n'as plus qu'à deviner ce qui a pu se passer.
Bref, passer à Concourse a demandé du travail mais je suis certain que c'est un investissement rentable. On atterrit dans une nouvelle dimension.
Ça permet aussi de contribuer à rendre l'outillage nécessaire pour construire le logiciel libre qu'est Tracim lui aussi libre de bout en bout (il reste GitHub).
Tu peux désactiver Javascript ou supprimer les cookies en général sur ces sites pour bypasser les paywalls. Ou faire un snapshot archive.org et y accéder comme ça.
les systèmes de fichiers réutilisent assez facilement les numéros d'inode
Oui. De plus, l'inode n'est unique qu'au sein d'un même système de fichier, donc si le dossier synchronisé contient deux points de montage, ce n'est pas bon.
Pire, certains systèmes de fichiers ne garantissent pas l'unicité des inodes. Pour Btrfs, par exemple, l'inode n'est unique que par sous-volume (avec le Copy-on-write, les fichiers peuvent être partagés jusqu'à la modification… et d'ailleurs, la modification d'un fichier peut aussi le faire changer d'inode). Et une partition Btrfs peut être montée entièrement sur un unique point de montage, avec tous les sous-volumes dedans.
Je suppose que c'est vrai aussi pour ZFS.
Donc ça peut causer des bugs « intéressant » effectivement, et la solution de n'accepter de synchroniser des fichiers n'appartenant qu'à un seul point de montage n'est pas suffisante.
Je suis preneur de toutes les idées, remarques et remontées de bugs !
Eh bien c'est parti ! :-)
Avoir une liste de fichiers / dossiers ignorés dans le style des fichiers .gitignore pour Git. Une liste soit locale, soit synchronisée sur Tracim.
Pouvoir éditer les notes. Webdav permet de récupérer les notes qui ont une extension .document.html mais ne permet pas de les modifier. L'extension pourrait être reprise, mais le comportement de la synchronisation pour ces fichiers devra appeler les API relatives aux notes (avec un éditeur de code ou un outil WYSIWYG indépendant de trsync qui ne s'occuperait que de la synchronisation elle-même).
avoir une petite icône / l'état de la synchronisation dans la zone de notifications de l'environnement de bureau (?)
Pourquoi pas, si tous ces modèles sont supportés longtemps ce qui a l'air d'être le cas ?
Quitte à vendre un téléphone neuf, il vaut mieux qu'il prenne en charge les derniers standard pour avoir plus de chance d'être utile plus longtemps.
L'article soulève qu'en pratique les Fairphones « ont aussi la fâcheuse réputation de devenir rapidement pénibles à utiliser, en raison des bugs et autres instabilités » mais ne rentre pas dans les détails sur ce point qui, pourtant, parait important pour répondre à la question.
De mon côté, je salue bien entendu l'initiative. On a besoin d'une production plus respectueuse de l'humain et de l'environnement. Je trouve ça dommage que les gouvernements du monde entier ne mettent pas l'accent et le paquet sur l'aspect humain (et l'écologie, bien sûr). Ça devrait être l'une de leur raison d'être. Mais à défaut…
La question que je me pose depuis longtemps, c'est que les Fairphones sont basés sur des chipsets Qualcomm, qui, j'imagine, comprennent au moins le modem et le processeur, probablement la mémoire vive, probablement la Wifi/ Bluetooth. C'est un gros morceau, est-ce qu'ils sont produits de façon responsable ? Quel est le pourcentage "Fair" du Fairphone ? (en nombre d'humains impliqués, ou en quantité de matériaux utilisés)
Ensuite, pour moi, dans "Fair" et "Human right", l'aspect logiciel libre semble important également, et le Fairphone a des caractéristiques semblables aux autres téléphones Android : c'est des blobs binaires pour les pilotes matériels. C'est la communauté qui a porté Lineage sur le Fairphone 3. Un Fairphone 3 dégooglisé n'a pas été possible avant un petit moment après sa sortie. Fairphone et /e/ sont maintenant partenaires donc il y a des efforts sur cet aspect malgré tout, et j'imagine qu'il faut choisir ses batailles.
[^] # Re: ModemManager
Posté par raphj (site web personnel) . En réponse au lien Sortie de KDE Plasma Mobile 21.12 avec des améliorations importantes. Évalué à 3. Dernière modification le 10 décembre 2021 à 14:42.
Ça ne marche pas bien chez moi, mais par hasard j'ai lu quelqu'un qui l'avait fait marcher accidentellement en changeant son écran. Il a certainement bougé l'antenne et c'est tombé en marche. À voir.
# ModemManager
Posté par raphj (site web personnel) . En réponse au lien Sortie de KDE Plasma Mobile 21.12 avec des améliorations importantes. Évalué à 3. Dernière modification le 10 décembre 2021 à 12:38.
Ça c'est une bonne nouvelle. Le fait que Plasma Mobile va se baser sur ModemManager me permettra probablement de migrer dessus. Je suis en train de développer une appli SMS pour le PinePhone et elle ne sait parler qu'à ModemManager pour le moment. Prendre en charge Ofono n'est pas une chose sur laquelle je voulais passer du temps en sachant que KDE allait s'en séparer (je l'avais lu par hasard sur un forum) et que, comme le dit l'article, le projet n'est plus très actif comparé à ModemManager. ModemManager et NetworkManager lèveront probablement plusieurs limitations actuelles de Plasma Mobile sur le PinePhone également avec Ofono et ConnMan.
Un autre blocage : Firefox ne fonctionnait pas sur Plasma Mobile la dernière fois que j'ai testé. J'espère que ça va s'améliorer si ça ne marche pas encore. Après, si Angelfish marche bien… mais bon, je suis quand même bien attaché à Firefox, son moteur de rendu encore un peu indépendant et ses extensions.
(Et puis, j'aime bien avoir une base Debian sur le téléphone. Malheureusement, il n'y a pas de variante KDE de Mobian actuellement)
[^] # Re: Enfin!
Posté par raphj (site web personnel) . En réponse au lien Fynedesk : un bureau Linux en Go. Évalué à 10.
J'espère qu'il y aura un bouton "Go" pour remplacer le traditionnel bouton "Start" en bas à gauche de l'écran.
# Alignement quand on indente avec des tabulations
Posté par raphj (site web personnel) . En réponse au journal Quelles seraient les meilleures règles de formatage de code ?. Évalué à 3. Dernière modification le 30 novembre 2021 à 09:25.
C'est possible en faisant l'indentation avec les tabulations et l'alignement avec des espaces, non ? Bon de toute façon même si je le fais de temps en temps je crois que c'est rarement une bonne idée pour un tas de raisons.
Sinon, sur le formatage parfait… j'ai tendance à préférer le style recommandé par le langage. C'est souvent 4 espaces (Python, Java, Rust…). En Javascript c'est souvent 2 espaces, je trouve ça trop peu pour bien distinguer les blocs et je me retrouve souvent à jouer avec le curseur pour savoir si des blocs sont effectivement alignés, c'est loin d'être idéal. Donc dans mes codes perso, c'est 4 espaces aussi, c'est d'ailleurs plus cohérent avec les autres langages et je me demande si ce n'était pas la norme quand j'ai commencé à faire du Javascript. J'aimais bien 3 espaces à un moment mais quasi personne le fait et ça fait des alignement foireux, par exemple la ligne en dessous du "if (" se retrouve alignée avec la parenthèse ouvrante. Je trouve ça un peu moche. 4 c'est un peu le minimum confortable pour moi, et largement suffisant aussi donc c'est mon optimal. Finalement il y a des raisons objectives derrières mes préférences, mais je comprends qu'elles sont personnelles.
En théorie je n'ai rien contre l'indentation avec les tabulations, bien au contraire. Pourvu que le code ne se retrouve pas parfois indenté avec des tabulations, parfois avec des espaces. Je crois avoir lu un aveugle qui disait que l'indentation avec tabulations lui simplifiait la vie.
Globalement ma préférence va à des styles qui réduisent les erreurs de lecture et d'écriture au détriment de la place prise par le code, et c'est ça le plus important pour moi. Je préfère par exemple avoir systématiquement des accolades pour délimiter les blocs même quand elles sont optionnelles, en général. J'ai aussi tendance à passer des lignes vides assez largement dans mon code pour le faire « respirer », mais j'ai conscience que mes choix sont très arbitraires de ce côté là.
[^] # Re: Mitigé
Posté par raphj (site web personnel) . En réponse au lien Le low javascript: le bon web enfin hype ?. Évalué à 4.
Ce qui pourrait se faire j'imagine, c'est d'avoir le formulaire avec un attribut « hidden » qu'on retire en js. Ça me semble pas mal. Ça marcherait même sans CSS.
# Mitigé
Posté par raphj (site web personnel) . En réponse au lien Le low javascript: le bon web enfin hype ?. Évalué à 10.
Il y a une promesse de faire sans Javascript, ou avec peu de Javascript, mais ça dépend en fait d'une bibliothèque à inclure. Donc ce n'est pas tant "sans javacript" que "utiliser javascript différemment".
D'un côté je suis content si ça permet de remplacer des choses actuellement écrites comme des SPA (avec React, Angular, ou autres) par des pages principalement HTML.
D'un autre côté, ça a l'air afficher des contrôles et des formulaires qui seront juste "silencieusement non fonctionnels" si Javascript est désactivé.
Ce serait bien à mon avis de respecter le principe "je n'affiche pas des trucs qui ne vont pas marcher", en créant les éléments qui dépendant de Javascript… en Javascript.
Par exemple, la semaine dernière, j'ai implémenté une petite barre de recherche sur une page qui affiche une liste de documents. Tout est implémenté en Javascript. La barre de recherche est donc insérée par le code Javascript lui-même. Les visiteurs sans Javascript auront une page totalement utilisable et ils pourront utiliser la recherche du navigateur à la place (toutes les infos sont dans la page, la barre de recherche ne fait que filtrer). Ils ne verront pas une barre de recherche qui s’avérera inopérante après essai infructueux (UI décevante).
En parfaite adéquation avec le « progressive enhancement » qui me parait un principe important.
[^] # Re: Moralité
Posté par raphj (site web personnel) . En réponse au lien Changement de licence pour LLVM et appel à l'aide. Évalué à 2. Dernière modification le 24 novembre 2021 à 08:44.
Pour moi, si le principe est appliqué à toutes les contributions, ça tue effectivement l'utilité / l'intérêt des licences copyleft (pour les projets en copyleft), parce que ça veut dire que potentiellement la grosse majorité du code du projet et sous cette licence très permissive. Pour les projets sous licence copyfree je suppose qu'il y aurait des effets similaires.
Cela dit, si c'est un choix que tu fais toi en tant que contributeur individuel de placer ta contribution sous une licence très permissive, c'est tout à ton honneur je suppose !
[^] # Re: Moralité
Posté par raphj (site web personnel) . En réponse au lien Changement de licence pour LLVM et appel à l'aide. Évalué à 6.
Je me demande s'il n'y aurait pas un genre de CLA qui ferait moins peur, du style « j'autorise X à changer la licence de ma contribution, si j'ai (ou les ayants droits ont) été contacté et qu'on n'a pas donné de nouvelles / on ne s'est pas opposés dans les 6 mois, ou qu'on n'est plus joignables » (en légalement plus robuste).
[^] # Re: Analyse
Posté par raphj (site web personnel) . En réponse au lien La Borne passe sanitaire (BPS), le premier produit en open hardware de la Gendarmerie !. Évalué à 6. Dernière modification le 13 novembre 2021 à 18:41.
Ah bah non, tu penses bien ? Pour ça il faudrait que TAC-Vérif soit libre, mais le libre ce n'est pas sécurisé parce que les gens peuvent lire le code source, ce qui transmettrait le covid plus facilement.
# Campus du Libre à Lyon ce weekend
Posté par raphj (site web personnel) . En réponse au journal Venez découvrir la dernière mouture de Tracim à OSXP mardi et mercredi prochains (9 & 10 novembre). Évalué à 6.
On sera également au Campus du Libre à Lyon ce weekend, n'hésitez pas à passer nous rencontrer si vous êtes dans les parages :-)
[^] # Re: Réduction du service public...
Posté par raphj (site web personnel) . En réponse au lien Le Resto U n'est pas rentable. Alors on le ferme. . Évalué à 6. Dernière modification le 26 octobre 2021 à 11:44.
Un taboulé "français" simple est rapide à faire et très peu onéreux (< 1€ par repas), tout en étant riche côté nutritif.
Graines de couscous à faire gonfler dans de l'eau froide (même pas besoin de chauffer). Eau à raz de la semoule sèche (ça doit dépasser un tout petit peu mais c'est tout), un peu de sel, ça gonfle en 10 minutes. Décoller à la fourchette quand ça a commencé à gonfler.
Petits bouts de poivron, pois chiches, persil, menthe (éventuellement) raisins secs (éventuellement), ognons (éventuellement), concombre (éventuellement), carottes (éventuellement ; tu peux les faire cuire à l'eau bouillante pour les ramollir si tu veux), poivre (éventuellement). Huile d'olive. Éventuellement du jus de citron ou du vinaigre (balsamique ou non) si envie. Attention, le moment d'ajouter l'huile et/ou le jus de citron importe, il y en a un qu'il faut faire au dernier moment pour mieux conserver mais je ne sais plus lequel.
Un plat pas cher et adaptable au goût et au besoin.
On pourra plutôt partir sur un taboulé libanais avec beaucoup plus de persil (frais) et de la tomate, et plutôt du boulgour que de la semoule de blé. C'est potentiellement plus frais. On trouve des recettes sur internet, je n'en ai jamais fait.
[^] # Re: Réduction du service public...
Posté par raphj (site web personnel) . En réponse au lien Le Resto U n'est pas rentable. Alors on le ferme. . Évalué à 5. Dernière modification le 25 octobre 2021 à 16:12.
C'est très difficile de ne pas manger assez de protéines. Il faut presque le vouloir. Il y en a partout.
Il faut un peu de tout (fer, vitamines, glucides (surtout lents), lipides, potassium, …). Avec des féculents de base (pâtes, riz, patates) des légumes (choux pour le potassium), fruits (agrumes pour la vitamine C) et des légumineuses (lentilles, pois chiches) on arrive déjà à avoir pas mal de choses. Du sel mais pas trop permet d'avoir sa dose de sodium et d'iode. De l'huile pour faire cuire les légumes et tu as de la graisse pour assimiler les vitamines des légumes.
Si tu ne manges pas que des fruits et des légumes et que tu manges pas que d'un seul ingrédient simple tu as probablement ton quotas de protéines variées.
[^] # Re: Réduction du service public...
Posté par raphj (site web personnel) . En réponse au lien Le Resto U n'est pas rentable. Alors on le ferme. . Évalué à 7.
Ça ne sonne pas ultra équilibré non plus. Au moins, le tacos bien gras rempli de frites a généralement quelques légumes.
Mais un bon sandwich peut contenir des ingrédients variés et équilibré sans problème et explosera à la fois le tacos et le jambon beurre en termes de nutrition, en plus de potentiellement les exploser en termes de goût. Points bonus si c'est avec du pain complet, le pain blanc c'est surtout plein de sucres rapides, ce qui n'est pas ultra top.
Après, il faut avoir les moyens s'acheter des ingrédients variés et avoir le temps de se préparer à manger. Le pauvre étudiant précaire qui doit travailler à côté des études pour payer le loyer et les factures manque des deux. La cantine est en théorie un bon moyen de manger varié et pas excessivement cher.
[^] # Re: Réduction du service public...
Posté par raphj (site web personnel) . En réponse au lien Le Resto U n'est pas rentable. Alors on le ferme. . Évalué à 10. Dernière modification le 25 octobre 2021 à 11:30.
La rentabilité d'un service public, c'est hors sujet. Un service public c'est fait pour rendre service au public. Ça fait fonctionner un pays. C'est une dépense nécessaire. Et si c'est bien calculé, ça baisse les coûts pour tout le monde.
Je suis content de payer des impôts et qu'une partie de mon salaire soit des cotisations si le service public tient la route. Si.
La restauration universitaire est nécessaire. Comme beaucoup de services publics, la bonne question c'est "Comment ?", pas "Est-ce que ?" (et certainement pas privatiser les parties génératrices de revenus parce que sinon bien sûr, on finit par tout arrêter).
On peut parler de coût mais si le mot rentable apparait, on ne parle pas la bonne langue.
[^] # Re: Titre édité
Posté par raphj (site web personnel) . En réponse au journal On s'en fout de vos tartiflettes. Évalué à 4.
Les kebabs n'ont pas de coquille à ma connaissance.
[^] # Re: Pas écologique
Posté par raphj (site web personnel) . En réponse au journal On s'en fout de vos tartiflettes. Évalué à 1.
Sinon je suggère d'essayer le Vebab chez Gustavo, à base de seitan. Si vous habitez dans la région grenobloise et que vous n'avez pas encore essayé, laissez-vous tenter, c'est très bon et remplace avantageusement la pomme de terre bouillie non épluchée sans sel, même si vous n'êtes pas végé.
(après, la pomme de terre, c'est cool aussi, je ne dis pas)
[^] # Re: Cohérence ?
Posté par raphj (site web personnel) . En réponse au journal Intégration continue - Travis, la stratégie commerciale défaillante ?. Évalué à 6. Dernière modification le 20 octobre 2021 à 17:51.
Oui.
Et puis, en tant que contributeur occasionnel à des projets libres, je trouve ça rafraîchissant de tomber sur une autre forge que GitHub. Encore mieux si je tombe sur un nom de domaine qui correspond au nom du projet : ça veut certainement dire que le projet contrôle l'hébergement de ses tickets et de ses requêtes de fusions et n'est pas à la merci de GitHub et de ses changements potentiels de direction pour ça.
Je haie la centralisation de GitHub. Je souhaiterais que ça n'existe pas. Je suis plus que content de me créer un compte sur des forges alternatives au besoin (sauf si elles cassent les pieds avec des contraintes débiles sur le mot de passe ou qu'elle force à avoir de la double authentification). Si quelqu'un n'est pas assez motivé pour envoyer un patch par mail ou se créer un compte sur la forge d'un projet pour proposer un patch ou rapporter un bug, peut-être que finalement ce n'était pas si important. D'ailleurs, on peut toujours rapporter un bug par mail aux dev si on est un utilisateur classique.
Si seulement on ne reproduisait pas les travers des réseaux sociaux centralisés jusqu'à dans nos développements et dans les projets libres… On peut toujours rêver.
[^] # Re: Cohérence ?
Posté par raphj (site web personnel) . En réponse au journal Intégration continue - Travis, la stratégie commerciale défaillante ?. Évalué à 9. Dernière modification le 20 octobre 2021 à 17:37.
Non, effectivement. Loin de là. On a pas mal été occupés sur le développement de Tracim lui-même. On a priorisé les nouvelles fonctionnalités, on a été pas mal pris par des demandes clients et aussi par la sortie de la version 3.10 qui est imminente. Ça a été plutôt rapide une fois qu'on s'y est mis :-)
Après effectivement, il faut s'approprier l'outil et ses concepts, trouver les bons réglages, faire les bonnes interconnexions avec la forge, un peu mimer ce qu'on avait avant pour ne pas perturber les manières de travailler, etc. Faut s'assurer que ça marche bien aussi. Dans ce genre de migration, il est « urgent de ne pas se dépêcher » :-)
Ça doit se compter en jours en temps de travail effectif, et il faut prendre en compte les context switches parce qu'on est trop peu pour se permettre de dédier une ou deux personnes à temps plein sur la mise en place de la nouvelle CI pendant plusieurs jours consécutifs.
Et puis, 11 personnes ce n'est pas 11 devs, et c'est encore moins 11 devs susceptibles de travailler sur la migration de la CI.
# Un gain de temps au quotidien
Posté par raphj (site web personnel) . En réponse au journal Intégration continue - Travis, la stratégie commerciale défaillante ?. Évalué à 7.
Je suis enthousiaste à plusieurs niveaux avec changement.
L'outillage est autrement plus pratique à utiliser au quotidien :
Avec l'interface web de Travis, tout était lent. On ne sait pas pourquoi il y a un gros espace blanc en dessous des logs du build, ce qui empêche d'utiliser efficacement la barre de défilement du navigateur. Impossible d'utiliser les outils Unix efficacement pour disséquer les résultats présentés sur cette fichue page web. La page de résumé du statut de la CI sur GitHub n'est jamais à jour. Plus difficile d'investiguer : si le build n'est pas passé et que le problème n'est pas évident, tu n'as plus qu'à deviner ce qui a pu se passer.
Bref, passer à Concourse a demandé du travail mais je suis certain que c'est un investissement rentable. On atterrit dans une nouvelle dimension.
Ça permet aussi de contribuer à rendre l'outillage nécessaire pour construire le logiciel libre qu'est Tracim lui aussi libre de bout en bout (il reste GitHub).
[^] # Re: Le téléphone étanche du pauvre
Posté par raphj (site web personnel) . En réponse au journal Simuler un clic avec libevdev et uinput. Évalué à 3. Dernière modification le 15 octobre 2021 à 18:01.
Yep, d'ailleurs ça ne s'oppose pas, si la vidéo est sponsorisée par RasLeBolVPN ou JenPeuxPlusSchield c'est exactement ce qu'il va se passer :-)
(au fait, vous connaissez SponsorBlock ?)
[^] # Re: LDLC l'a fait ça marche
Posté par raphj (site web personnel) . En réponse au lien Initiative nationale de la CGT pour la réduction du temps de travail et les 32h. Évalué à 10.
Les mois cotisés pour la retraite ?
[^] # Re: Vive les paywalls et autres conneries
Posté par raphj (site web personnel) . En réponse au lien It’s Time to Stop Paying for a VPN. Évalué à 5.
Tu peux désactiver Javascript ou supprimer les cookies en général sur ces sites pour bypasser les paywalls. Ou faire un snapshot archive.org et y accéder comme ça.
[^] # Re: Retour d'expérience
Posté par raphj (site web personnel) . En réponse au journal trsync : un outil de synchronisation bidirectionnelle pour travailler hors-ligne avec tracim. Évalué à 5. Dernière modification le 02 octobre 2021 à 18:52.
Oui. De plus, l'inode n'est unique qu'au sein d'un même système de fichier, donc si le dossier synchronisé contient deux points de montage, ce n'est pas bon.
Pire, certains systèmes de fichiers ne garantissent pas l'unicité des inodes. Pour Btrfs, par exemple, l'inode n'est unique que par sous-volume (avec le Copy-on-write, les fichiers peuvent être partagés jusqu'à la modification… et d'ailleurs, la modification d'un fichier peut aussi le faire changer d'inode). Et une partition Btrfs peut être montée entièrement sur un unique point de montage, avec tous les sous-volumes dedans.
Je suppose que c'est vrai aussi pour ZFS.
Donc ça peut causer des bugs « intéressant » effectivement, et la solution de n'accepter de synchroniser des fichiers n'appartenant qu'à un seul point de montage n'est pas suffisante.
# Liste de fichiers ignorés, prise en charge des notes
Posté par raphj (site web personnel) . En réponse au journal trsync : un outil de synchronisation bidirectionnelle pour travailler hors-ligne avec tracim. Évalué à 4. Dernière modification le 01 octobre 2021 à 11:57.
Eh bien c'est parti ! :-)
.gitignorepour Git. Une liste soit locale, soit synchronisée sur Tracim..document.htmlmais ne permet pas de les modifier. L'extension pourrait être reprise, mais le comportement de la synchronisation pour ces fichiers devra appeler les API relatives aux notes (avec un éditeur de code ou un outil WYSIWYG indépendant de trsync qui ne s'occuperait que de la synchronisation elle-même).Félicitations pour ce projet.
# Ok si les modèles durent ?
Posté par raphj (site web personnel) . En réponse au lien Fairphone lance un 3e smartphone en 3 ans : est-ce bien écolo ?. Évalué à 6.
Pourquoi pas, si tous ces modèles sont supportés longtemps ce qui a l'air d'être le cas ?
Quitte à vendre un téléphone neuf, il vaut mieux qu'il prenne en charge les derniers standard pour avoir plus de chance d'être utile plus longtemps.
L'article soulève qu'en pratique les Fairphones « ont aussi la fâcheuse réputation de devenir rapidement pénibles à utiliser, en raison des bugs et autres instabilités » mais ne rentre pas dans les détails sur ce point qui, pourtant, parait important pour répondre à la question.
De mon côté, je salue bien entendu l'initiative. On a besoin d'une production plus respectueuse de l'humain et de l'environnement. Je trouve ça dommage que les gouvernements du monde entier ne mettent pas l'accent et le paquet sur l'aspect humain (et l'écologie, bien sûr). Ça devrait être l'une de leur raison d'être. Mais à défaut…
La question que je me pose depuis longtemps, c'est que les Fairphones sont basés sur des chipsets Qualcomm, qui, j'imagine, comprennent au moins le modem et le processeur, probablement la mémoire vive, probablement la Wifi/ Bluetooth. C'est un gros morceau, est-ce qu'ils sont produits de façon responsable ? Quel est le pourcentage "Fair" du Fairphone ? (en nombre d'humains impliqués, ou en quantité de matériaux utilisés)
Ensuite, pour moi, dans "Fair" et "Human right", l'aspect logiciel libre semble important également, et le Fairphone a des caractéristiques semblables aux autres téléphones Android : c'est des blobs binaires pour les pilotes matériels. C'est la communauté qui a porté Lineage sur le Fairphone 3. Un Fairphone 3 dégooglisé n'a pas été possible avant un petit moment après sa sortie. Fairphone et /e/ sont maintenant partenaires donc il y a des efforts sur cet aspect malgré tout, et j'imagine qu'il faut choisir ses batailles.