Il peut y avoir aussi des problèmes avec les rolling releases.
Je réinstalle aussi toujours à partir d'un live USB. Je me suis fais un petit script de post-installation, plus 2 ou 3 étapes manuelles qui ne prennent pas beaucoup de temps. Au moins ça marche à chaque fois, et je suis sûr que mon système est « propre ». Quand j'installe un paquet, je le rajoute dans ma liste de paquets à installer dans le script. Avant de réinstaller, je nettoie ma liste de paquets en enlevant ce que je n'ai plus besoin.
Sur ma machine perso j'utilise Fedora 22 depuis la beta, et j'ai eu très peu de problèmes.
À mon boulot j'utilise Fedora sans problème aussi.
Fedora est assez prompt à faire les mises à jour, par exemple les versions 3.16.x de GNOME. Ubuntu ne met pas toujours à jour les versions des modules de GNOME. Certains modules restent en 3.14.0 alors que les développeurs ont sorti les versions 3.14.1 et 3.14.2 qui corrigent des bugs important (j'ai vu ça dans Debian aussi). Aussi, Ubuntu mélange les versions des modules de GNOME : certains modules sont en 3.14, d'autres sont en 3.12, d'autres sont encore plus ancien… ce qui engendre pas mal d'autres bugs. Et aussi, depuis plusieurs années, Ubuntu ne prend pas la dernière version de GNOME, mais la précédente.
Ce qui aide aussi dans Fedora est que bon nombre de packageurs sont aussi les développeurs/mainteneurs en amont. Donc ils savent comment bien intégrer leurs logiciels dans la distrib.
Utilise libpeas pour les plugins, c'est ce qui est utilisé dans gedit et d'autres applications de GNOME (libpeas provient du code de gedit à la base).
Mais, avoir un système de plugin rajoute beaucoup d'emmerdes pour le développement d'une application. Il faut que l'application définisse une API que les plugins pourront utiliser. Et, si possible, cette API ne doit pas être cassée à chaque version… Comme pour le développement d'une librairie, en gros. Avec l'age, n'importe quel code a besoin d'être restructuré un jour ou l'autre, et maintenir la compatibilité des plugins est parfois difficile et demande en tout cas plus de boulot.
De plus les plugins rajoutent de l'incertitude dans la stabilité de l'application. Toi, étant développeur de l'éditeur de texte, tu veux être certain que l'application soit stable, qu'il n'y ait pas de bugs. Avec des plugins, il peut y avoir plein de bugs imprévus. Les plugins sont généralement moins bien écrit et contiennent plus de bugs que le cœur de l'application (pcq développé par des gens moins expérimenté). Un cassage de l'API ne fait qu’aggraver les choses. Et les bugs ne sont pas forcément isolé à la fonctionnalité qu'un plugin fourni, un plugin peut faire apparaitre des bugs dans d'autres fonctionnalités. Et quand un utilisateur a plein de bugs et qu'il n'en connait pas vraiment la cause, il se dit que l'application est pourrie et va voir ailleurs.
Donc… je ne recommande pas vraiment les systèmes de plugins. En tout cas certainement pas pour une jeune application dont l'architecture du code doit encore évoluer.
Ceci dit, pour en revenir à libpeas, ça utilise sous le capot dlopen(), pour charger des shared libraries au runtime. Un plugin est donc une sorte de librairie.
Le mode setting, c'est le réglage de l'écran dans un certain mode (résolution, nombre de couleurs, fréquence de rafraichissement). Avec un mode setting atomique, les paramètres sont tous changés en même temps, ce qui devrait régler le problème des bugs graphiques quand on passe d'un mode à l'autre (quand on démarre ou éteint l'ordinateur, quand on lance une application graphique en plein écran, etc).
Bref, c'est assez génial cet Atomic Mode Setting !
Cool, un autre éditeur de texte basé sur GtkSourceView.
Sache qu'il y a le projet libgedit (dont je suis l'initiateur), qui vise à rendre le code de gedit réutilisable pour d'autres éditeurs de texte, en bougeant les fonctionnalités dans GtkSourceView notamment.
Pcq, tu as sans doute pu le remarquer, écrire un éditeur de texte from scratch avec GtkSourceView demande quand même pas mal de boulot, pour avoir une éditeur de texte convenable. gedit fait 40k lignes de code plus ou moins (sans les plugins), donc il reste encore du refactoring à faire ;-)
Les Autotools ne sont pas obsolètes… Ça a l'avantage d'être un standard, tant pour les packageurs que pour les utilisateurs qui veulent compiler les sources (le fameux ./configure, make, make install). Si chaque projet utilise un build system différent, ce serait un vrai casse-tête. CMake (je ne connais pas Scons) ne suit même pas les GNU Coding Standards, il n'y a par exemple pas de make uninstall de base (ou alors ça a changé depuis la dernière fois que je l'ai utilisé).
J'ai écris sur ce sujet un peu plus longuement sur mon blog, où je suis passé de CMake aux Autotools pour LaTeXila.
Le fichier /etc/centos-release contient le numéro de version 7.1.1503.
Autre référence, l'article CentOS sur Wikipédia utilise comme numérotation 7.1-1503.
C'est beaucoup plus simple de se référer à la version équivalente chez RHEL, c'est-à-dire « 7.1 ». Je ne vois pas pourquoi les mails d'annonce n'utilisent pas cette numérotation.
En tout cas c'est tout à fait valide de dire « CentOS 7.1 » (version raccourcie). Le fichier /etc/centos-release peut très bien servir de référence, tout autant que les mails d'annonce.
La mise à jour s'est très bien passée pour moi, avec un simple yum update. Mais je n'avais « que » entre 400 et 500 paquets à mettre à jour (je n'ai pas installé beaucoup de paquets en plus sur cette machine, c'est presque comme l'installation de base, en workstation).
Si je me rappelle bien le concept du Humble Indie Bundle, ils ouvrent le code source et rendent les jeux gratuits une fois qu'une certaine somme est atteinte. Tant que cette somme n'est pas atteinte, ce sont des logiciels propriétaires, juste ?
Étant donné que les Humble Indie Bundles ont beaucoup de succès, je suppose que certains jeux ont été libéré, non ?
La dernière fois que j'ai cherché à télécharger un de ces jeux, c'était vraiment la galère et j'ai finalement pas trouvé… Ils ne sont pas disponible de base ni dans Fedora ni dans Debian à ce que je sache.
Y a-t-il une page quelque part avec les jeux qui ont été libéré ? Mais peut-être que je suis complètement à côté de la plaque.
Ou comment réinventer la roue… Toutes les applications GNOME sont déjà passées à GTK+ 3 depuis belle lurette. Étant donné que Mate est un clone de GNOME 2, les développeurs de Mate devront faire exactement le même travail pour porter les applications à GTK+ 3…
Ce serait plus malin pour Mate de continuer à maintenir metacity, gnome-panel, gnome-applets et quelques autres modules qui vont avec. Bref, juste le desktop, pas les applications ni les librairies.
Dans LaTeXila il y a un menu Math avec les commandes principales, plus de nombreux symboles dans le panneau latéral. La complétion peut aider aussi un peu.
Avec un seul langage (Oz), le livre couvre tous les principaux paradigmes/modèles : declarative/functional programming, declarative concurrency, message-passing concurrency, explicit state (programmation impérative), object-oriented, shared-state concurrency, relational programming, GUI programming, distributed programming, constraint programming, et autres buzzword.
Même si le langage Oz n'est pas très connu, le livre est surtout un outil pédagogique. Une fois qu'on a appris pas mal de paradigmes différents, on peut choisir un language plus répandu qui est spécialisé dans le paradigme qui convient pour un certain projet. Mais cela dit, c'est un avantage d'avoir un seul langage qui supporte plusieurs paradigmes, comme ça pour des projets un peu plus gros, on peut mélanger plusieurs paradigmes tout en gardant la même syntaxe. En gros on choisit le paradigme le plus approprié suivant le besoin.
Je préfère le préciser tout de suite, j'ai contribué à cette dépêche, mais un peu trop tard, une grande partie du contenu était déjà écrit, donc je n'allais quand même pas tout modifier…
Tout d'abord, ce n'est pas un concours pour écrire la dépêche la plus longue. Il peut y avoir du contenu d'excellente qualité qui soit assez bref. Dans cette optique, est-il vraiment nécessaire de détailler les changements des principaux logiciels upstream (gnome, kde, systemd, etc). Normalement il y a déjà eu des dépêches sur ces sujets-là, donc pour moi il suffit de dire par exemple « GNOME est passé de la version 3.10 à 3.14 », avec les liens vers les dépêches parlant de GNOME 3.12 et GNOME 3.14. Donc pour moi la section « Nouvelles versions des principaux logiciels » aurait pu se résumer à quelques lignes.
Il aurait été plus intéressant de parler de choses propres à Fedora :
l'architecture en anneaux. Les produits Workstation, Server et Cloud sont sur l'anneau extérieur. Mais la dépêche ne parle pas des anneaux intérieurs : Base et Environments and Stacks.
le développement du successeur de yum, DNF, avec les librairies sous-jacentes que sont hawkey et libsolv.
détailler un peu plus le changement de mode de gouvernance.
un petit mot sur les dépôts COPR, qui sont en quelque sorte un équivalent des PPA d'Ubuntu.
un résumé des roadmaps pour les différents produits.
Je trouve que sur Linux Weekly News la proportion de bons articles est assez grande (en tout cas pour moi), et les sujets sont assez divers : développement, distribs, sécurité, le noyau Linux, …
Si je devais recommander qu'une seule source d'information pour GNU/Linux, ce serait celle-là.
Bientôt LFS sera aussi conviviale (une fois installée) que n'importe quelle autre distrib systemd/GNU/Linux, si systemd contient de plus en plus d'outils qui étaient auparavant ré-implémentés pour chaque distrib… On arrête pas le progrès.
(j'ai découvert le site de Martin Fowler récemment en me renseignant sur un de ses livres, Refactoring, et je trouve que son bliki (blog/wiki) est une vraie mine d'information, à recommander !)
Les articles ne parlent pas vraiment des roadmaps, mais avoir une direction générale à long-terme d'un logiciel est certainement quelque chose d'utile, et plus l'objectif est à court terme au plus la roadmap doit être détaillée. Par exemple pour la prochaine itération de développement, c'est une bonne idée d'avoir une idée plus précise de ce qu'on souhaite faire. Évidemment la roadmap peut changer en cours de route, si les développeurs ou les clients se rendent compte de certains problèmes (c'est pour ça qu'il vaut mieux avoir un code qui fonctionne le plus tôt possible, même s'il n'y a pas toutes les fonctionnalités).
[^] # Re: Installation après Kubuntu
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Fedora 22. Évalué à 1.
Il peut y avoir aussi des problèmes avec les rolling releases.
Je réinstalle aussi toujours à partir d'un live USB. Je me suis fais un petit script de post-installation, plus 2 ou 3 étapes manuelles qui ne prennent pas beaucoup de temps. Au moins ça marche à chaque fois, et je suis sûr que mon système est « propre ». Quand j'installe un paquet, je le rajoute dans ma liste de paquets à installer dans le script. Avant de réinstaller, je nettoie ma liste de paquets en enlevant ce que je n'ai plus besoin.
[^] # Re: Installation après Kubuntu
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Fedora 22. Évalué à 6.
Sur ma machine perso j'utilise Fedora 22 depuis la beta, et j'ai eu très peu de problèmes.
À mon boulot j'utilise Fedora sans problème aussi.
Fedora est assez prompt à faire les mises à jour, par exemple les versions 3.16.x de GNOME. Ubuntu ne met pas toujours à jour les versions des modules de GNOME. Certains modules restent en 3.14.0 alors que les développeurs ont sorti les versions 3.14.1 et 3.14.2 qui corrigent des bugs important (j'ai vu ça dans Debian aussi). Aussi, Ubuntu mélange les versions des modules de GNOME : certains modules sont en 3.14, d'autres sont en 3.12, d'autres sont encore plus ancien… ce qui engendre pas mal d'autres bugs. Et aussi, depuis plusieurs années, Ubuntu ne prend pas la dernière version de GNOME, mais la précédente.
Ce qui aide aussi dans Fedora est que bon nombre de packageurs sont aussi les développeurs/mainteneurs en amont. Donc ils savent comment bien intégrer leurs logiciels dans la distrib.
[^] # Re: Très bien mais...
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Fedora 22. Évalué à 1.
L'accélération du touchpad fonctionne très bien chez moi, avec libinput. Je n'ai rien du faire de spécial.
[^] # Re: Consulter les annonces de RC
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Sortie du noyau Linux 4.0. Évalué à 2.
Abonne-toi au flux RSS de LWN, les annonces de RC y sont toujours, et il y a plein d'autres articles intéressants.
[^] # Re: Merci pour vos réponses et le futur de IT-Edit.
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche IT-edit, un éditeur de texte avec terminaux intégrés. Évalué à 1.
Utilise libpeas pour les plugins, c'est ce qui est utilisé dans gedit et d'autres applications de GNOME (libpeas provient du code de gedit à la base).
Mais, avoir un système de plugin rajoute beaucoup d'emmerdes pour le développement d'une application. Il faut que l'application définisse une API que les plugins pourront utiliser. Et, si possible, cette API ne doit pas être cassée à chaque version… Comme pour le développement d'une librairie, en gros. Avec l'age, n'importe quel code a besoin d'être restructuré un jour ou l'autre, et maintenir la compatibilité des plugins est parfois difficile et demande en tout cas plus de boulot.
De plus les plugins rajoutent de l'incertitude dans la stabilité de l'application. Toi, étant développeur de l'éditeur de texte, tu veux être certain que l'application soit stable, qu'il n'y ait pas de bugs. Avec des plugins, il peut y avoir plein de bugs imprévus. Les plugins sont généralement moins bien écrit et contiennent plus de bugs que le cœur de l'application (pcq développé par des gens moins expérimenté). Un cassage de l'API ne fait qu’aggraver les choses. Et les bugs ne sont pas forcément isolé à la fonctionnalité qu'un plugin fourni, un plugin peut faire apparaitre des bugs dans d'autres fonctionnalités. Et quand un utilisateur a plein de bugs et qu'il n'en connait pas vraiment la cause, il se dit que l'application est pourrie et va voir ailleurs.
Donc… je ne recommande pas vraiment les systèmes de plugins. En tout cas certainement pas pour une jeune application dont l'architecture du code doit encore évoluer.
Ceci dit, pour en revenir à libpeas, ça utilise sous le capot dlopen(), pour charger des shared libraries au runtime. Un plugin est donc une sorte de librairie.
# Atomic Mode Setting
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Sortie du noyau Linux 4.0. Évalué à 10.
Quelques précisions.
Le mode setting, c'est le réglage de l'écran dans un certain mode (résolution, nombre de couleurs, fréquence de rafraichissement). Avec un mode setting atomique, les paramètres sont tous changés en même temps, ce qui devrait régler le problème des bugs graphiques quand on passe d'un mode à l'autre (quand on démarre ou éteint l'ordinateur, quand on lance une application graphique en plein écran, etc).
Bref, c'est assez génial cet Atomic Mode Setting !
# libgedit
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche IT-edit, un éditeur de texte avec terminaux intégrés. Évalué à 4. Dernière modification le 19 avril 2015 à 18:53.
Cool, un autre éditeur de texte basé sur GtkSourceView.
Sache qu'il y a le projet libgedit (dont je suis l'initiateur), qui vise à rendre le code de gedit réutilisable pour d'autres éditeurs de texte, en bougeant les fonctionnalités dans GtkSourceView notamment.
Pcq, tu as sans doute pu le remarquer, écrire un éditeur de texte from scratch avec GtkSourceView demande quand même pas mal de boulot, pour avoir une éditeur de texte convenable. gedit fait 40k lignes de code plus ou moins (sans les plugins), donc il reste encore du refactoring à faire ;-)
[^] # Re: Quel est l'interet de GNOME Builder ?
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.16 - nettoyage de printemps. Évalué à 5.
Les Autotools ne sont pas obsolètes… Ça a l'avantage d'être un standard, tant pour les packageurs que pour les utilisateurs qui veulent compiler les sources (le fameux ./configure, make, make install). Si chaque projet utilise un build system différent, ce serait un vrai casse-tête. CMake (je ne connais pas Scons) ne suit même pas les GNU Coding Standards, il n'y a par exemple pas de make uninstall de base (ou alors ça a changé depuis la dernière fois que je l'ai utilisé).
J'ai écris sur ce sujet un peu plus longuement sur mon blog, où je suis passé de CMake aux Autotools pour LaTeXila.
# /etc/centos-release : version 7.1.1503
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche CentOS 7 (1503) ou CentOS-7 (1503) : ne m'appelez pas CentOS 7.1 !. Évalué à 3. Dernière modification le 07 avril 2015 à 11:11.
Le fichier /etc/centos-release contient le numéro de version 7.1.1503.
Autre référence, l'article CentOS sur Wikipédia utilise comme numérotation 7.1-1503.
C'est beaucoup plus simple de se référer à la version équivalente chez RHEL, c'est-à-dire « 7.1 ». Je ne vois pas pourquoi les mails d'annonce n'utilisent pas cette numérotation.
En tout cas c'est tout à fait valide de dire « CentOS 7.1 » (version raccourcie). Le fichier /etc/centos-release peut très bien servir de référence, tout autant que les mails d'annonce.
[^] # Re: En mise à jour ça ne se passe pas nécessairement très bien
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche CentOS 7 (1503) ou CentOS-7 (1503) : ne m'appelez pas CentOS 7.1 !. Évalué à 1.
La mise à jour s'est très bien passée pour moi, avec un simple yum update. Mais je n'avais « que » entre 400 et 500 paquets à mettre à jour (je n'ai pas installé beaucoup de paquets en plus sur cette machine, c'est presque comme l'installation de base, en workstation).
[^] # Re: Où sont ceux sous licence libre ?
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Humble Indie Bundle 14! . Évalué à 1.
Ben voilà, il me semblait bien.
# Où sont ceux sous licence libre ?
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Humble Indie Bundle 14! . Évalué à -5.
Si je me rappelle bien le concept du Humble Indie Bundle, ils ouvrent le code source et rendent les jeux gratuits une fois qu'une certaine somme est atteinte. Tant que cette somme n'est pas atteinte, ce sont des logiciels propriétaires, juste ?
Étant donné que les Humble Indie Bundles ont beaucoup de succès, je suppose que certains jeux ont été libéré, non ?
La dernière fois que j'ai cherché à télécharger un de ces jeux, c'était vraiment la galère et j'ai finalement pas trouvé… Ils ne sont pas disponible de base ni dans Fedora ni dans Debian à ce que je sache.
Y a-t-il une page quelque part avec les jeux qui ont été libéré ? Mais peut-être que je suis complètement à côté de la plaque.
[^] # Re: Wayland will be the end for them !
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Xfce 4.12 est là !. Évalué à 1. Dernière modification le 30 mars 2015 à 14:55.
Ou comment réinventer la roue… Toutes les applications GNOME sont déjà passées à GTK+ 3 depuis belle lurette. Étant donné que Mate est un clone de GNOME 2, les développeurs de Mate devront faire exactement le même travail pour porter les applications à GTK+ 3…
Ce serait plus malin pour Mate de continuer à maintenir metacity, gnome-panel, gnome-applets et quelques autres modules qui vont avec. Bref, juste le desktop, pas les applications ni les librairies.
[^] # Re: éditeur d’équation
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche LaTeXila 3.16 plus campagne de financement. Évalué à 1.
Dans LaTeXila il y a un menu Math avec les commandes principales, plus de nombreux symboles dans le panneau latéral. La complétion peut aider aussi un peu.
[^] # Re: Qui utilise des IDE LaTeX ?
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche LaTeXila 3.16 plus campagne de financement. Évalué à 3.
Pour ma part, j'ai appris grâce au livre LaTeX par la pratique de Christian Rolland, mais je pense qu'il n'est plus en vente (à part d'occasion).
Mais il y a de nombreux autres livres sur LaTeX, par exemple celui de la collection Framabook (sous licence libre): Tout ce que vous avez toujours voulu savoir sur LaTeX sans jamais oser le demander, de Vincent Lozano.
[^] # Re: Qui utilise des IDE LaTeX ?
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche LaTeXila 3.16 plus campagne de financement. Évalué à 10.
Un éditeur LaTeX avec interface graphique a quand même des avantages :
[^] # Re: Fedora se cale sur Debian ?
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Vidéos DevConf 2015 disponibles. Évalué à 2.
Non, Fedora prend toujours la dernière version de GNOME, il n'y a pas de retard.
Pour le matériel, il n'y a pas plus de détails.
[^] # Re: La vrai question la derrière
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Un sondage pour la numérotation des versions de Linux. Évalué à 0.
Et puis entre-temps on a inventé… l'écriture ! Dingue ça.
# Autre livre
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Récent livre pour apprendre Haskell et la programmation fonctionnelle. Évalué à 3.
Autre livre très intéressant :
Concepts, Techniques, and Models of Computer Programming
Avec un seul langage (Oz), le livre couvre tous les principaux paradigmes/modèles : declarative/functional programming, declarative concurrency, message-passing concurrency, explicit state (programmation impérative), object-oriented, shared-state concurrency, relational programming, GUI programming, distributed programming, constraint programming, et autres buzzword.
Voir aussi cette page de Peter Norvig (qui travaille chez Google, et a co-écrit Le livre sur l'intelligence artificielle) :
Teach Yourself Programming in Ten Years
Même si le langage Oz n'est pas très connu, le livre est surtout un outil pédagogique. Une fois qu'on a appris pas mal de paradigmes différents, on peut choisir un language plus répandu qui est spécialisé dans le paradigme qui convient pour un certain projet. Mais cela dit, c'est un avantage d'avoir un seul langage qui supporte plusieurs paradigmes, comme ça pour des projets un peu plus gros, on peut mélanger plusieurs paradigmes tout en gardant la même syntaxe. En gros on choisit le paradigme le plus approprié suivant le besoin.
# Quelques idées pour améliorer la dépêche suivante sur Fedora
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Fedora 21. Évalué à 4.
Je préfère le préciser tout de suite, j'ai contribué à cette dépêche, mais un peu trop tard, une grande partie du contenu était déjà écrit, donc je n'allais quand même pas tout modifier…
Tout d'abord, ce n'est pas un concours pour écrire la dépêche la plus longue. Il peut y avoir du contenu d'excellente qualité qui soit assez bref. Dans cette optique, est-il vraiment nécessaire de détailler les changements des principaux logiciels upstream (gnome, kde, systemd, etc). Normalement il y a déjà eu des dépêches sur ces sujets-là, donc pour moi il suffit de dire par exemple « GNOME est passé de la version 3.10 à 3.14 », avec les liens vers les dépêches parlant de GNOME 3.12 et GNOME 3.14. Donc pour moi la section « Nouvelles versions des principaux logiciels » aurait pu se résumer à quelques lignes.
Il aurait été plus intéressant de parler de choses propres à Fedora :
[^] # Re: Petites précisions utiles
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Fedora 21. Évalué à 1.
Voir aussi les articles sur le mode d'organisation de Fedora, et sur le pourquoi du public cible de Fedora Workstation (càd les développeurs).
[^] # Re: Vive les journaux bookmark
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Journal Bookmark #2. Évalué à 1.
Je trouve que sur Linux Weekly News la proportion de bons articles est assez grande (en tout cas pour moi), et les sujets sont assez divers : développement, distribs, sécurité, le noyau Linux, …
Si je devais recommander qu'une seule source d'information pour GNU/Linux, ce serait celle-là.
# Sur le serveur du projet auquel on contribue
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au sondage Ma page perso est hébergée sur.... Évalué à 3.
Quand on contribue régulièrement à un logiciel libre, les contributeurs ou mainteneurs ont souvent une page perso sur le site web du projet.
Par exemple j'ai ma page perso sur le wiki de GNOME, ainsi qu'un blog.
# Distrib systemd/GNU/Linux
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Linux From Scratch 7.6 version systemd traduite en français !. Évalué à 4.
Bientôt LFS sera aussi conviviale (une fois installée) que n'importe quelle autre distrib systemd/GNU/Linux, si systemd contient de plus en plus d'outils qui étaient auparavant ré-implémentés pour chaque distrib… On arrête pas le progrès.
[^] # Re: wtf
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Du nouveau pour Thunderbird !. Évalué à 3.
Pour des articles plus sérieux sur les méthodologies agiles, il y a le site de Martin Fowler, avec des articles comme :
(j'ai découvert le site de Martin Fowler récemment en me renseignant sur un de ses livres, Refactoring, et je trouve que son bliki (blog/wiki) est une vraie mine d'information, à recommander !)
Les articles ne parlent pas vraiment des roadmaps, mais avoir une direction générale à long-terme d'un logiciel est certainement quelque chose d'utile, et plus l'objectif est à court terme au plus la roadmap doit être détaillée. Par exemple pour la prochaine itération de développement, c'est une bonne idée d'avoir une idée plus précise de ce qu'on souhaite faire. Évidemment la roadmap peut changer en cours de route, si les développeurs ou les clients se rendent compte de certains problèmes (c'est pour ça qu'il vaut mieux avoir un code qui fonctionne le plus tôt possible, même s'il n'y a pas toutes les fonctionnalités).