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).
Je suis pas sûr à 100% que ce soit la faute de systemd (au début je pensais à un bug du noyau), mais parfois l'ordinateur redémarre au lieu de s'éteindre avec Fedora 15, alors que Fedora 14 n'avait pas ce bug. J'ai eu ce problème sur deux machines différentes (les deux seules où j'ai installé F15…).
Il faudrait que j'essaye Fedora 16 pour voir s'il y a toujours ce bug.
Un des problèmes d'Asterisk est que les versions que la plupart utilisent ne sont plus supportées. Pour Firefox, ce problème a une moins grande ampleur à vue de nez, puisque la plupart des utilisateurs de Firefox sont sur Windows et qu'il y a normalement des mises à jour qui sont proposées régulièrement.
Mais Asterisk a d'autres problèmes. Comme la dernière phrase du paragraphe le dit, Digium commercialise une version fort différente d'Asterisk, et ils ne testent pas suffisamment Asterisk lui-même et donc il y a des problèmes de stabilité. Mozilla ne commercialise pas une version différente de Firefox, et je n'ai aucun problème avec la dernière version (la 7).
Donc non, Firefox n'est évidemment pas du fauxpen source…
Non, je ne fais pas partie de la communauté d'Asterisk, donc je suis loin d'être une référence.
Ce qui me fait dire que c'est du fauxpen source, c'est en lisant le paragraphe suivant (voir le lien donné par nud) :
The root of the problem in the Asterisk world is that we now find ourselves with one and only one supported version of Asterisk: Asterisk 1.8. And it happens to be a version that few people actually use to run their businesses. The reason for this dilemma is that, other than security fixes, Digium now has dropped support for both Asterisk 1.4 and 1.6, the two products that most folks regard as the “stable releases” and deploy in production systems. So we’re left with a supported version of Asterisk that no one actually is using or selling for a production environment. Indeed, Digium, The Asterisk Company markets a commercial product based upon a completely different version of Asterisk!
C'est un bon exemple du fauxpen source, il me semble. Si Asterisk était développé de manière beaucoup plus communautaire, il y aurait certainement moins de problèmes de stabilité.
Si Digium a un trop grand contrôle sur le développement d'Asterisk, peut-être qu'un fork est encore la meilleure solution. LibreOffice par exemple se porte beaucoup mieux maintenant, à ce que je sache. Pour LibreOffice, pas mal de sociétés se sont regroupées pour créer une fondation. Peut-être est-ce envisageable pour Asterisk ?
Bon, peut-être qu'un fork ne vaut pas vraiment la peine, si par exemple le design général du code d'Asterisk est pourri, et qu'il est difficile d'améliorer ça sans une réécriture complète… Dans ce cas, le mieux (à long terme) est sans doute de se tourner vers FreeSWITCH ou autre. Le problème c'est qu'il manque certainement beaucoup de fonctionnalités par rapport à Asterisk, et que migrer tous les scripts de configuration vers un autre système qui est potentiellement complètement différent, ça demande beaucoup de boulot…
D'autres commits ont suivi, celui que tu pointes est le premier, donc forcément y a pas encore grand chose… Si on regarde le code actuel du fichier, c'est déjà plus compréhensible (le fait que ce code fasse marcher une wiimote, pas le fait de comprendre le code lui-même ;).
Linus continue donc de creuser la question et son patch, qui implémente plusieurs micro‐caches, permet de gagner entre 1 et 2 % de performances sur un noyau compilé avec « make -j ».
La phrase est bizarrement formulée je trouve. J'ai compris d'abord que les 1 à 2% de performances n'étaient atteints (en permanence) que si on compile le noyau avec « make -j », ce qui est complètement absurde.
En fait, ce qu'il faut comprendre (voir message du commit) c'est qu'un « make -j » effectué sur le noyau est maintenant de 1 à 2% plus rapide, car c'est une opération assez couteuse en recherche de chemin de fichiers (ce que le patch optimise).
Si on utilise un nombre non-signé pour représenter le nombre de secondes depuis le 1er janvier 1970, on tiendrait jusqu'en 2106, ce qui est déjà beaucoup mieux.
Le bug de l'an 2038, c'est pcq c'est un nombre signé qui est utilisé, et donc en théorie, avec ce système, on peut dire qu'un fichier date de 1902. Ou mieux, envoyer un mail datant de 1902, ce qui serait assez rigolo (mais je n'ai pas été lire la RFC pour voir si c'était possible, et si ça tombe le mail se base sur une autre unité).
D'ailleurs, pourquoi ils n'installent pas les outils GNU ?
Solaris, HP-UX, AIX, c'est du UNIX, mais c'est aussi du proprio…
Par exemple Solaris est livré avec le compilateur Sun Studio. Ça peut être intéressant de l'utiliser sur une machine SPARC pcq Sun Studio contient des options de compilations spécifiques à ce processeur qui n'existent pas dans GCC.
Pourquoi ils ne contribuent pas plutôt à GCC ou LLVM/Clang ? Ça je n'en sais rien. Peut-être que si Oracle n'avait pas racheté Sun, ce serait le cas, vu que Sun était plus « libre-friendly » (OpenSolaris, …).
Donc le fait qu'ils n'installent pas les outils GNU est sans doute dû au fait que ces OS sont quand même propriétaire, et qu'ils ont développé depuis de nombreuses années des logiciels maisons qui s'intègrent bien à leur OS.
[^] # Re: chaise/tabouret
Posté par swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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 swilmet . 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).
[^] # Re: systemd
Posté par swilmet . En réponse au journal Lennart casse les logs!. Évalué à 1.
Je suis pas sûr à 100% que ce soit la faute de systemd (au début je pensais à un bug du noyau), mais parfois l'ordinateur redémarre au lieu de s'éteindre avec Fedora 15, alors que Fedora 14 n'avait pas ce bug. J'ai eu ce problème sur deux machines différentes (les deux seules où j'ai installé F15…).
Il faudrait que j'essaye Fedora 16 pour voir s'il y a toujours ce bug.
[^] # Re: Qualité du logiciel
Posté par swilmet . En réponse à la dépêche Asterisk 10 est disponible. Évalué à 2.
Un des problèmes d'Asterisk est que les versions que la plupart utilisent ne sont plus supportées. Pour Firefox, ce problème a une moins grande ampleur à vue de nez, puisque la plupart des utilisateurs de Firefox sont sur Windows et qu'il y a normalement des mises à jour qui sont proposées régulièrement.
Mais Asterisk a d'autres problèmes. Comme la dernière phrase du paragraphe le dit, Digium commercialise une version fort différente d'Asterisk, et ils ne testent pas suffisamment Asterisk lui-même et donc il y a des problèmes de stabilité. Mozilla ne commercialise pas une version différente de Firefox, et je n'ai aucun problème avec la dernière version (la 7).
Donc non, Firefox n'est évidemment pas du fauxpen source…
[^] # Re: Qualité du logiciel
Posté par swilmet . En réponse à la dépêche Asterisk 10 est disponible. Évalué à 1.
Non, je ne fais pas partie de la communauté d'Asterisk, donc je suis loin d'être une référence.
Ce qui me fait dire que c'est du fauxpen source, c'est en lisant le paragraphe suivant (voir le lien donné par nud) :
[^] # Re: Qualité du logiciel
Posté par swilmet . En réponse à la dépêche Asterisk 10 est disponible. Évalué à 2.
C'est un bon exemple du fauxpen source, il me semble. Si Asterisk était développé de manière beaucoup plus communautaire, il y aurait certainement moins de problèmes de stabilité.
Si Digium a un trop grand contrôle sur le développement d'Asterisk, peut-être qu'un fork est encore la meilleure solution. LibreOffice par exemple se porte beaucoup mieux maintenant, à ce que je sache. Pour LibreOffice, pas mal de sociétés se sont regroupées pour créer une fondation. Peut-être est-ce envisageable pour Asterisk ?
Bon, peut-être qu'un fork ne vaut pas vraiment la peine, si par exemple le design général du code d'Asterisk est pourri, et qu'il est difficile d'améliorer ça sans une réécriture complète… Dans ce cas, le mieux (à long terme) est sans doute de se tourner vers FreeSWITCH ou autre. Le problème c'est qu'il manque certainement beaucoup de fonctionnalités par rapport à Asterisk, et que migrer tous les scripts de configuration vers un autre système qui est potentiellement complètement différent, ça demande beaucoup de boulot…
[^] # Re: Wiimote driver
Posté par swilmet . En réponse à la dépêche Sortie du noyau Linux 3.1. Évalué à 6.
D'autres commits ont suivi, celui que tu pointes est le premier, donc forcément y a pas encore grand chose… Si on regarde le code actuel du fichier, c'est déjà plus compréhensible (le fait que ce code fasse marcher une wiimote, pas le fait de comprendre le code lui-même ;).
# Compilation du noyau avec « make -j » plus rapide
Posté par swilmet . En réponse à la dépêche Sortie du noyau Linux 3.1. Évalué à 9.
La phrase est bizarrement formulée je trouve. J'ai compris d'abord que les 1 à 2% de performances n'étaient atteints (en permanence) que si on compile le noyau avec « make -j », ce qui est complètement absurde.
En fait, ce qu'il faut comprendre (voir message du commit) c'est qu'un « make -j » effectué sur le noyau est maintenant de 1 à 2% plus rapide, car c'est une opération assez couteuse en recherche de chemin de fichiers (ce que le patch optimise).
# 5 ans de support pour Ubuntu 12.04 desktop
Posté par swilmet . En réponse à la dépêche En bref : du 17 au 21 octobre. Évalué à 2.
Au lieu de 3 ans. Voir annonce.
[^] # Re: J'approuve
Posté par swilmet . En réponse au journal x32: Une nouvelle ABI Linux '32 bits' pour les CPU x86-64. Évalué à 1.
Si on utilise un nombre non-signé pour représenter le nombre de secondes depuis le 1er janvier 1970, on tiendrait jusqu'en 2106, ce qui est déjà beaucoup mieux.
Le bug de l'an 2038, c'est pcq c'est un nombre signé qui est utilisé, et donc en théorie, avec ce système, on peut dire qu'un fichier date de 1902. Ou mieux, envoyer un mail datant de 1902, ce qui serait assez rigolo (mais je n'ai pas été lire la RFC pour voir si c'était possible, et si ça tombe le mail se base sur une autre unité).
[^] # Re: Inconvénient des autotools
Posté par swilmet . En réponse à la dépêche Petit éventail des outils de construction (« builder ») libres. Évalué à 3.
Solaris, HP-UX, AIX, c'est du UNIX, mais c'est aussi du proprio…
Par exemple Solaris est livré avec le compilateur Sun Studio. Ça peut être intéressant de l'utiliser sur une machine SPARC pcq Sun Studio contient des options de compilations spécifiques à ce processeur qui n'existent pas dans GCC.
Pourquoi ils ne contribuent pas plutôt à GCC ou LLVM/Clang ? Ça je n'en sais rien. Peut-être que si Oracle n'avait pas racheté Sun, ce serait le cas, vu que Sun était plus « libre-friendly » (OpenSolaris, …).
Donc le fait qu'ils n'installent pas les outils GNU est sans doute dû au fait que ces OS sont quand même propriétaire, et qu'ils ont développé depuis de nombreuses années des logiciels maisons qui s'intègrent bien à leur OS.
[^] # Re: Exemple concret de line(1)
Posté par swilmet . En réponse au journal Line meurt. Évalué à 1.
Ça ne m'avance pas du tout pour comprendre l'utilité dans un script…
# Exemple concret de line(1)
Posté par swilmet . En réponse au journal Line meurt. Évalué à 3.
Je ne connaissais pas cette commande, et je ne vois pas trop dans quel cas ça peut être utile.
Tu as un exemple concret ?