Sébastien Wilmet a écrit 701 commentaires

OSTree n'a rien à voir avec les RPM. Il y a plein d'usages différents possibles. Par exemple OSTree est déjà utilisé pour GNOME Continuous, un système d'intégration continue.

« Multi-level “Rings” Approach », voir l'article sur Fedora magazine.

De toute façon les articles « payants » sont disponibles gratuitement une semaine plus tard. Sur LWN il y aussi l'équivalent des journaux bookmarks, avec des liens vers d'autres articles trouvés sur le web, avec une citation d'un passage intéressant.

Le contenu est varié, il y a plusieurs catégories : sécurité, kernel, distribs, développement, annonces, etc.

Bref, à recommander vivement.

Si on prend deux extrêmes, gedit sans aucun plugin, et Eclipse, l'un est clairement un éditeur de texte et l'autre un IDE. Les termes éditeurs de texte et IDE existent, on les utilise dans la vie courante. Essayer de donner une définition à ces mots est donc un comportement normal.

Le but principal du journal était plutôt d'expliquer la différence entre généraliste et spécialisé. La plupart des éditeurs de texte et IDE disponibles actuellement sont généralistes. L'idée du journal était de donner envie à certains développeurs de développer des applications spécialisées, plus simple de configuration et plus pratique à utiliser que des usines à gaz.

Donner un nom à une chose est important. Les design patterns en POO est très important par exemple. Si je te parles de méthode factory, tu comprends tout de suite de quoi je parle.

Une autre chose importante est de trouver des axes de différentiation. J'en ai donné quelques uns dans le journal, et d'autres en ont donné d'autres dans les commentaires.

Par exemple, savoir qu'un certain IDE possède un modèle de code est intéressant, car ça implique qu'il puisse y avoir des fonctionnalités plus intéressantes.

D'après les (plus vieux) développeurs de gedit, il ne manque pas grand chose à gedit pour être à la hauteur de sublime text. C'est juste une question de découvrir les différents plugins disponibles, et de s'habituer aux raccourcis clavier. Et gedit existe depuis plus longtemps que sublime text…

Le concept de projet, encore un autre axe de différentiation.

Une chose que je n'ai pas dit, c'est qu'avec le temps (ajouts de fonctionnalités), ou avec des plugins, il y a moyen de transformer un éditeur de texte en un IDE.

Par exemple gedit est considéré comme un simple éditeur de texte, mais avec des plugins il y a moyen de le configurer comme un IDE léger pour Vala.

Oui c'est vrai qu'avec les descriptions que j'ai donné, Emacs est plutôt un IDE. Pourtant on le présente plus comme un éditeur de texte, au même titre que Vim. La différence entre Emacs et Eclipse est le fait qu'Eclipse a une GUI, tandis qu'Emacs s'utilise plus en mode texte/commandes. C'est un autre point de différenciation, et comme je l'ai dit au début du journal, ce sont plutôt des niveaux de gris.

Dans tous les cas, Emacs est généraliste, il y a moyen de le configurer pour faire plein de tâches différentes, on est bien d'accord là-dessus.

Pas sûr qu'un éditeur de texte où le mode par défaut n'est pas l'édition de texte, soit un bon choix.

Si tu te réfères à Vi, par défaut c'est le mode d'édition de texte. Pour passer en mode insertion, il faut appuyer sur i.

Les étudiants sont sensés travailler du 19 mai au 22 août, avec une évaluation à mi-terme fin juin. Ce n'est pas un temps plein pendant toute la période, les étudiants peuvent prendre une semaine ou deux de vacances, avoir des examens, etc.

Mais dans l'unif où j'ai étudié, les examens finissent fin juin, après l'évaluation à mi-terme ! Et c'est un peu près comme ça partout en Belgique, et sans doute dans de nombreux pays européens (la France aussi ?).

L'année passée le GSoC se passait de mi-juin à fin septembre, ce qui correspondait bien à mes études (et donc j'ai fait le GSoC). Lors des évaluations des étudiants, ils ont posé comme question si les dates les arrangeaient bien. Peut-être que beaucoup se sont pleins, et donc ils sont revenus aux dates d'avant. Ou bien ils comptent alterner, pour qu'une année ça arrange bien les européens, une autre année ça arrange mieux d'autres, etc. L'idéal serait d'avoir un système plus flexible, où chaque étudiant choisis les dates parmi plusieurs choix (mais pour l'organisation ce serait plus difficile).

(il n'a quasi pas de dépendance)

Ça aurait été mieux d'avoir une dépendance à GtkSourceView au lieu d'avoir une copie des sources d'une très vielle version, sans doute contenant des bugs qui ont été corrigés upstream…

Il innove sur le design, j'imagine.

Sinon, pour l'avoir implémenté, la recherche (et remplacement) par regex est mieux que dans Vim, en tout cas pour certains aspects : les occurrences peuvent faire plusieurs lignes ; et il y a le report d'erreurs dans l'UI quand une regex ou le texte de remplacement contient des erreurs de syntaxe ; une fois que les occurrences sont trouvées dans le text buffer, les emplacements sont retenus, il ne faut plus refaire de recherche pour naviguer dans les occurrences.

Une solution serait d'utiliser plus de composants de GNOME, au lieu de réinventer la roue dans Xfce.

Quand on installe Xfce dans Debian ou Fedora, on se retrouve avec plein d'applications différentes que celles de GNOME. Les applications GNOME pourraient être installées à la place.

Pour le window manager, ça doit être faisable de réutiliser mutter à la place de Xfwm4. Xfce profiterait ainsi du portage de mutter à Wayland.

Pour le stockage des paramètres, GSettings et dconf feraient très bien l'affaire. Pour la configuration du desktop, celui de GNOME pourrait être utilisé, avec peut-être quelques modifications.

Les devs d'Xfce pourraient ainsi se concentrer sur le panel, les applets, et quelques autres modules. Ça remplacerait en quelque sorte le mode fallback de GNOME 3. On pourrait reprendre les bonnes idées de gnome-shell pour les amener dans un bureau traditionnel, comme la meilleure gestion des notifications.

Mate a forké l'ensemble de Gnome 2, incluant aussi les applications. C'est beaucoup plus sein d'esprit de « simplement » continuer à maintenir gnome-panel, metacity, gnome-applets, et les autres modules qui vont avec. Rien qu'avec ces modules-là, il y a déjà beaucoup de travail de maintenance. Alors avec l'ensemble de Gnome, c'est de la pure folie.

Mais comme dit le monsieur en haut, les développeurs de Mate reviennent à la raison il parait.

CentOS est donc en quelque sorte une Fedora LTS (long term support).

La question était plutôt quel terme on utilise dans une discussion.

En français, on a la chance de ne pas avoir le même mot pour libre et gratuit. En anglais, le mot « libre » est aussi utilisé. Par exemple « libre software », ou « free/libre software ».

Et avec des applications comme LibreOffice, il faut espérer que le mot libre rentre plus facilement dans le vocabulaire des anglophones (pour les adeptes du libre en tout cas).

Entièrement d'accord. Il parait que GObject en C++ vérifie plus de choses à la compilation.

(l'exemple est assez ancien, GtkObject et GtkSignal n'existent plus depuis un bon bout de temps, mais les principes restent valides)

On peut espérer dans le futur avoir des plugins pour GCC ou Clang pour faire ce genre de vérifications. Et un développeur a justement commencé ce boulot récemment pour Clang.

Le style épuré du Python vient principalement du fait que ce n'est pas un langage à typage explicite. Étant donné que le type d'une variable est une forme d'auto-documentation, je ne vois pas où est l'avantage.

Au lieu de fixer un langage qui n'est pas bien conçu dès le départ (pour des grosses applications), c'est plus intéressant de créer un nouveau langage. Rust est un excellent exemple, puisque le compilateur fait plus de vérifications que pour le C.

TypeScript (pour JavaScript) et mypy (pour Python) démontrent bien que des gens sont intéressés par le typage statique, tout en bénéficiant de fonctionnalités de haut niveau.

Mes questions posées dans le journal ainsi que dans ce thread restent toujours sans réponse… J'ai pu aussi remarquer quelques moinssages du journal. Ce qui prouve sans doute que certains ne sont pas d'accord (alors que marquer un journal comme « inutile » est différent de marquer son désaccord).

Comme dirait je ne sais plus qui, « On a toujours tord d'avoir raison trop tôt. »

On en reparle dans 20 ans :-) ?

Intéressant, en effet.

TypeScript is designed for development of large applications

Ça confirme mon point de vue.

Quoi qu'on en pense, Microsoft est assez bon dans les langages de programmation. Je n'irais pas à dire que Visual Basic est bien, il faut quand même pas exagérer. Mais C# et .NET ont l'air bien foutu. Et des initiatives comme TypeScript est une bonne idée aussi je trouve.

C'est tout le débat entre les langages à typage statique et dynamique. Je suis tout à fait conscient que Python est utilisé pour des gros, voir très gros, logiciels. Mais je ne suis pas convaincu.

Quand on écrit from scratch un nouveau programme, et qu'on est le seul développeur, forcément on a une bonne connaissance du code (mais ça ne va plus de même quelques mois ou années plus tard). Mais quand on doit plonger dans du code Python qu'on ne connait pas, j'en ai l'expérience, je trouve ça horrible. Quand on voit le prototype d'une fonction, on ne sait même pas de quel type sont les arguments ! (bon, j'ai entendu qu'il était possible de définir le type, dans ce cas-là, mais combien de développeurs le font ?) Il faut trouver les appels de la fonction en question, voir quelles variables sont passées en arguments, pour espérer savoir de quel type sont les variables. Avec un peu de malchance, il faut recommencer le processus (trouver l'appel de la seconde fonction, etc).

Autre exemple, quand on veut faire du refactoring, renommer une méthode, une classe, etc. J'ai donné l'exemple dans le journal de la méthode « show ». Vas-y pour trouver tous les appels de la méthode show dans un code volumineux… Avec une bonne greppabilité du code, et une compilation pour détecter les erreurs, aucun soucis.

Et je suis loin d'être le seul à penser ce genre de choses. Bien sur ça ne fait pas très plaisir à entendre quand on est convaincu par les langages dynamique (pour des gros programmes), et qu'on y a travaillé de cette façon pendant plusieurs années… J'aimerais pourtant avoir tord, mais j'aimerais qu'on m'explique comment on procède dans les deux situations que je viens de décrire.

Evolution a l'air d'avoir quand même beaucoup d'éléments réutilisables, dont EDS qui sert à gérer le carnet d'adresses et le calendrier. Il y a aussi Camel pour gérer plein de choses en rapport avec les mails, comme les objets MIME, le protocole IMAP, etc.

Les développeurs de Yorba ont quand même sans doute raison sur un point, c'est que ces librairies sont assez vielles. Il n'y a pas que le code qui est ancien, il y a aussi l'API. Pour le code, c'est plus facile de le moderniser, tandis que pour l'API, ils sont un peu coincés. Il y a sans doute moyen de créer une API plus moderne, basée sur GIO notamment. Ils pourraient évidemment casser l'API, sortir une nouvelle version majeure, etc, mais ça demande beaucoup d'efforts, avec pour risque d'amener des régressions.

Mais de là à recommencer from scratch une toute nouvelle implémentation, il faut vraiment le vouloir.

Sans parler de Music, Photo, et d'autres noms pas pratique à chercher dans un moteur de recherche. Au lieu d'améliorer Rhythmbox ou Banshee (pour la musique); eog (Eye of GNOME), Shotwell ou encore gthumb (pour visionner des images).

J'aime bien les technologies de GNOME, en tant que programmeur. Mais il y a plein de choses pour lesquelles je ne suis pas d'accord dans les directions que prend GNOME. Heureusement, ça n'impacte pas le petit monde des éditeurs de texte et GtkSourceView.