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) :
Je connais quelqu'un (suite à des problèmes de dos) qui a aussi un tabouret de ce style, mais avec des roulettes, ce qui doit être plus pratique. Il appelle ça son « tabouret de dentiste ».
Aussi, son siège (en cuir) a une drôle de forme qui est bien adaptée. Je l'ai essayé, et c'est vraiment confortable (en tout cas 5 min).
(Moi qui ait eu un problème de dos récemment, ce journal m'a fait découvrir pas mal de choses, mais le plus important pour moi est la posture à mon bureau, et donc changer de chaise est ma priorité pour l'instant. Sinon je compte passer au typematrix (j'écris déjà en bépo), la souris de ploum a l'air intéressante, je vais ressortir le repose-poignet en gel aussi, et pourquoi pas essayer un tiling wm comme awesome).
Bon exemple. Une autre analogie, en programmation orientée objet : la différence entre une interface et une classe (l'implémentation).
Le texte complet de la licence, c'est la classe. Ce qu'on peut lire par exemple sur wikipédia ou autre à propos d'une licence, c'est l'interface. Et de mon point de vue, comprendre l'interface d'une licence suffit, c'est-à-dire comprendre les principes généraux, et les points importants à savoir en tant que développeur.
Il faut voir ça aussi du point de vue des juristes : on a envie que notre licence fasse « ça » et « ça ». À nous maintenant d'implémenter ça comme il faut dans un texte juridique. Comprendre les intentions de départ des juristes (l'interface) suffit donc pour comprendre la licence.
La GPL est plus complexe, ça c'est certain. Mais est-ce vraiment grave du point de vue des développeurs ? Les licences, ça fait partie du domaine des juristes, c'est normal si un programmeur ne comprend pas tout ou trouve ça barbant à lire. Chacun son métier, après tout.
Personnellement, je n'ai lu ni la GPLv2 ni la v3, par contre je connais les principes généraux (copyleft, tivoïsation pour la v3, etc) auxquels j'adhère. Ensuite je fais confiance à la FSF pour que la licence soit juridiquement correcte. De toute façon je n'ai pas les connaissances nécessaires pour vérifier qu'elle est correcte, alors à quoi bon lire un truc que je comprendrai même pas ?
Quand vous installez un nouveau logiciel libre, vous lisez tout le code source pour vérifier que ça fait bien ce que vous voulez que le logiciel fasse ? Non, vous lisez la liste des fonctionnalités disponibles, et faites confiance aux développeurs pour avoir implémenté ça correctement.
Je m'étais fait la réflexion il n'y a pas longtemps : ça manque, une distrib en rolling-release, binaire, stable, facile à installer, avec un bon gestionnaire de paquets.
Et bien je pense que Calculate Linux est exactement ce que je cherchais, merci !
L'utilisation, dans mon cas, sera pour l'ordi familial (sur Fedora actuellement). Pour ma machine perso, Gentoo me convient bien (mais qui sait, peut-être que je passerai aussi sur Calculate).
Debian testing, le désavantage c'est que c'est pas tout le temps stable (d'où le nom), ni tout le temps en rolling-release (périodes de freeze). De plus, mais ça c'est un avis purement personnel, je n'aime pas trop APT (je préfère yum pour sa simplicité, ou portage pour sa flexibilité).
Bon ça peut paraitre bizarre, mais pour mes tâches personnelles, en notant pratiquement tout sur papier je m'en sors très bien. Pas besoin d'avoir mon ordi avec moi tout le temps, et en plus qu'il soit allumé.
J'ai essayé pendant un temps GTG (Getting Things GNOME!) ou gtodo, mais j'ai pas accroché.
Merci, j'ai regardé un peu ce que c'était. Y a effectivement un calendrier de Seinfeld, mais à la base Kotivox est fait tout d'abord pour tenir un journal intime. Ce qui est assez chiant pcq il faut à chaque fois rentrer un login/mdp pour ouvrir le logiciel.
Petite note au passage (comme c'est assez inhabituel), Kotivox est écrit en langage D (d'où sa présence sur dsource.org).
Mais y a pas d'autotools ou autotools-like pour compiler facilement le bazar, juste le code source disponible comme ça, avec un binaire à côté (ce qui pour les férus de sécurité, c'est pas très rassurant étant donné que c'est pour gérer un journal intime… :). Donc voilà, c'est pas vraiment l'idéal, ce qui expliquerait sans doute pourquoi même Debian n'a pas de paquet pour Kotivox.
Autre petite note au passage (comme c'est assez inhabituel), Kotivox, étonnamment, c'est du GTK+, oui oui.
Aussi, mais ça c'est pas trop grave, l'interface est vraiment bizarre à utiliser. Il y a très peu de boutons, pas de barre de menu, il faut faire un clic droit pour certaines actions, et l'application est prévue de base pour les mal-voyants. Disons que j'ai déjà vu mieux.
Bref, pas totalement convaincu.
Le code de Daily Stamp par contre est disponible, mais installer et configurer un serveur web sur ma machine perso juste pour ça, c'est un peu dommage.
Au final je sens que je vais prendre un calendrier format papier… (ça donne sans doute d'ailleurs une meilleure vue d'ensemble des chaines formées jours après jours, si le calendrier couvre une année complète).
Chouette, j'ai réussi, je vais aller sur dailystamp.com noter ça. Tient je vais vite faire un petit tour sur DLFP par la même occasion, c'est pas à 5 min prêt… Ou comment être piégé.
Bon plus sérieusement, Daily Stamp c'est pas mal comme concept, mais quand j'ai vu que c'était en fait un site web, je trouve ça moins cool. Eh oui, tout le monde n'a pas une connexion internet 24h/24 tous les jours, et partager ses « stamps » avec ses amis, ça sent la grosse mode réseaux sociaux ça, faut pas exagérer non plus (« cool mon pote a réussi à se lever d'un seul coup avant 10h du matin aujourd'hui, génial ! »).
Donc, y a pas une petite appli qui fait la même chose ? (et si c'est en GTK+, je serais comblé :).
GNOME Shell, c'est prévu à la base pour que ce soit complètement différent de GNOME 2 (gnome-panel). En essayant de développer une extension de gnome shell pour que ça ressemble le plus possible à gnome-panel, c'est normal que ça coince à un moment donné…
Comme pour MATE, je me demande pourquoi les devs ne continuent simplement pas à maintenir gnome-panel.
Donc bon, si, ça reste bizarre de se faire héberger par un logiciel proprio, à moins de dire que le libre est un moyen, pas un but, et que les fonctionnalités sont prioritaire sur la liberté (et alors la, c'est très logique d'utiliser Github)
Un des très gros avantages de GitHub et Gitorious, c'est le nombre d'utilisateurs. Héberger son projet sur ce genre de site permet d'avoir plus de contributeurs potentiels (la facilité de faire un fork/clone, meilleure visibilité…). Sur ce point, GitHub a -- il me semble -- une plus grande communauté.
Donc pour moi, le principal avantage de GitHub/Gitorious, c'est la communauté qu'il y a autour. Sinon cgit fait très bien l'affaire. Et pour un projet ayant plus d'importance, je trouve que GitHub n'est pas adapté (pour gérer les traductions par exemple, ou le bugtracker, qui est très limité comparé à un bugzilla).
Donc, pour un petit projet, GitHub/Gitorious permet un hébergement très facile (pas besoin de serveur perso, etc.), tout en profitant du « réseau social » du site. Quand le projet a une plus grande ampleur, il faut se tourner vers une plateforme plus complète, avec un vrai bugzilla etc.
Quel est donc l'intérêt de faire tourner son propre Gitorious sur un serveur perso ? On ne profite pas de la communauté de Gitorious, et on n'a pas une plateforme ayant suffisamment de fonctionnalités pour gérer un gros projet.
Le seul intérêt que je vois, c'est si un jour le site web Gitorious ferme ses portes, comme le code source est là, le développement web n'est pas perdu. Par contre, pour faire revivre le site, il faut déjà des serveurs assez puissants, une très bonne bande passante, etc. Et aussi, mettre en place tous ces serveurs demande certainement beaucoup de boulot et de connaissances. Est-ce que Gitorious explique vraiment comment leur infrastructure est organisée, les scripts qu'ils ont écris pour la maintenance, et tout ce genre de choses ?
Pour pas mal de développeurs, le fait que le genre de service comme GitHub ou Gitorious soit libre ou pas ne change pas grand chose. C'est vu plutôt comme un service, pas comme une application. Et ce qui compte pour un service, c'est la portabilité des données, et le fait de pouvoir changer facilement de service si besoin. Git est de nature décentralisé, donc ça ne pose aucun soucis. Pour d'autres trucs comme le bugtracker, j'ai entendu qu'il y avait moyen très facilement de récupérer toutes les données.
En fait je rejoins assez bien l'avis de Karl Fogel (4e question de l'entretien).
# Summer of Code _in_ Space
Posté par Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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).
[^] # Re: chaise/tabouret
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Ergonomie et aménagement du poste de travail : retours et appels à expériences. Évalué à 1.
Je connais quelqu'un (suite à des problèmes de dos) qui a aussi un tabouret de ce style, mais avec des roulettes, ce qui doit être plus pratique. Il appelle ça son « tabouret de dentiste ».
Aussi, son siège (en cuir) a une drôle de forme qui est bien adaptée. Je l'ai essayé, et c'est vraiment confortable (en tout cas 5 min).
(Moi qui ait eu un problème de dos récemment, ce journal m'a fait découvrir pas mal de choses, mais le plus important pour moi est la posture à mon bureau, et donc changer de chaise est ma priorité pour l'instant. Sinon je compte passer au typematrix (j'écris déjà en bépo), la souris de ploum a l'air intéressante, je vais ressortir le repose-poignet en gel aussi, et pourquoi pas essayer un tiling wm comme awesome).
[^] # Re: Complexité
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche La famille des *GPL relativement moins présente parmi les licences libres. Évalué à 2.
Bon exemple. Une autre analogie, en programmation orientée objet : la différence entre une interface et une classe (l'implémentation).
Le texte complet de la licence, c'est la classe. Ce qu'on peut lire par exemple sur wikipédia ou autre à propos d'une licence, c'est l'interface. Et de mon point de vue, comprendre l'interface d'une licence suffit, c'est-à-dire comprendre les principes généraux, et les points importants à savoir en tant que développeur.
Il faut voir ça aussi du point de vue des juristes : on a envie que notre licence fasse « ça » et « ça ». À nous maintenant d'implémenter ça comme il faut dans un texte juridique. Comprendre les intentions de départ des juristes (l'interface) suffit donc pour comprendre la licence.
[^] # Re: Complexité
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche La famille des *GPL relativement moins présente parmi les licences libres. Évalué à 5. Dernière modification le 07 janvier 2012 à 13:05.
La GPL est plus complexe, ça c'est certain. Mais est-ce vraiment grave du point de vue des développeurs ? Les licences, ça fait partie du domaine des juristes, c'est normal si un programmeur ne comprend pas tout ou trouve ça barbant à lire. Chacun son métier, après tout.
Personnellement, je n'ai lu ni la GPLv2 ni la v3, par contre je connais les principes généraux (copyleft, tivoïsation pour la v3, etc) auxquels j'adhère. Ensuite je fais confiance à la FSF pour que la licence soit juridiquement correcte. De toute façon je n'ai pas les connaissances nécessaires pour vérifier qu'elle est correcte, alors à quoi bon lire un truc que je comprendrai même pas ?
Quand vous installez un nouveau logiciel libre, vous lisez tout le code source pour vérifier que ça fait bien ce que vous voulez que le logiciel fasse ? Non, vous lisez la liste des fonctionnalités disponibles, et faites confiance aux développeurs pour avoir implémenté ça correctement.
[^] # Re: Put a CoW in your Boxen Edition
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Gentoo Linux livre LiveDVD 12.0. Évalué à 1.
Il y a aussi, dans l'annonce officielle :
# vi, vim
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Les vrais développeurs utilisent ed !. Évalué à 3.
Quand on connait vi/vim, on est en quelque sorte déjà un peu familier avec ed.
Si je dis pas de bêtise, toutes (?) les commandes qui commencent par « : » dans vi, c'est en fait des commandes ed.
# Ça a l'air très intéressant !
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Calculate Linux 11.12 est disponible (dans votre chaussette). Évalué à 3.
Je m'étais fait la réflexion il n'y a pas longtemps : ça manque, une distrib en rolling-release, binaire, stable, facile à installer, avec un bon gestionnaire de paquets.
Et bien je pense que Calculate Linux est exactement ce que je cherchais, merci !
L'utilisation, dans mon cas, sera pour l'ordi familial (sur Fedora actuellement). Pour ma machine perso, Gentoo me convient bien (mais qui sait, peut-être que je passerai aussi sur Calculate).
Debian testing, le désavantage c'est que c'est pas tout le temps stable (d'où le nom), ni tout le temps en rolling-release (périodes de freeze). De plus, mais ça c'est un avis purement personnel, je n'aime pas trop APT (je préfère yum pour sa simplicité, ou portage pour sa flexibilité).
# Les TODO personnels : sur papier.
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Lifehacking et logiciel libre, premier recensement. Évalué à 3.
Bon ça peut paraitre bizarre, mais pour mes tâches personnelles, en notant pratiquement tout sur papier je m'en sors très bien. Pas besoin d'avoir mon ordi avec moi tout le temps, et en plus qu'il soit allumé.
J'ai essayé pendant un temps GTG (Getting Things GNOME!) ou gtodo, mais j'ai pas accroché.
[^] # Re: Daily Stamp
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Lifehacking et logiciel libre, premier recensement. Évalué à 1.
Ça a l'air quand même beaucoup plus sophistiqué que dailystamp.
Ce qui est bien justement avec un calendrier de Seinfeld, c'est sa simplicité.
[^] # Re: Daily Stamp
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Lifehacking et logiciel libre, premier recensement. Évalué à 3.
Merci, j'ai regardé un peu ce que c'était. Y a effectivement un calendrier de Seinfeld, mais à la base Kotivox est fait tout d'abord pour tenir un journal intime. Ce qui est assez chiant pcq il faut à chaque fois rentrer un login/mdp pour ouvrir le logiciel.
Petite note au passage (comme c'est assez inhabituel), Kotivox est écrit en langage D (d'où sa présence sur dsource.org).
Mais y a pas d'autotools ou autotools-like pour compiler facilement le bazar, juste le code source disponible comme ça, avec un binaire à côté (ce qui pour les férus de sécurité, c'est pas très rassurant étant donné que c'est pour gérer un journal intime… :). Donc voilà, c'est pas vraiment l'idéal, ce qui expliquerait sans doute pourquoi même Debian n'a pas de paquet pour Kotivox.
Autre petite note au passage (comme c'est assez inhabituel), Kotivox, étonnamment, c'est du GTK+, oui oui.
Aussi, mais ça c'est pas trop grave, l'interface est vraiment bizarre à utiliser. Il y a très peu de boutons, pas de barre de menu, il faut faire un clic droit pour certaines actions, et l'application est prévue de base pour les mal-voyants. Disons que j'ai déjà vu mieux.
Bref, pas totalement convaincu.
Le code de Daily Stamp par contre est disponible, mais installer et configurer un serveur web sur ma machine perso juste pour ça, c'est un peu dommage.
Au final je sens que je vais prendre un calendrier format papier… (ça donne sans doute d'ailleurs une meilleure vue d'ensemble des chaines formées jours après jours, si le calendrier couvre une année complète).
# Daily Stamp
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Lifehacking et logiciel libre, premier recensement. Évalué à 5.
« Ne pas surfer sur le web aujourd'hui »
Chouette, j'ai réussi, je vais aller sur dailystamp.com noter ça. Tient je vais vite faire un petit tour sur DLFP par la même occasion, c'est pas à 5 min prêt… Ou comment être piégé.
Bon plus sérieusement, Daily Stamp c'est pas mal comme concept, mais quand j'ai vu que c'était en fait un site web, je trouve ça moins cool. Eh oui, tout le monde n'a pas une connexion internet 24h/24 tous les jours, et partager ses « stamps » avec ses amis, ça sent la grosse mode réseaux sociaux ça, faut pas exagérer non plus (« cool mon pote a réussi à se lever d'un seul coup avant 10h du matin aujourd'hui, génial ! »).
Donc, y a pas une petite appli qui fait la même chose ? (et si c'est en GTK+, je serais comblé :).
# Maintenir gnome-panel
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Cinnamon : fork de Gnome-Shell façon Gnome 2. Évalué à 0. Dernière modification le 26 décembre 2011 à 13:07.
GNOME Shell, c'est prévu à la base pour que ce soit complètement différent de GNOME 2 (gnome-panel). En essayant de développer une extension de gnome shell pour que ça ressemble le plus possible à gnome-panel, c'est normal que ça coince à un moment donné…
Comme pour MATE, je me demande pourquoi les devs ne continuent simplement pas à maintenir gnome-panel.
[^] # Re: githubçapue, c'est pas libre
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Évolutions du site. Évalué à 1.
Non, c'est séparé du dépôt git.
[^] # Re: github ça pue, c'est pas libre
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Évolutions du site. Évalué à 2.
Un des très gros avantages de GitHub et Gitorious, c'est le nombre d'utilisateurs. Héberger son projet sur ce genre de site permet d'avoir plus de contributeurs potentiels (la facilité de faire un fork/clone, meilleure visibilité…). Sur ce point, GitHub a -- il me semble -- une plus grande communauté.
Donc pour moi, le principal avantage de GitHub/Gitorious, c'est la communauté qu'il y a autour. Sinon cgit fait très bien l'affaire. Et pour un projet ayant plus d'importance, je trouve que GitHub n'est pas adapté (pour gérer les traductions par exemple, ou le bugtracker, qui est très limité comparé à un bugzilla).
Donc, pour un petit projet, GitHub/Gitorious permet un hébergement très facile (pas besoin de serveur perso, etc.), tout en profitant du « réseau social » du site. Quand le projet a une plus grande ampleur, il faut se tourner vers une plateforme plus complète, avec un vrai bugzilla etc.
Quel est donc l'intérêt de faire tourner son propre Gitorious sur un serveur perso ? On ne profite pas de la communauté de Gitorious, et on n'a pas une plateforme ayant suffisamment de fonctionnalités pour gérer un gros projet.
Le seul intérêt que je vois, c'est si un jour le site web Gitorious ferme ses portes, comme le code source est là, le développement web n'est pas perdu. Par contre, pour faire revivre le site, il faut déjà des serveurs assez puissants, une très bonne bande passante, etc. Et aussi, mettre en place tous ces serveurs demande certainement beaucoup de boulot et de connaissances. Est-ce que Gitorious explique vraiment comment leur infrastructure est organisée, les scripts qu'ils ont écris pour la maintenance, et tout ce genre de choses ?
[^] # Re: github ça pue, c'est pas libre
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Évolutions du site. Évalué à 9.
Pour pas mal de développeurs, le fait que le genre de service comme GitHub ou Gitorious soit libre ou pas ne change pas grand chose. C'est vu plutôt comme un service, pas comme une application. Et ce qui compte pour un service, c'est la portabilité des données, et le fait de pouvoir changer facilement de service si besoin. Git est de nature décentralisé, donc ça ne pose aucun soucis. Pour d'autres trucs comme le bugtracker, j'ai entendu qu'il y avait moyen très facilement de récupérer toutes les données.
En fait je rejoins assez bien l'avis de Karl Fogel (4e question de l'entretien).