J'avais essayé la version 0.2.4. Elle avait des bugs assez désagréables (des problèmes lors de la suppression de tâches). C'est pour ça que je l'avais abandonné.
La dernière version c'est bien plus agréable à utiliser, je vais essayer de l'utiliser plus longtemps :)
Donc merci beaucoup pour le travail.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Sur Xeon Phi, c'est pas NUMA, mais y a beaucoup de cœurs, donc il va falloir que la parallélisation OpenMP scale bien, ce qui n'est pas toujours évidemment.
J'ai parlé d'OpenMP parce qu'un commentaire disait avant que ça y ressemblait, mais c'est quelque chose de spécifique fourni par Intel donc ça doit mieux se passer.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Dans la liste des points qui peuvent influencer ce chiffre, j'ai oublié de parler du système de refroidissement qui peut beaucoup influencer ce chiffre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
L'objectif va être dans les prochaines années d'améliorer l'efficacité énergétique de ces machines (puissance de 12.7 MW pour le K-computer par exemple). Pour ces 12.7 MW, il faut compter sur une facture d'électricité de 1 million d'euros par mois environ :-)
D'ailleurs, sur le site du K, il y a une centrale à gaz rien que pour alimenter la bestiole !
Il faut noter que la consommation ne vient pas uniquement de la consommation électrique des composant mais aussi du système de refroidissement. De ce que je crois en savoir, aujourd'hui, si on dit qu'une de ces machines consomme 1MW, il y a grosso modo 50% qui est consommé par le système de refroidissement. L'un des enjeux est d'arriver à améliorer cela. Les techniques vont être de rapprocher le watercooling des composant pour arriver à faire ce qui est fait sur les machines de particulier, c'est à dire que les CPU auront un slot dans le quel on ferra passer de l'eau. Cela pourrait, à moyen terme fortement la puissance consommer pour les systèmes de refroidissement.
Bien sûr ce n'est pas pour ça que les machines consommeront moins, elles seront plus puissantes et auront un meilleur rendement.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Ça me fait penser à un autre problème : les transports en commun. Je ne m'assoie plus en transport en commun sauf si je suis vraiment crevé ou que le dis transport soit vide parce que quand quelqu'un arrive que ce soit une femme ou une personne âgée soit tu ne te lève pas et tu passe pour quelqu'un qui n'a aucun savoir vivre, soit tu te lève et les gens peuvent se sentir insulté que tu te sens plus en forme qu'eux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je présume qu'ils n'accèdent pas à la mémoire de manière aussi simple que le processeur principal. Donc quand tu veut gérer une grande quantité de données ça risque de poser problème d'avoir a faire de gros transfert entre la mémoire principale et la mémoire du coprocesseur.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je ne connais pas l'usage des pragma mais si c'est vraiment comme celles d'OpenMP ça permet de gagner facilement beaucoup sur des cas simple. La parallélisation des boucles ne posera problèmes que :
si les itérations sont interdépendantes ou utilisent des données partagées (autre que dans des cas particuliers)
si elles utilisent une grande quantité de données
Mais c'est déjà pas mal.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Est-ce qu'il vaut mieux parier sur un GPU adapté au calcul haute performance ou bien est-ce que l'approche d'Intel, consistant à privilégier la compatibilité x86, va finalement l'emporter ?
Je pense que c'est une question de besoin. Pour certains domaines, comme la simulation nucléaire militaire, les logiciels sont déjà écris et les re-valider pour passer à une architecture CUDA peut couter chère.
Pour des nouveaux codes la facilité de développement et le fait de ne pas avoir à faire des échanges mémoire fréquent entre la carte d'extension et la mémoire principale peut aussi donner un avantage à x86.
Bref plus que de savoir la quelle est la meilleure architecture dans l'absolue, il me semble que c'est plus une question de cas d'usage.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
L'efficacité [de Sequoia] est de 2 031,6 MFlops/W et on peut noter que Titan, en combinant des CPU et des GPU, arrive à offrir une meilleure efficacité (2 143 MFlops/W) énergétique que Sequoia et ses CPU développés spécialement par IBM.
(C'est moi qui ai ajouté ce qui est en italique)
Cette comparaison n'est pas complète, je pense. La consommation ne viens pas uniquement de la puissance de calcul. En effet la mémoire est elle aussi un gouffre de puissance sur ce genre de machines. Il y a d'autres caractéristique importantes (comme la vitesse pour sauvegarder la mémoire vive en mémoire physique par exemple) qui peuvent être importantes sans pour autant influer sur la puissance de calcul.
Bref tout ça pour dire que si c'est en effet une caractéristique importante, ça ne suffit pas pour déduire que les GPU nVIDIA sont plus efficaces que les CPU IBM spécifiques.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Il n'y a que le secteur du PC où il est négligeable, […]
Qu'entends-tu par là ? C'est la démocratisation des ordinateurs personnels qui a poussé tout les autres domaines. Bien sûr c'est les jeux vidéos, mais même pour tout le reste à quoi sert d'avoir un réseau s'il n'y a personne pour se connecter dessus ? Pourquoi les téléphones devraient faire plus que le Nokia 3110 ?
Sans ce marché l'informatique existerait mais elle serait bien moins développée.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je n'ai pas dis que c'était bien ou mal, j'ai juste dis que dire que la compilation statique empêche d'avoir des mises à jour globales est faux. Tu pourrait très bien maintenir les sources des paquets et faire des mises à jours des paquets par mise à jour des sources et compilation statique de l'ensemble ce qui diminue la taille de ton téléchargement mais tu prend 300 créations de paquets dans les gencives.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
C'est dommage le paquet demande python en version 2.6.6-7 et la version de debian stable est 2.6.6-3. Je doute qu'il y ai des masses d'incompatibilité entre les deux).
Par contre je viens de voir qu'il dépend aussi de python-psutil en version 0.4.1 alors que la version de debian stable est 0.1.3-1, je ne sais pas s'il y a des incompatibilité entre ces deux versions.
C'est dommage parce que c'est un logiciel qui sera installé sur des serveurs qui ont plutôt tendances à être sous Debian Stable.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Tiens ça c'est bien dommage. Ça veut dire qu'il faut s'appliquer à faire des mv si on veut garder un historique des info ou que l'on écris sur un répertoire partagé par plusieurs machines ayant chacune leur instance de glances.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Posté par barmic .
En réponse au sondage Le libre et mon activité.
Évalué à 4.
Dernière modification le 12 novembre 2012 à 09:13.
Je pense que les résultats serait très différents si la question portait sur la toolchain qu'on utilise. Par exemple moi au boulot je ne bosse pas pour du logiciel libre, mais à l'exception de ce qui est expressément demandé par ma boite tout le reste de mes logiciels sont libres et je ne pourrais pas bosser (développer et debugger des comportements erronés du logiciel) sans eux.
Pour la suite bureautique j'utilise libo 95% du temps et MS dans certains cas (par exemple certains de mes collègues utilisent visio pour faire les schémas et je n'ai pas toujours le temps ou le courage de les refaire avec un outil libre (généralement dia ou inkscape)…).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Et comme sous Windows tu dois faire les mises à jour manuellement pour la plupart des logiciels tiers et qu'une bonne partie des utilisateurs ne le font pas, tu as du coup un terrain favorable à l'exploitation de failles…
Ça n'a rien avoir. Tu peut très bien avoir des logiciels compilés en statique dans les dépôt des distributions et donc mis à jour comme ça l'est actuellement sous Linux et BSD.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je peux critiquer un choix de développement, je présume, non ? J'affirme qu'avoir 2 dépendances qui dépendent de runtime différents apportent un certains nombre de problèmes. Ma phrase était un peu assassine mais mon commentaire était argumenté et expliqué.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Des erreurs arrivent toujours, et c'est bien de prendre soin d'éduquer les développeurs, mais il se trouve que dans ce cas précis je pense pouvoir prédire sans me tromper qu'utiliser à la fois du software perl et du software python leur a vraiment simplifié la vie, et que supprimer l'un des deux leur demanderait du travail pour un bénéfice qui n'en vaut pas la peine.
Comme répété déjà 3 fois : c'est une situation qui peut avoir du sens mais il ne faut pas oublier qu'elle apportent un certains nombre de contraintes et de problèmes (déjà sus-cité).
Bien sûr si toi tu accordes une importance supérieure à ces questions (tu choisis de favoriser la propreté du design plutôt que les besoins objectifs, ce qui peut avoir un intérêt, je le dis en perfectionniste averti), […]
Avoir des contraintes de simplicité et de temps c'est tout à fait normal. Faire des choix pragmatiques aussi, mais ce n'est pas pour ça qu'il faut se voiler la face et dire qu'il n'y a pas de problème. Il est tout à fait possible d'adopter une solution simple et rapide tout en indiquant qu'il faudra faire mieux plus tard. Reconnaître ce genre de chose n'est pas une tare.
[…] tu es libre de donner ton propre temps pour résoudre cette situation, c'est beau le logiciel libre.
Tu as raison, tout comme je suis libre de faire des remarques. Je regarderais plus en détail ce que c'est ces dépendances.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je ne sais pas ce que tu veux dire par "en lisant un peu plus", j'ai bien sûr lu le billet avant de le critiquer.
Je voulais dire « en allant 2 paragraphes plus bas ».
Le texte que tu cites n'a rien de particulièrement convaincant : tu peux avoir un paquet Firefox qui dépend du paquet Toto qui lui-même dépend du paquet Tiff pour certaines de ses fonctionnalités, que Firefox lui-même n'utilise pas (genre, au hasard, un truc à la ImageMagick qui supporte 60 formats dont 59 intéressent Firefox).
Merci je connais la logique qui induit ce genre de dépendances.
De même, Firefox peut décider d'utiliser deux bibliothèques super utiles, une pour parser le HTML et l'autre pour communiquer à travers le réseau, l'une étant écrite en Python et l'autre en Perl, deux langages qui demandent un support runtime donc doivent être installés avec ces libs.
Soit.
Qu'est-ce que l'auteur aigri conseille aux développeurs de Firefox (ou autre) de faire en ce cas ?
D'arrêter de faire du bloatware. Avoir 2 runtimes (un perl et un python) pour finallement en exécuter un autre (JS), en passant son temps à faire des bindings dans tout les sens ces contre-productifs et contre-performant. Ça rend le logiciel plus compliquer à maintenir (multiplier les langages dans un même projet ça ne simplifie rien). Ça rend de plus le logiciel plus fragile si l'une des briques a un problème, firefox en a un.
Ré-écrire l'une des bibliothèques dans l'autre langage pour n'installer qu'un seul runtime ?
Je vais me contenter de citer ce que j'ai dis dans le journal :
Bien sûr qu'il peut y avoir de bonnes raisons pour ajouter une dépendance, mais il faut justement la chercher avant de la créer.
Si la raison est simplement qu'un développeur préfère tel ou tel langage, ça ne me semble pas être une bonne raison.
Le problème à grande échelle c'est que l'on arrive a avoir des systèmes de paquet dont le graphe de dépendances des paquets se rapproche d'une clique pour éxagérer. Tu peut le voir comme un aigri, mais c'est un réel problème pour le packaging.
Sauf que dans la vraie vie ces gens-là ont bien plus intéressant et utile à faire de leur temps et leur énergie, pour aider à résoudre d'autres problèmes qui font certainement râler quelqu'un d'autre sur le net.
Parce que tu pense que la lourdeur de Firefox n'est pas aussi (mais pas que) lié à ce genre de gestion ? Si demain, Mozilla trouve qu'OSGi est vraiment la meilleure manière pour gérer les plugins et ajoute comme dépendance à Firefox la JVM (et felix histoire de). Tu vois pas où est-ce que ça peut mener ?
Et si un jour ces problèmes deviennent gênants (oui ça arrive), les gens investissent plus d'effort là-dedans, on a un peu plus de cathédrale et un peu moins de bazaar le temps d'une restructuration, et ça repart.
Ouai on se traine une dette technique et il n'y a que quand on ne peu plus regarder ailleurs qu'on y fait attention. C'est une manière de faire, c'est pas la seule et je pense que tu peut comprendre que l'opposée est envisageable.
PS: et tout ce que j'ai dit est assez évident, tu aurais certainement pu faire l'effort de dérouler cette argumentation toi-même.
Tout comme sa critique était assez évidente, tu aurais probablement pu faire l'effort de la dérouler toi même.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
L'auteur râle parce qu'un paquet donné a trop de dépendances. En même temps il râle parce que certains codes sont copiés dans plein de paquets différents. C'est quoi la solution pour résoudre son deuxième problème ? Factoriser le code comme un paquet et en faire… une dépendance supplémentaire. Bonjour la contradiction.
En lisant un peu plus, on voit de quoi il veut parler :
Here is one example of an ironic piece of waste: Sam Leffler's graphics/libtiff is one of the 122 packages on the road to www/firefox, yet the resulting Firefox browser does not render TIFF images. For reasons I have not tried to uncover, 10 of the 122 packages need Perl and seven need Python; one of them, devel/glib20, needs both languages for reasons I cannot even imagine.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
C'est un code écrit en quelques minutes en parcourant vite fait la page wikipedia. À la relecture je vois qu'il accepte la valeur 0 ce qui n'est pas bon, non plus.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Réellement je ne lui trouve pas de défauts (enfin si peut être mais c'est pas le sujet).
Avec CMake tu va écrire un CMakeLists.txt qui va te permettre de générer des fichiers pour différents systèmes de build, dont autotool si je ne me trompe pas. Pour la recherche de bibliothèques il s'appuie sur ces générateurs, non ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
2) leur code ne serait pas commité s'ils refusent les règles (libre à eux de forker s'ils pensent que c'est la bonne solution).
Et c'est là que le bazard arrive, justement, genre, je sais pas, les dernières évolutions de gnome et les forks qui en découlent?
Au final, même le dev en bazard n'évite pas le fork, parce que tout connement, peu importe la méthode de dev, il y a toujours quelqu'un ou une minorité qui a l'ascendant sur la communauté… comme Linus Torvalds l'a sur Linux (et Lennart sur systemd? aborder cet outil finira par donner le droit au point godwin huuhu)
Gnome fait fasse à une crise ça peut arriver. Une direction donnée par le projet qui ne correspond plus à l'attente d'une partie de leur utilisateurs. C'est le principe d'un fork. Après les « forkeurs » ne se mettent pas d'accord pour sur la manière de forker et on se retrouve avec mate et cynamone, mais c'est à mon avis transitoire.
Mais certaines grandes lignes pourraient devenir communes et on verrait apparaître des standards de >fait.
Les distros obéissent à ce point pour certaines choses:
_ redhat et ses filles => rpm
_ debian et ses filles => deb
_ toutes celles que je connais (pas besef) => Xorg
Pour Xorg elles n'ont pas trop le choix.
Un modèle encore plus haut serait de passer par POSIX/LSB/Freedesktop pour plus de choses encore.
Je parlais surtout d'avoir un organisme de standard/normalisation. En l'état aucun des 3 ne fait le boulot. POSIX se met à jour très lentement et a plutôt tendance à être dans le mode inverse (elle normalise l'existant). Freedesktop est pas mal critiqué pour suivre plus Gnome que KDE, mais quoi qu'il en soit elle ne s'intéresse qu'au desktop (système d'init inclu évidement). C'est la LSB qui devrait faire ce travail mais elle ne le fait pas ou mal.
Je me vois mal obliger les dev de firefox à utiliser telle librairie gérant la sérialisation plutôt que boost::serialization, par exemple.
Tu ne les oblige pas. Mais entend que mainteneur tu peut dire que chez toi la biblio pour faire de la sérialisation c'est ultra_serialisation++ et que ce qui n'utilise pas celle-ci pourraient avoir des problèmes d'intégration. Si Debian et RedHat décident que toutes leur base logicielle sera dorénavant compilée en
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Ça n'est absolument pas mon propos. CMake est un super outil très pratique. C'est juste pas une solution de build. Il ne se substitue pas complètement aux autotools. Bref c'est pas CMake qui appel le compilateur (malheureusement).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Pas mal !
Posté par barmic . En réponse au journal Sortie de GTG 0.3 et de liblarch 2.1.1. Évalué à 5.
J'avais essayé la version 0.2.4. Elle avait des bugs assez désagréables (des problèmes lors de la suppression de tâches). C'est pour ça que je l'avais abandonné.
La dernière version c'est bien plus agréable à utiliser, je vais essayer de l'utiliser plus longtemps :)
Donc merci beaucoup pour le travail.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Architecture
Posté par barmic . En réponse à la dépêche Le Top 500 de novembre 2012. Évalué à 2.
J'ai parlé d'OpenMP parce qu'un commentaire disait avant que ça y ressemblait, mais c'est quelque chose de spécifique fourni par Intel donc ça doit mieux se passer.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rendement
Posté par barmic . En réponse à la dépêche Le Top 500 de novembre 2012. Évalué à 2.
Dans la liste des points qui peuvent influencer ce chiffre, j'ai oublié de parler du système de refroidissement qui peut beaucoup influencer ce chiffre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: En vrac...
Posté par barmic . En réponse à la dépêche Le Top 500 de novembre 2012. Évalué à 4.
Il faut noter que la consommation ne vient pas uniquement de la consommation électrique des composant mais aussi du système de refroidissement. De ce que je crois en savoir, aujourd'hui, si on dit qu'une de ces machines consomme 1MW, il y a grosso modo 50% qui est consommé par le système de refroidissement. L'un des enjeux est d'arriver à améliorer cela. Les techniques vont être de rapprocher le watercooling des composant pour arriver à faire ce qui est fait sur les machines de particulier, c'est à dire que les CPU auront un slot dans le quel on ferra passer de l'eau. Cela pourrait, à moyen terme fortement la puissance consommer pour les systèmes de refroidissement.
Bien sûr ce n'est pas pour ça que les machines consommeront moins, elles seront plus puissantes et auront un meilleur rendement.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: égalité
Posté par barmic . En réponse au journal Assurance auto : égalité hommes/femmes. Évalué à 3.
Ça me fait penser à un autre problème : les transports en commun. Je ne m'assoie plus en transport en commun sauf si je suis vraiment crevé ou que le dis transport soit vide parce que quand quelqu'un arrive que ce soit une femme ou une personne âgée soit tu ne te lève pas et tu passe pour quelqu'un qui n'a aucun savoir vivre, soit tu te lève et les gens peuvent se sentir insulté que tu te sens plus en forme qu'eux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Architecture
Posté par barmic . En réponse à la dépêche Le Top 500 de novembre 2012. Évalué à 3.
Je présume qu'ils n'accèdent pas à la mémoire de manière aussi simple que le processeur principal. Donc quand tu veut gérer une grande quantité de données ça risque de poser problème d'avoir a faire de gros transfert entre la mémoire principale et la mémoire du coprocesseur.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Architecture
Posté par barmic . En réponse à la dépêche Le Top 500 de novembre 2012. Évalué à 3.
Je ne connais pas l'usage des pragma mais si c'est vraiment comme celles d'OpenMP ça permet de gagner facilement beaucoup sur des cas simple. La parallélisation des boucles ne posera problèmes que :
Mais c'est déjà pas mal.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Architecture
Posté par barmic . En réponse à la dépêche Le Top 500 de novembre 2012. Évalué à 5.
Je pense que c'est une question de besoin. Pour certains domaines, comme la simulation nucléaire militaire, les logiciels sont déjà écris et les re-valider pour passer à une architecture CUDA peut couter chère.
Pour des nouveaux codes la facilité de développement et le fait de ne pas avoir à faire des échanges mémoire fréquent entre la carte d'extension et la mémoire principale peut aussi donner un avantage à x86.
Bref plus que de savoir la quelle est la meilleure architecture dans l'absolue, il me semble que c'est plus une question de cas d'usage.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Rendement
Posté par barmic . En réponse à la dépêche Le Top 500 de novembre 2012. Évalué à 4.
(C'est moi qui ai ajouté ce qui est en italique)
Cette comparaison n'est pas complète, je pense. La consommation ne viens pas uniquement de la puissance de calcul. En effet la mémoire est elle aussi un gouffre de puissance sur ce genre de machines. Il y a d'autres caractéristique importantes (comme la vitesse pour sauvegarder la mémoire vive en mémoire physique par exemple) qui peuvent être importantes sans pour autant influer sur la puissance de calcul.
Bref tout ça pour dire que si c'est en effet une caractéristique importante, ça ne suffit pas pour déduire que les GPU nVIDIA sont plus efficaces que les CPU IBM spécifiques.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Échec
Posté par barmic . En réponse au journal Si on commençait un nouvel OS libre de bureau aujourd'hui.... Évalué à 2.
Qu'entends-tu par là ? C'est la démocratisation des ordinateurs personnels qui a poussé tout les autres domaines. Bien sûr c'est les jeux vidéos, mais même pour tout le reste à quoi sert d'avoir un réseau s'il n'y a personne pour se connecter dessus ? Pourquoi les téléphones devraient faire plus que le Nokia 3110 ?
Sans ce marché l'informatique existerait mais elle serait bien moins développée.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Je n'en veux pas d'un tel système
Posté par barmic . En réponse au journal Si on commençait un nouvel OS libre de bureau aujourd'hui.... Évalué à 3.
Je n'ai pas dis que c'était bien ou mal, j'ai juste dis que dire que la compilation statique empêche d'avoir des mises à jour globales est faux. Tu pourrait très bien maintenir les sources des paquets et faire des mises à jours des paquets par mise à jour des sources et compilation statique de l'ensemble ce qui diminue la taille de ton téléchargement mais tu prend 300 créations de paquets dans les gencives.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Paquet Debian
Posté par barmic . En réponse à la dépêche Glances, l’outil de supervision système passe en version 1.5. Évalué à 4.
C'est dommage le paquet demande python en version 2.6.6-7 et la version de debian stable est 2.6.6-3. Je doute qu'il y ai des masses d'incompatibilité entre les deux).
Par contre je viens de voir qu'il dépend aussi de python-psutil en version 0.4.1 alors que la version de debian stable est 0.1.3-1, je ne sais pas s'il y a des incompatibilité entre ces deux versions.
C'est dommage parce que c'est un logiciel qui sera installé sur des serveurs qui ont plutôt tendances à être sous Debian Stable.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: nmon ?
Posté par barmic . En réponse à la dépêche Glances, l’outil de supervision système passe en version 1.5. Évalué à 2.
Je pense que glances est vraiment fait pour être simple assez loin des grosses solutions comme nagio, shinken et autres.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: nmon ?
Posté par barmic . En réponse à la dépêche Glances, l’outil de supervision système passe en version 1.5. Évalué à 2.
Tiens ça c'est bien dommage. Ça veut dire qu'il faut s'appliquer à faire des mv si on veut garder un historique des info ou que l'on écris sur un répertoire partagé par plusieurs machines ayant chacune leur instance de glances.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Patchs
Posté par barmic . En réponse au sondage Le libre et mon activité. Évalué à 4. Dernière modification le 12 novembre 2012 à 09:13.
Je pense que les résultats serait très différents si la question portait sur la toolchain qu'on utilise. Par exemple moi au boulot je ne bosse pas pour du logiciel libre, mais à l'exception de ce qui est expressément demandé par ma boite tout le reste de mes logiciels sont libres et je ne pourrais pas bosser (développer et debugger des comportements erronés du logiciel) sans eux.
Pour la suite bureautique j'utilise libo 95% du temps et MS dans certains cas (par exemple certains de mes collègues utilisent visio pour faire les schémas et je n'ai pas toujours le temps ou le courage de les refaire avec un outil libre (généralement dia ou inkscape)…).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Windows 8
Posté par barmic . En réponse à la dépêche Supercopier 2.3. Évalué à 3.
Windows 8 n'a-t'il pas signé la mort de ce type de logiciel (sous windows en tout cas) avec son propre gestionnaire ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Je n'en veux pas d'un tel système
Posté par barmic . En réponse au journal Si on commençait un nouvel OS libre de bureau aujourd'hui.... Évalué à 6.
Ça n'a rien avoir. Tu peut très bien avoir des logiciels compilés en statique dans les dépôt des distributions et donc mis à jour comme ça l'est actuellement sous Linux et BSD.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Inepties
Posté par barmic . En réponse à la dépêche « Une génération perdue dans le bazar ». Évalué à 2.
Je peux critiquer un choix de développement, je présume, non ? J'affirme qu'avoir 2 dépendances qui dépendent de runtime différents apportent un certains nombre de problèmes. Ma phrase était un peu assassine mais mon commentaire était argumenté et expliqué.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Inepties
Posté par barmic . En réponse à la dépêche « Une génération perdue dans le bazar ». Évalué à 3.
Comme répété déjà 3 fois : c'est une situation qui peut avoir du sens mais il ne faut pas oublier qu'elle apportent un certains nombre de contraintes et de problèmes (déjà sus-cité).
Avoir des contraintes de simplicité et de temps c'est tout à fait normal. Faire des choix pragmatiques aussi, mais ce n'est pas pour ça qu'il faut se voiler la face et dire qu'il n'y a pas de problème. Il est tout à fait possible d'adopter une solution simple et rapide tout en indiquant qu'il faudra faire mieux plus tard. Reconnaître ce genre de chose n'est pas une tare.
Tu as raison, tout comme je suis libre de faire des remarques. Je regarderais plus en détail ce que c'est ces dépendances.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Inepties
Posté par barmic . En réponse à la dépêche « Une génération perdue dans le bazar ». Évalué à 2.
Je voulais dire « en allant 2 paragraphes plus bas ».
Merci je connais la logique qui induit ce genre de dépendances.
Soit.
D'arrêter de faire du bloatware. Avoir 2 runtimes (un perl et un python) pour finallement en exécuter un autre (JS), en passant son temps à faire des bindings dans tout les sens ces contre-productifs et contre-performant. Ça rend le logiciel plus compliquer à maintenir (multiplier les langages dans un même projet ça ne simplifie rien). Ça rend de plus le logiciel plus fragile si l'une des briques a un problème, firefox en a un.
Je vais me contenter de citer ce que j'ai dis dans le journal :
Si la raison est simplement qu'un développeur préfère tel ou tel langage, ça ne me semble pas être une bonne raison.
Le problème à grande échelle c'est que l'on arrive a avoir des systèmes de paquet dont le graphe de dépendances des paquets se rapproche d'une clique pour éxagérer. Tu peut le voir comme un aigri, mais c'est un réel problème pour le packaging.
Parce que tu pense que la lourdeur de Firefox n'est pas aussi (mais pas que) lié à ce genre de gestion ? Si demain, Mozilla trouve qu'OSGi est vraiment la meilleure manière pour gérer les plugins et ajoute comme dépendance à Firefox la JVM (et felix histoire de). Tu vois pas où est-ce que ça peut mener ?
Ouai on se traine une dette technique et il n'y a que quand on ne peu plus regarder ailleurs qu'on y fait attention. C'est une manière de faire, c'est pas la seule et je pense que tu peut comprendre que l'opposée est envisageable.
Tout comme sa critique était assez évidente, tu aurais probablement pu faire l'effort de la dérouler toi même.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Inepties
Posté par barmic . En réponse à la dépêche « Une génération perdue dans le bazar ». Évalué à 4.
En lisant un peu plus, on voit de quoi il veut parler :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Comme toujours les réponses sont dans Futurama
Posté par barmic . En réponse au journal Sexe et numéro de sécurité sociale en France. Évalué à 2.
C'est un code écrit en quelques minutes en parcourant vite fait la page wikipedia. À la relecture je vois qu'il accepte la valeur 0 ce qui n'est pas bon, non plus.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: trotrotrotro troll !
Posté par barmic . En réponse au journal A Generation Lost in the Bazaar. Évalué à 2.
Réellement je ne lui trouve pas de défauts (enfin si peut être mais c'est pas le sujet).
Avec CMake tu va écrire un CMakeLists.txt qui va te permettre de générer des fichiers pour différents systèmes de build, dont autotool si je ne me trompe pas. Pour la recherche de bibliothèques il s'appuie sur ces générateurs, non ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Objectivement...
Posté par barmic . En réponse au journal A Generation Lost in the Bazaar. Évalué à 2.
Gnome fait fasse à une crise ça peut arriver. Une direction donnée par le projet qui ne correspond plus à l'attente d'une partie de leur utilisateurs. C'est le principe d'un fork. Après les « forkeurs » ne se mettent pas d'accord pour sur la manière de forker et on se retrouve avec mate et cynamone, mais c'est à mon avis transitoire.
Pour Xorg elles n'ont pas trop le choix.
Je parlais surtout d'avoir un organisme de standard/normalisation. En l'état aucun des 3 ne fait le boulot. POSIX se met à jour très lentement et a plutôt tendance à être dans le mode inverse (elle normalise l'existant). Freedesktop est pas mal critiqué pour suivre plus Gnome que KDE, mais quoi qu'il en soit elle ne s'intéresse qu'au desktop (système d'init inclu évidement). C'est la LSB qui devrait faire ce travail mais elle ne le fait pas ou mal.
Tu ne les oblige pas. Mais entend que mainteneur tu peut dire que chez toi la biblio pour faire de la sérialisation c'est ultra_serialisation++ et que ce qui n'utilise pas celle-ci pourraient avoir des problèmes d'intégration. Si Debian et RedHat décident que toutes leur base logicielle sera dorénavant compilée en
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: trotrotrotro troll !
Posté par barmic . En réponse au journal A Generation Lost in the Bazaar. Évalué à 2.
Ça n'est absolument pas mon propos. CMake est un super outil très pratique. C'est juste pas une solution de build. Il ne se substitue pas complètement aux autotools. Bref c'est pas CMake qui appel le compilateur (malheureusement).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)