Oui, dans des cas très particuliers, grep te sortira un ou deux résultats non voulus, mais le but premier est de savoir où est appelé telle ou telle fonction. Donc c'est très loin d'être grave…
Exact. Pour éviter ce souci, les dernières versions des bibliothèques GNOME comprennent une surcouche nommée GObject-Introspection qui permet de régénérer des bindings "fiables" pour chaque nouvelle version de Vala.
Je ne parlais pas des bindings, je parlais du fait que les mainteneurs d'applications doivent adapter le code pour utiliser les nouvelles API, si ils veulent rester à jour par rapport à GTK+ etc.
Si ce boulot est fait petit à petit, au fur et à mesure des versions, ça ne demande pas trop trop de temps. Mais si on rajoute les incompatibilités entre les différentes versions de Vala, ça rajoute du boulot supplémentaire, dont on se passerait bien.
Posté par swilmet .
En réponse à la dépêche Sortie de Val(a)IDE 0.7.2.
Évalué à -2.
Dernière modification le 02 janvier 2013 à 13:46.
ne sortir que des méthodes et pas de variables du même nom par exemple
Tu as déjà vu une variable portant le nom gtk_text_view_new_with_buffer ?
si tu as plusieurs méthodes avec des paramètres différents mais du même nom
Ça n'existe pas en C.
Là où grep fonctionne très bien pour du code C, pour d'autres langages comme Java il faut utiliser les fonctionnalités d'un IDE comme Eclipse (outil refactoring pour renommer une méthode ou une classe, par exemple).
Mais la verbosité du C est aussi utile pour la compréhension du code. Quand on a une hiérarchie importante de classes, le fait d'avoir le nom complet des fonctions permet de savoir de quelle classe elle vient, et donc on retrouve plus rapidement la documentation.
sur le code «greppable», soit j'ai pas compris, soit ça s'applique à plus ou moins tous les langages objets (en C++, Java, … t'auras le même problème pour «grepper», non ?)
Oui. Le C est un langage un peu plus verbeux, mais ça a des avantages.
Après quelques années d'utilisation de Vala, je conseillerais plutôt le C maintenant. Il y a des avantages à Vala, mais aussi des (gros) inconvénients.
Si on veut faire du GLib/GObject en C, c'est vrai qu'il y a pas mal de code de « remplissage ». En Vala, les spécificités de GObject (interfaces, classes, propriétés, signaux, etc) sont directement intégrés dans la syntaxe du langage.
Ce qui est pas mal aussi, c'est les closures, ou fonctions anonymes où on peut appeler des variables qui sont déclarées en-dehors du corps de la closure. C'est pratique pour attacher un callback à un signal : le code de la fonction est au même endroit. C'est à réserver que pour les petites fonctions, bien évidemment.
Autre point fort de Vala : la gestion automatique de la mémoire (qui se fait avec un compteur, quand il tombe à 0 la mémoire est libérée). Mais ça peut être vu aussi comme un point faible pour Vala, car le compilateur valac fait parfois des trucs vraiment pas optimisé, notamment quand des chaines de caractères sont manipulées.
Il y a d'autres (gros) désavantages à Vala. Déjà, valac est assez buggé (bon, avec le temps ça s'améliore, mais c'est pas encore ça). Donc quand on trouve un bug dans Vala, on perd énormément de temps rien que pour se rendre compte que ça vient de Vala, il faut analyser le code C généré (qui est assez immonde), rapporter/corriger le bug, trouver un contournement en attendant, etc.
Quand vous faites du C, vous regardez souvent le code assembleur que GCC génère, pcq GCC est buggé ? Non, évidemment pas.
Faire du Vala, c'est rajouter une couche de maintenance en plus. L'API en C peut changer, des trucs deviennent obsolètes (surtout pour GTK+ ces derniers temps). Mais la « couche » Vala peut changer aussi. Ça demande du travail de maintenance en plus, qu'on n'a pas quand on fait du C.
Bref, pour développer une application Gnome, je conseillerais plutôt le C. Quand on voit une classe GObject en C, on se demande d'abord qu'est-ce que c'est ce bazar, mais finalement on s'habitue, c'est pas si dérangeant que ça.
Ce qui est bien avec le C, aussi, c'est que le code est facilement « greppable » : on utilise le nom complet des fonctions. En Vala, on utilise objet.méthode(). Quand « méthode » est un nom très court qui revient pour beaucoup d'objets (get, set, …), c'est difficile de trouver tous les endroits dans le code où la méthode est appelée. Dans ce cas c'est plus facile de grepper dans le code C généré, puis d'essayer de retrouver l'endroit exact dans le code Vala, ce qui n'est pas très pratique.
Il y aura toujours un peu de maintenance à faire, pour que ça fonctionne toujours bien avec les dernières versions des dépendances, et pour porter si besoin le code sur d'autres plateformes. Bien que pour sed il ne doit pas y avoir beaucoup de dépendances, et elles sont à mon avis très stable (pas de cassage de l'API à tout bout de champ).
Et si un jour un chercheur publie un article avec un tout nouveau algorithme ayant une complexité calculatoire moindre, c'est toujours intéressant de l'implémenter, pour ne pas rester à la traine par rapport aux autres implémentations.
Paolo Bonzini était le seul mainteneur de sed ? Il y a quelqu'un pour le remplacer ? Je ne vois aucune information à ce sujet.
Beaucoup d'outils comme sed conviennent maintenant à la plupart des besoins des utilisateurs. Il y a de moins en moins de raisons de vouloir contribuer. Ce n'était à mon avis pas le cas dans les années 90. Je peux me tromper, mais je pense qu'en faisant des statistiques, on pourrait voir que ces dernières années il y a moins de contributions que dans les années 90. Pourtant, pour la pérennité à long terme de ces logiciels, il faut de nouveaux développeurs, qui doivent être suffisamment calé dans le domaine.
Y aura-t-il toujours des développeurs suffisamment compétents pour maintenir les trucs comme sed ?
Le risque est qu'un jour, plus personne ne comprenne pourquoi certaines parties du code ont été écrite d'une telle manière, puisque plus personne n'y a touché depuis des années, et que la personne ayant écrit le code n'a pas laissé suffisamment de documentation ou de commentaires, et que la personne n'est plus disponible.
Je pense qu'à long terme, c'est un risque qu'il ne faut pas négliger, et donc, raison de plus pour bien documenter son code ;)
Pour le chemin du fichier à insérer, ce serait pratique, en effet. Il y a moyen aussi de compléter le chemin du fichier directement avec la complétion.
Donc, en gros, quand on fait ctrl+espace là où on doit donner un chemin de fichier, on affiche les répertoires et fichiers relatifs, plus éventuellement une entrée en plus « Sélectionner un fichier… » pour ouvrir une fenêtre de dialogue.
On pourrait imaginer une action pour directement ouvrir la boite de dialogue, et qui insérerait le chemin relatif du fichier sélectionné.
La complétion des balises n'est pas encore parfaite, il manque pas mal de choses, comme pour l'insertion d'une figure (l'environnement figure, includegraphics, etc.). Comme j'en avais parlé avec Simon, je préfère améliorer la complétion que de rajouter un wizard.
Pour la création d'un tableau, la complétion peut être améliorée aussi, mais ça devient plus délicat pour l'intérieur du tableau : comment séparer les lignes et colonnes.
À partir du menu LaTeX, on peut insérer une table ou un tableau, mais ce qui est inséré n'est pas très complet. Ce serait bien d'insérer à ce moment-là un exemple avec 2 lignes et 2 colonnes (vides). Et aussi rajouter un bouton dans la 2e barre d'outils, juste à côté de l'insertion d'une figure.
PyGTK est obsolète. Avec GObject Introspection et PyGI, les bindings pour Python des bibliothèques basées sur GObject (comme GTK+) se font de manière automatique.
C'est intéressant de faire la migration, parce que je pense que PyGTK n'est plus maintenu.
En tout cas je trouve que ce genre de programmes est intéressant. De plus en plus de personnes utilisent des services web comme Facebook ou autre pour ce genre de choses, alors que des applications font très bien l'affaire.
Tout d'abord, je ne te remercies vraiment pas pour ce script, je viens de perdre mon après-midi à le personnaliser, fignoler, … ;)
Plus sérieusement, pour savoir si on est root ou pas, c'est plus simple d'utiliser :
if [[ ${EUID} == 0 ]]
Pour git, si la branche origin/branch n'existe pas, il y a une erreur :
fatal: ambiguous argument 'origin/my-prompt..my-prompt': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
Je me souviens aussi qu'il y a un meilleur moyen pour obtenir les infos de git, au lieu d'utiliser des commandes comme git branch, git diff, etc. Mais je sais plus quel est ce meilleur moyen, je te laisse chercher ;)
Sinon sur le web y a déjà plein d'autres prompt bash pour git, avec certaines choses utiles, mais malheureusement plein d'autres trucs inutiles (mettre dans une couleur différente selon l'heure du dernier commit, …). Juste le nom de la branche avec quelques couleurs, c'est très bien !
Quand j'explique qu'un des avantages, sous Linux, c'est le choix, notamment pour le gestionnaire de bureaux, les gens ne comprennent pas en quoi c'est bien.
Mais quand ils commenceront à se plaindre des nouvelles interfaces, là ils comprendront peut-être enfin…
Si la tendance des interfaces unifiées (Unity, GNOME 3, …) ne plait pas, il y a toujours des alternatives : Xfce, tiling (awesome, …), etc etc.
ça ne m'intéresse pas d'avoir de nouveaux trucs et 32 mises-à-jour dans ma distribution tous 3 jours. Mais encore une fois, j'adore Fedora, c'est une excellente distribution ;)
C'est que tu n'as pas compris la philosophie de Fedora alors, qui est d'être leading-edge, et donc par conséquent aussi bleeding edge : en intégrant les toutes dernières technologies en grandeur nature, y a forcément des bugs qui apparaissent.
Justement, je trouve ça bête d'utiliser des pipes (donc plusieurs processus) dans l'unique but d'afficher la progression. D'ailleurs ça ne m'étonnerait pas que le script que j'avais testé se basait sur pv… cp et mv n'ont besoin que d'un seul processus, à ma connaissance.
Je ne sais plus pourquoi je n'utilise plus le script, sans doute pcq il était trop limité (peu ou pas d'options, …).
L'affichage de la progression devrait être implémenté directement dans l'outil qui effectue la copie ou le déplacement des fichiers. Cela n'exclus évidemment pas le fait que l'outil utilise une bibliothèque pour l'affichage de la progression (mais je ne sais pas si une telle bibliothèque existe).
Ce qu'il me manque, c'est un cp et mv --progress. J'avais testé une fois un script de ce genre, mais c'était plus un hack qu'autre chose, en utilisant tar (sans compression) dans une série de pipes.
Ces derniers temps il y a beaucoup de refactoring dans GTK+, tant interne (donc qui n'affecte pas l'API) qu'externe (qui propose une nouvelle API et rendant obsolète l'ancienne).
Pour le refactoring interne, c'est surtout pour utiliser Clutter, permettant ainsi de profiter de l'accélération matérielle. Les développeurs se demandaient il y a quelques années si ce n'était pas mieux de recommencer un tout nouveau toolkit graphique basé sur Clutter, au lieu d'adapter GTK+. En fait les deux se produisent, puisqu'il y a la nouvelle bibliothèque Mx.
Il y a aussi pas mal de changements dans l'API, ce qui demande pas mal de boulot pour les développeurs d'applications.
Et à côté de ça, elementary a un support pour l'accélération graphique depuis le début, et l'API semble vraiment stable. Par contre point de vue fonctionnalités, je pense que GTK+ est plus complet.
Les autres bibliothèques des EFL (eio etc) semblent avoir le même but que la GLib, GIO, etc. De ce côté-là, je pense que GNOME a un gros avantage : GObject-introspection, qui permet d'utiliser n'importe quelle bibliothèque basée sur GObject dans un autre langage que le C, sans devoir créer et maintenir des bindings. Pour l'instant Python et Javascript sont supportés (et dans une certaine mesure Vala, mais GObject-introspection n'est pas encore tout à fait au point pour Vala).
Bref, la base de GNOME (GObject, GLib, GIO etc) est très bien, mais GTK+ se fait un peu vieux… Et pour les développeurs d'applications, c'est plus intéressant de se baser sur une API qui ne risque pas de changer d'ici un an ou deux.
« Anyway, summary is: I wish them good luck, they are now going their own way, stuck in a legacy stack with little new engineering, becoming an island of their own. »
Une autre solutions serait une distribution hybride entre du long time release (Red Hat/Debian) et du rolling release (Arch/Gentoo). Une « base système » la plus stable possible et qui ne bouge pas pendant longtemps et un rétroportage régulier des derniers logiciels utilisateurs (firefox, etc).
Un problème aussi c'est que le basesystem sous les distribs Linux est divisé en plein de petits (et moins petits) paquets. Pareil évidemment pour les paquets des autres logiciels. Au final, pratiquement chaque système a un ensemble de paquets installés différent, ce qui donne une explosion de la complexité à faire de bons tests pour trouver et corriger les bugs etc. Pour le basesystem, c'est assez critique. Les développeurs BSD l'ont bien compris et développent le basesystem comme un tout.
Un article intéressant, qui montre que certains devs Linux sont conscients des problèmes de stabilité et essayent de trouver des solutions (en gros faire un basesystem de type BSD, tout mettre dans git et faire tourner des tests automatiques assez poussés) :
[^] # Re: Prendre le taureau par les cornes
Posté par swilmet . En réponse au journal [HS] Développeur un peu perdu… ou pas… Que faire maintenant ? Changer de vie ?. Évalué à 0.
C'est le principe de la méritocratie, en gros.
[^] # Re: Pourquoi Vala?
Posté par swilmet . En réponse à la dépêche Sortie de Val(a)IDE 0.7.2. Évalué à 0.
Je ne vois pas où tu veux en venir.
Oui, dans des cas très particuliers, grep te sortira un ou deux résultats non voulus, mais le but premier est de savoir où est appelé telle ou telle fonction. Donc c'est très loin d'être grave…
[^] # Re: Pourquoi Vala?
Posté par swilmet . En réponse à la dépêche Sortie de Val(a)IDE 0.7.2. Évalué à 1.
Je ne parlais pas des bindings, je parlais du fait que les mainteneurs d'applications doivent adapter le code pour utiliser les nouvelles API, si ils veulent rester à jour par rapport à GTK+ etc.
Si ce boulot est fait petit à petit, au fur et à mesure des versions, ça ne demande pas trop trop de temps. Mais si on rajoute les incompatibilités entre les différentes versions de Vala, ça rajoute du boulot supplémentaire, dont on se passerait bien.
[^] # Re: Pourquoi Vala?
Posté par swilmet . En réponse à la dépêche Sortie de Val(a)IDE 0.7.2. Évalué à -2. Dernière modification le 02 janvier 2013 à 13:46.
Tu as déjà vu une variable portant le nom gtk_text_view_new_with_buffer ?
Ça n'existe pas en C.
Là où grep fonctionne très bien pour du code C, pour d'autres langages comme Java il faut utiliser les fonctionnalités d'un IDE comme Eclipse (outil refactoring pour renommer une méthode ou une classe, par exemple).
Mais la verbosité du C est aussi utile pour la compréhension du code. Quand on a une hiérarchie importante de classes, le fait d'avoir le nom complet des fonctions permet de savoir de quelle classe elle vient, et donc on retrouve plus rapidement la documentation.
[^] # Re: Pourquoi Vala?
Posté par swilmet . En réponse à la dépêche Sortie de Val(a)IDE 0.7.2. Évalué à 2.
Oui. Le C est un langage un peu plus verbeux, mais ça a des avantages.
[^] # Re: Pourquoi Vala?
Posté par swilmet . En réponse à la dépêche Sortie de Val(a)IDE 0.7.2. Évalué à 4.
Après quelques années d'utilisation de Vala, je conseillerais plutôt le C maintenant. Il y a des avantages à Vala, mais aussi des (gros) inconvénients.
Si on veut faire du GLib/GObject en C, c'est vrai qu'il y a pas mal de code de « remplissage ». En Vala, les spécificités de GObject (interfaces, classes, propriétés, signaux, etc) sont directement intégrés dans la syntaxe du langage.
Ce qui est pas mal aussi, c'est les closures, ou fonctions anonymes où on peut appeler des variables qui sont déclarées en-dehors du corps de la closure. C'est pratique pour attacher un callback à un signal : le code de la fonction est au même endroit. C'est à réserver que pour les petites fonctions, bien évidemment.
Autre point fort de Vala : la gestion automatique de la mémoire (qui se fait avec un compteur, quand il tombe à 0 la mémoire est libérée). Mais ça peut être vu aussi comme un point faible pour Vala, car le compilateur valac fait parfois des trucs vraiment pas optimisé, notamment quand des chaines de caractères sont manipulées.
Il y a d'autres (gros) désavantages à Vala. Déjà, valac est assez buggé (bon, avec le temps ça s'améliore, mais c'est pas encore ça). Donc quand on trouve un bug dans Vala, on perd énormément de temps rien que pour se rendre compte que ça vient de Vala, il faut analyser le code C généré (qui est assez immonde), rapporter/corriger le bug, trouver un contournement en attendant, etc.
Quand vous faites du C, vous regardez souvent le code assembleur que GCC génère, pcq GCC est buggé ? Non, évidemment pas.
Faire du Vala, c'est rajouter une couche de maintenance en plus. L'API en C peut changer, des trucs deviennent obsolètes (surtout pour GTK+ ces derniers temps). Mais la « couche » Vala peut changer aussi. Ça demande du travail de maintenance en plus, qu'on n'a pas quand on fait du C.
Bref, pour développer une application Gnome, je conseillerais plutôt le C. Quand on voit une classe GObject en C, on se demande d'abord qu'est-ce que c'est ce bazar, mais finalement on s'habitue, c'est pas si dérangeant que ça.
Ce qui est bien avec le C, aussi, c'est que le code est facilement « greppable » : on utilise le nom complet des fonctions. En Vala, on utilise objet.méthode(). Quand « méthode » est un nom très court qui revient pour beaucoup d'objets (get, set, …), c'est difficile de trouver tous les endroits dans le code où la méthode est appelée. Dans ce cas c'est plus facile de grepper dans le code C généré, puis d'essayer de retrouver l'endroit exact dans le code Vala, ce qui n'est pas très pratique.
[^] # Re: Prochain mainteneur pour sed ?
Posté par swilmet . En réponse au journal Grabuge à la FSF : GnuTLS quitte le projet GNU et sed perd son mainteneur. Évalué à 2.
En voyant ce récent commit, justement on dirait que ce n'est plus une priorité.
[^] # Re: Prochain mainteneur pour sed ?
Posté par swilmet . En réponse au journal Grabuge à la FSF : GnuTLS quitte le projet GNU et sed perd son mainteneur. Évalué à 3.
Il y aura toujours un peu de maintenance à faire, pour que ça fonctionne toujours bien avec les dernières versions des dépendances, et pour porter si besoin le code sur d'autres plateformes. Bien que pour sed il ne doit pas y avoir beaucoup de dépendances, et elles sont à mon avis très stable (pas de cassage de l'API à tout bout de champ).
Et si un jour un chercheur publie un article avec un tout nouveau algorithme ayant une complexité calculatoire moindre, c'est toujours intéressant de l'implémenter, pour ne pas rester à la traine par rapport aux autres implémentations.
# Prochain mainteneur pour sed ?
Posté par swilmet . En réponse au journal Grabuge à la FSF : GnuTLS quitte le projet GNU et sed perd son mainteneur. Évalué à 2.
Paolo Bonzini était le seul mainteneur de sed ? Il y a quelqu'un pour le remplacer ? Je ne vois aucune information à ce sujet.
Beaucoup d'outils comme sed conviennent maintenant à la plupart des besoins des utilisateurs. Il y a de moins en moins de raisons de vouloir contribuer. Ce n'était à mon avis pas le cas dans les années 90. Je peux me tromper, mais je pense qu'en faisant des statistiques, on pourrait voir que ces dernières années il y a moins de contributions que dans les années 90. Pourtant, pour la pérennité à long terme de ces logiciels, il faut de nouveaux développeurs, qui doivent être suffisamment calé dans le domaine.
Y aura-t-il toujours des développeurs suffisamment compétents pour maintenir les trucs comme sed ?
Le risque est qu'un jour, plus personne ne comprenne pourquoi certaines parties du code ont été écrite d'une telle manière, puisque plus personne n'y a touché depuis des années, et que la personne ayant écrit le code n'a pas laissé suffisamment de documentation ou de commentaires, et que la personne n'est plus disponible.
Je pense qu'à long terme, c'est un risque qu'il ne faut pas négliger, et donc, raison de plus pour bien documenter son code ;)
[^] # Re: Assistant, même très basique, interdit?
Posté par swilmet . En réponse à la dépêche LaTeXila 2.6, éditeur LaTeX pour GNOME. Évalué à 2.
Voilà c'est fait :
Dans la branche master, il y a maintenant 1000 commits !
$ git log --oneline | wc -l
1000
[^] # Re: Assistant, même très basique, interdit?
Posté par swilmet . En réponse à la dépêche LaTeXila 2.6, éditeur LaTeX pour GNOME. Évalué à 1.
Pour le chemin du fichier à insérer, ce serait pratique, en effet. Il y a moyen aussi de compléter le chemin du fichier directement avec la complétion.
Donc, en gros, quand on fait ctrl+espace là où on doit donner un chemin de fichier, on affiche les répertoires et fichiers relatifs, plus éventuellement une entrée en plus « Sélectionner un fichier… » pour ouvrir une fenêtre de dialogue.
On pourrait imaginer une action pour directement ouvrir la boite de dialogue, et qui insérerait le chemin relatif du fichier sélectionné.
Pour les \include ou \input, c'est pareil.
[^] # Re: Assistant, même très basique, interdit?
Posté par swilmet . En réponse à la dépêche LaTeXila 2.6, éditeur LaTeX pour GNOME. Évalué à 1.
La complétion des balises n'est pas encore parfaite, il manque pas mal de choses, comme pour l'insertion d'une figure (l'environnement figure, includegraphics, etc.). Comme j'en avais parlé avec Simon, je préfère améliorer la complétion que de rajouter un wizard.
Pour la création d'un tableau, la complétion peut être améliorée aussi, mais ça devient plus délicat pour l'intérieur du tableau : comment séparer les lignes et colonnes.
À partir du menu LaTeX, on peut insérer une table ou un tableau, mais ce qui est inséré n'est pas très complet. Ce serait bien d'insérer à ce moment-là un exemple avec 2 lignes et 2 colonnes (vides). Et aussi rajouter un bouton dans la 2e barre d'outils, juste à côté de l'insertion d'une figure.
[^] # Re: Ouverture du navigateur de fichier graphique
Posté par swilmet . En réponse à la dépêche LaTeXila 2.6, éditeur LaTeX pour GNOME. Évalué à 2.
C'est surement un bug dans les fichiers de config, voir sur le bugzilla:
# PyGTK -> PyGI
Posté par swilmet . En réponse à la dépêche Présentation de GBirthday et appel à contribution. Évalué à 5.
PyGTK est obsolète. Avec GObject Introspection et PyGI, les bindings pour Python des bibliothèques basées sur GObject (comme GTK+) se font de manière automatique.
C'est intéressant de faire la migration, parce que je pense que PyGTK n'est plus maintenu.
En tout cas je trouve que ce genre de programmes est intéressant. De plus en plus de personnes utilisent des services web comme Facebook ou autre pour ce genre de choses, alors que des applications font très bien l'affaire.
# Summer of Code _in_ Space
Posté par swilmet . En réponse à la dépêche SOCIS2012 : les étudiants peuvent candidater !. Évalué à 2.
Ça peut être sympa de passer l'été à programmer dans une navette spatiale, à contempler la terre.
Bon pour la connexion internet, la latence doit être assez élevée, c'est pas terrible pour discuter sur IRC :/
# Retour d'expérience
Posté par swilmet . En réponse à la dépêche Un prompt bash utile, sans poudre aux yeux. Évalué à 6.
Tout d'abord, je ne te remercies vraiment pas pour ce script, je viens de perdre mon après-midi à le personnaliser, fignoler, … ;)
Plus sérieusement, pour savoir si on est root ou pas, c'est plus simple d'utiliser :
Pour git, si la branche origin/branch n'existe pas, il y a une erreur :
Je me souviens aussi qu'il y a un meilleur moyen pour obtenir les infos de git, au lieu d'utiliser des commandes comme
git branch,git diff, etc. Mais je sais plus quel est ce meilleur moyen, je te laisse chercher ;)Sinon sur le web y a déjà plein d'autres prompt bash pour git, avec certaines choses utiles, mais malheureusement plein d'autres trucs inutiles (mettre dans une couleur différente selon l'heure du dernier commit, …). Juste le nom de la branche avec quelques couleurs, c'est très bien !
# Mettre en avant le choix sous Linux
Posté par swilmet . En réponse au journal De la convergence des interfaces, le revers de la médaille. Évalué à 4.
Quand j'explique qu'un des avantages, sous Linux, c'est le choix, notamment pour le gestionnaire de bureaux, les gens ne comprennent pas en quoi c'est bien.
Mais quand ils commenceront à se plaindre des nouvelles interfaces, là ils comprendront peut-être enfin…
Si la tendance des interfaces unifiées (Unity, GNOME 3, …) ne plait pas, il y a toujours des alternatives : Xfce, tiling (awesome, …), etc etc.
[^] # Re: HFS
Posté par swilmet . En réponse à la dépêche Sortie de Fedora 17 nommée Beefy Miracle. Évalué à 1.
C'est que tu n'as pas compris la philosophie de Fedora alors, qui est d'être leading-edge, et donc par conséquent aussi bleeding edge : en intégrant les toutes dernières technologies en grandeur nature, y a forcément des bugs qui apparaissent.
[^] # Re: Couteaux suisses
Posté par swilmet . En réponse à la dépêche dfc 3.0.0 : nouvelle version majeure pour cette alternative haute en couleurs à l'utilitaire df(1). Évalué à 1.
Justement, je trouve ça bête d'utiliser des pipes (donc plusieurs processus) dans l'unique but d'afficher la progression. D'ailleurs ça ne m'étonnerait pas que le script que j'avais testé se basait sur pv… cp et mv n'ont besoin que d'un seul processus, à ma connaissance.
Je ne sais plus pourquoi je n'utilise plus le script, sans doute pcq il était trop limité (peu ou pas d'options, …).
L'affichage de la progression devrait être implémenté directement dans l'outil qui effectue la copie ou le déplacement des fichiers. Cela n'exclus évidemment pas le fait que l'outil utilise une bibliothèque pour l'affichage de la progression (mais je ne sais pas si une telle bibliothèque existe).
[^] # Re: Couteaux suisses
Posté par swilmet . En réponse à la dépêche dfc 3.0.0 : nouvelle version majeure pour cette alternative haute en couleurs à l'utilitaire df(1). Évalué à 1.
Ça tombe bien, ça faisait un petit temps que je comptais essayer mc (tout comme zsh qui est sur ma todo list depuis des lustres… /me sifflote).
[^] # Re: Tilde
Posté par swilmet . En réponse à la dépêche RPM 4.10 est sorti. Évalué à 1.
« btw, is the concept of numbers smaller than zero but not negative known/used anywhere outside of debian/dpkg? » (Holger Levsen)
Si je comprends bien, c'est possible grâce au tilde : la version 0~rc1 par exemple.
[^] # Re: Couteaux suisses
Posté par swilmet . En réponse à la dépêche dfc 3.0.0 : nouvelle version majeure pour cette alternative haute en couleurs à l'utilitaire df(1). Évalué à 1.
Pareil top -> htop.
Ce qu'il me manque, c'est un cp et mv --progress. J'avais testé une fois un script de ce genre, mais c'était plus un hack qu'autre chose, en utilisant tar (sans compression) dans une série de pipes.
# Pendant ce temps-là chez GTK+
Posté par swilmet . En réponse à la dépêche Sortie des EFL 1.2.0 et autres illuminations. Évalué à 9.
Ces derniers temps il y a beaucoup de refactoring dans GTK+, tant interne (donc qui n'affecte pas l'API) qu'externe (qui propose une nouvelle API et rendant obsolète l'ancienne).
Pour le refactoring interne, c'est surtout pour utiliser Clutter, permettant ainsi de profiter de l'accélération matérielle. Les développeurs se demandaient il y a quelques années si ce n'était pas mieux de recommencer un tout nouveau toolkit graphique basé sur Clutter, au lieu d'adapter GTK+. En fait les deux se produisent, puisqu'il y a la nouvelle bibliothèque Mx.
Il y a aussi pas mal de changements dans l'API, ce qui demande pas mal de boulot pour les développeurs d'applications.
Et à côté de ça, elementary a un support pour l'accélération graphique depuis le début, et l'API semble vraiment stable. Par contre point de vue fonctionnalités, je pense que GTK+ est plus complet.
Les autres bibliothèques des EFL (eio etc) semblent avoir le même but que la GLib, GIO, etc. De ce côté-là, je pense que GNOME a un gros avantage : GObject-introspection, qui permet d'utiliser n'importe quelle bibliothèque basée sur GObject dans un autre langage que le C, sans devoir créer et maintenir des bindings. Pour l'instant Python et Javascript sont supportés (et dans une certaine mesure Vala, mais GObject-introspection n'est pas encore tout à fait au point pour Vala).
Bref, la base de GNOME (GObject, GLib, GIO etc) est très bien, mais GTK+ se fait un peu vieux… Et pour les développeurs d'applications, c'est plus intéressant de se baser sur une API qui ne risque pas de changer d'ici un an ou deux.
[^] # Re: systemd vs upstart
Posté par swilmet . En réponse à la dépêche Ubuntu 12.04 Precise Pangolin est sortie. Évalué à 4.
Et la réponse de Lennart.
« Anyway, summary is: I wish them good luck, they are now going their own way, stuck in a legacy stack with little new engineering, becoming an island of their own. »
[^] # Re: donc en gros
Posté par swilmet . En réponse au journal Pourquoi le monde libre me gave de plus en plus.. Évalué à 4.
Un problème aussi c'est que le basesystem sous les distribs Linux est divisé en plein de petits (et moins petits) paquets. Pareil évidemment pour les paquets des autres logiciels. Au final, pratiquement chaque système a un ensemble de paquets installés différent, ce qui donne une explosion de la complexité à faire de bons tests pour trouver et corriger les bugs etc. Pour le basesystem, c'est assez critique. Les développeurs BSD l'ont bien compris et développent le basesystem comme un tout.
Un article intéressant, qui montre que certains devs Linux sont conscients des problèmes de stabilité et essayent de trouver des solutions (en gros faire un basesystem de type BSD, tout mettre dans git et faire tourner des tests automatiques assez poussés) :
On the future of Linux distributions
(L'auteur, Lars Wirzenius, a fait une conf là-dessus au FOSDEM cette année).