Un tri... Sur un tableau, on a tendance à trier le contenu (trier les indices n'a pas grand intérêt), alors que sur une map, on triera plutôt selon les clefs (quand ça a un sens, ce qui n'est pas gagné).
Un langage pour les gouverner tous... ça n'existe pas !
Que les tableaux et les maps (et les chaines de caractères) soient intégrés dans un langage de script, ça ne me choque pas, au contraire, je dirais que ça simplifie la vie. Mais que ce soit intégré dans un langage bas niveau comme le C ou comme veut l'être Go, non merci. Quand on utilise un langage bas niveau, c'est pour pouvoir tout contrôler et optimiser là où il faut. Un join sur un tableau de string, ça peut très bien se faire en C de manière très optimisée, sans doute bien plus rapidement que n'importe quel langage qui intègrerait tout.
Déjà, il est faux de dire (comme le faisait un post plus haut) que les interfaces de Go sont "équivalents" aux templates de C++.
Je ne disais pas ça, je disais qu'avec des templates C++ (et les concepts qui ne font pas encore partie de C++), on avait un équivalent des interfaces Go. Certes, on peut faire beaucoup plus de choses avec les templates, mais je n'en ai absolument pas parlé.
Mais à force de se focaliser sur des détails bas niveau sans grand intérêt, on se fossilise dans des conceptions dépassées qui sont au final moins performantes.
Déjà croire que les GC sont la solution miracle à tous les problèmes d'allocation mémoire, c'est se mettre le doigt dans l'oeil parce qu'un GC n'est jamais parfait. Ensuite, dans certains domaines comme l'embarqué, la consommation mémoire doit être strictement encadrée parce qu'il y en a peu. Et c'est plus souvent ce point qui pousse à utiliser une allocation manuelle que la "performance". Il est montré qu'un GC peut être aussi performant que l'allocation manuelle mais qu'il prend 5 fois plus de mémoire !
un tableau est essentiellement une map avec des clés entières au domaine restreint à être de la forme [0..N-1]
Bienvenue dans PHP ! Et tout codeur PHP sait tous les problèmes que ce genre de considération peut poser. Un tableau et une map, ce n'est pas la même chose. Ils n'ont pas la même utilité. Et on peut tout à fait les mettre les deux dans un langage sans les fusionner. Ce qui permettra d'optimiser certaines opérations suivant qu'on a un tableau ou une map.
De même, les templates C++ sont équivalents aux interfaces Go, sauf qu'on ne déclare pas l'interface, on utilise des méthodes d'un type et on peut instancier le template avec n'importe quel type qui implémente les méthodes. La définition des interfaces devaient être incluses dans le nouveau C++ sous le nom de concept mais a été annulé.
Non, tu n'es pas seul. Je trouve sa syntaxe vraiment bizarre. Il y a plein de choses que j'aime pas, notamment make, l'omission des parenthèses (autour de la condition du if par exemple) qui rendent le code difficilement compréhensible, la différence array/slice, le mélange entre pointeurs et références cachés (comme les map) qui fait que suivant le truc, l'argument est passé par valeur ou par référence, le goto, la précédence des opérateurs simpliste qui fait que 3 * 2 << 2 n'est pas égal à 2 << 2 * 3 (alors que dans la plupart des autres langages, c'est le cas)...
Bref, beaucoup d'inconvénients pour peu d'avantages (pour moi, un gc n'est pas un avantage).
Sur Jamendo, les tags étaient assez bien gérés (je ne sais pas si c'est toujours comme ça). En gros, on pouvait ajouter un tag avec "+tag" et on pouvait en retirer avec "-tag". Si le tag était présent, ça lui donnait plus de poids ou ça lui enlevait du poids (jusqu'à disparaître). Du coup, le système convergeait assez bien vers un consensus.
Posté par rewind (Mastodon) .
En réponse au journal IE9.
Évalué à 4.
Oui c'est bien ce que je dis. HTML5, c'est défini comme du XHTML5 écrit avec les pieds mais tout le monde doit avoir la même déformation des pieds (n'y voyez aucune allusion à GNOME), comme ça les navigateurs qui corrigeait pas de la même manière avant vont maintenant tous faire la même chose.
Posté par rewind (Mastodon) .
En réponse au journal IE9.
Évalué à 5.
XHTML n'est pas mort, juste le nom. HTML5, c'est un dialecte XML comme les autres, avec en plus une normalisation pour ceux qui savent pas fermer des balises pour que tous les navigateurs "corrigent" de la même manière.
Sur Wikipedia (Loi) : «Adage (non légal) qui ne signifie pas que l'on doit connaître l'ensemble des lois, mais selon lequel on ne peut invoquer l'ignorance de la loi pour échapper à la loi.»
Ce que tu dis est vrai selon ta vision où il n'existe que des contrats entre entités économiques privées (et, sous-entendu, peu de lois pour réguler). Malheureusement pour toi, il y a aussi l'État qui peut fourrer son nez dedans et obliger MS à faire autre chose. Et tu le sais parfaitement puisque ça s'est déjà produit aux US, qui ne sont pourtant pas des grands fans de l'État.
«Nul n'est censé ignorer la loi» (puisque je crois que c'est à ça que tu fais allusion), ça ne concerne que le pénal (meurtres, viols, toussa), pas le reste. Il n'y a aucune «obligation» de connaître les lois, encore moins exhaustive (et heureusement). Il faut juste savoir ce qui est interdit pénalement, ce qui me semble être le minimum dans une société civilisée.
Ne faisant pas de python, chaque fois que je regarde du code python, j'ai l'impression que personne n'utilise les mêmes conventions de nommage et que même à l'intérieur de la lib standard, il y a plusieurs conventions. N'est-ce pas un handicap à son adoption, surtout quand on voit Ruby ou Java qui ont des conventions fortes et respectées à peu près partout ?
La lib QtCore fait entre 2 et 3 fois la taille de la GLib, sans compter qu'intégrer une lib C++ dans une lib C c'est moins évident que l'inverse.
Chez moi (Debian amd64) : GLib = 934K, QtCore = 2,6M.
Mais il faut ajouter GObject parce que même si on peut utiliser GLib sans GObject, tous les projets cités l'utilisent. Donc GObject = 309K.
Et bien tu vois, entre l'un et l'autre, honnêtement, il n'y a pas tant de différence. Il y aurait un facteur 10, je dis pas, on pourrait critiquer, mais là, moins de 3, ça va pas chercher très loin, on reste dans le même ordre de grandeur.
tu gères comment la dépendance circulaire, si on doit jouer au zero sum entre GLib et QtCore ?
Il n'y a aucune dépendance circulaire entre GLib et QtCore, les deux sont implémentés indépendamment l'une de l'autre et n'utilise pas du tout l'autre. Et un projet peut utiliser soit l'une, soit l'autre.
GStreamer est le seul framework multimédia potable sous *nix
Et Xine ? Et mplayer/ffmpeg ? Sérieusement, tu dis n'importe quoi là. Les dev GNOME ne jurent que par GStreamer qui n'a jamais été massivement adopté pour des raisons à la fois de non-stabilité (comme PulseAudio, ça a mis des plombes à marcher correctement pour des utilisations basiques) et de non compatibilité de l'API entre la 0.8 et la 0.10.
Pango n'est pas hébergé par FreeDesktop ni même utilisé par Qt ou KDE.
Il est cité comme projet fd.o sur les wikipedia fr et en. Donc il est supporté par fd.o même s'il n'est pas hébergé par fd.o. Et oui Qt avait sa propre solution (et je ne pense pas que l'un ait eu l'antériorité sur l'autre) donc KDE utilisait le truc de Qt. Mais il se trouve qu'un nouveau projet est arrivé pour unifier tout ça : HarfBuzz. Attendons de voir ce que ça donnera.
Par ailleurs, GStreamer est né en dehors de GNOME et a une vie indépendamment de celui-ci.
Ha ça c'est sûr, tout le monde en est convaincu : d'ailleurs, si on regarde les news du projet GStreamer depuis sa création, le développeur s'est rendu plusieurs fois au GUADEC (jamais à l'Akademy), GStreamer est utilisé par GNOME depuis 2002 (alors que seuls quelques applis KDE l'ont utilisé : Juk et Amarok (même si tout le monde utilisait le backend Xine d'Amarok pour les raisons cités précédemment)), et même sur la page wikipedia anglaise de GStreamer a une boite GNOME en bas, le citant parmi les technologies GNOME. Vraiment, là, c'était trop gros, ça ne passe pas.
Forcément, si les mecs de KDE croient que pour balancer une spécification, suffit de balancer une implémentation complète puis de faire un plébiscite
C'est marrant, tu dis plus haut qu'une dépendance à la GLib, c'est pas grave, mais une dépendance à Qt Core (l'équivalent de GLib en somme), c'est inacceptable. Pourtant, quand on regarde de près, c'est à peu près la même chose, et l'un n'est pas plus insensé que l'autre. D'ailleurs, on constatera que dans les dépendances de KDE, il y a GLib mais dans les dépendances de GNOME, point de Qt Core. Du coup, pour moi, ceux qui essaient d'intégrer au mieux les technos de l'autre, c'est pas GNOME.
Et dans les projets FreeDesktop discutables, il y a GStreamer et Pango. L'un comme l'autre ont été imposé par GNOME. GStreamer étant la solution son de GNOME, et Pango étant la solution de rendu de fontes (issue à la base de Gtk si je me souviens bien, qui est quand même le concurrent de Qt Gui). Les deux, en plus de la GLib, se traîne GObject ! On pourrait aussi citer PolicyKit ou DeviceKit ou encore le vénérable HAL. Tous sont dans ce cas d'utiliser GLib+GObject. Hormis Pango (pour lequel il existe un équivalent dans Qt), KDE n'a jamais refusé d'intégrer ces composants développés par RedHat pour la plupart et donc avec GNOME en tête.
Dans le cas présent, pour une fois, c'est KDE qui propose la première implémentation. Et paf, GNOME refuse en donnant les excuses les plus minables que j'ai jamais vues. Ça va de "ça ne nous intéressait pas" (contredit plus loin par "on l'a mis dans GNOME Shell") à "ça s'est fait sans nous" (alors que aseigo montre que KDE a pris en compte les remarques venant de GNOME). Bref, que des justifications très égocentriques.
J'espère que cela clarifie la forme, et qu'on puisse maintenant passer au fond.
Le fond et la forme sont intimement liés ici. Le choix de la licence n'est pas neutre puisqu'il donne une indication sur le contenu du livre (qui parle lui-même de licences et de diffusion). Et en l'occurrence, ce qui me gêne, que ce soit dans la licence ou dans le contenu du bouquin, c'est "commercial". Je m'explique.
Il est tout à fait louable de vouloir vivre de son art et donc d'en faire commerce, rien de mal à ça. Mais de quoi parle-t-on là ? De création. Or, tout ce qui est créé n'est (heureusement) pas vendu. Les dessins des enfants à la maternelle sont protégés par le droit d'auteur au même titre que la dernière bouse auditive qui passe sur les radios. L'un est vendu, l'autre non. Les licences libres, comme le droit d'auteur, concernent toutes les oeuvres, indépendamment de leur commerce (d'ailleurs, il y a toujours un paragraphe dans les licences pour le dire). Et inutile de dire que les oeuvres qui font l'objet d'un commerce sont ultra-minoritaire par rapport à tout ce qui est protégé par le droit d'auteur.
Associer de telle manière création et commerce revient à dire, peu ou prou, que toute création doit être rémunéré, ce qui est assez dangereux à mon sens et risque justement de tuer la création. Car la création risque d'être guidée uniquement par des aspects commerciaux et pas artistique (et on y est déjà dans l'industrie musicale, inutile de l'étendre). On peut se poser légitimement la question de la rémunération des artistes, le livre y répond en partie. Mais faire croire qu'avec des licences qui permettent la diffusion et en associant systématiquement création et commerce, on va améliorer la création, j'ai un gros doute.
Il n'y a pas de suceurs, il est possible de le faire, et ils le font. C'est même dans l'esprit du libre que plein de boites puissent fournir du support pour le même logiciel, parce qu'elles peuvent l'étudier, le modifier, etc (4 libertés toussa). Et si des boîtes ont un mauvais support ou n'apporte aucune valeur ajoutée (RH y compris), elles sont remplacées par d'autres plus compétentes. Que je sache, RH n'a pas codé tous les logiciels qu'ils distribuent. Si tout le monde agissait comme eux, on s'en sortirait pas. RH pense peut-être qu'avec du marketting, on peut rester premier. Dans le propriétaire oui (Apple, MS), mais dans le libre non.
Sérieusement, ça fait partie du jeu du libre. S'ils ne sont pas content, ils laissent tous les softs dont eux profitent également et ils retournent faire du propriétaire. Pas sûr qu'ils y gagnent vraiment.
pourquoi est-ce que ce serait à "l'extrême gauche" de s'allier sur le PS ? Parce que dans la réalité que tu chéries tant, c'est comme ça que ça se passe : le PS se sent hégémonique et donc, il ne tient absolument aucun compte des programmes ou des idées de ses potentiels alliés (voir aussi la Gauche Plurielle comme cas pratique). Le PS ne connaît qu'un seul argument : le rapport de force. Autrement dit, le nombre de voix. Donc, le reste de la gauche joue avec les règles du PS.
dans ton raisonnement, tu oublies les 11 millions d'électeurs qui se sont abstenus au premier tour. Sachant que ça s'est joué à moins de 200000 voix, je crois qu'il faut arrêter d'être obsédé par ce qui est à gauche du PS, et regarder la réalité en face : le PS n'a pas réussi à convaincre ses potentiels électeurs.
Je ne pense pas. On en avait combien sur l'ancien site ? Une vingtaine je pense, en tout cas plus que maintenant. Et vu que la version RoR semble plus rapide, ça ne devrait pas poser de problème.
Au pire (mais ça demande plus de boulot), on laisse 10 par défaut pour le visiteur et on met une option pour les utilisateurs enregistrés (quand je dis "on", je veux bien sûr dire "notre maître codeur préféré").
Donc selon toi, ce que tu appelles "l'extrême gauche" doit se contenter de dire amen au programme du PS et ne pas présenter de candidat quand bien même le programme du PS n'avait rien de socialiste (dixit celui qui le portait) ? C'est n'importe quoi...
On t'explique que le PS n'a pas réussi à convaincre les électeurs de voter pour lui parce qu'il avait un programme pourri et toi, tu nous expliques que "l'extrême gauche" n'avait qu'à se ranger derrière ce programme pourri quand même. Vraiment, il y a des raisonnements qui me dépassent...
Enfin bon, faut arrêter de généraliser à tout va. Ce n'est pas "les grecs" qui ont foutu le merdier, c'est surtout le gouvernement de droite qui a maquillé les comptes, bien aidé en cela par Goldman Sachs (toujours dans les coups merdiques, mais pourquoi les É-U les ont pas laissé crever...) [1]. Du coup, à l'alternance, ça s'est vu.
Deuxième point, le problème n'est pas qu'ils aient trop emprunté (ils sont dans le haut du classement en % du PIB mais derrière l'Italie à qui on ne va pas chercher des poux). Et en plus, complètement ridicule en valeur absolue par rapport au PIB de l'UE. En plus, ils avaient une croissance remarquable jusqu'en 2008 (entre 3.5 et 4.7% entre 2003 et 2008, à faire rêver n'importe quel ministre de l'économie français). Non, ce qui pêchait, c'était les taux d'intérêt usurier auquel on leur prêtait. Et ça, ça ne vient pas de la nature ni de la main invisible du marché, ce sont des décisions politiques qui en sont à la base, ça vient de l'obsession allemande d'empêcher les états d'emprunter directement à la BCE au taux de 1% (actuellement) et de devoir passer par des banques à 3-5% pour les chanceux, et 15-20% pour la Grèce au plus fort... On est les seuls couillons au monde à le faire : ni les É-U, ni le Japon, ni la Chine ne le font. Mais nous si.
Alors je veux bien que tu m'expliques que tous les grecs sont des cons, fraudeurs et militaristes. N'empêche que le contexte européen, ça ne les a pas aidé. Et le FMI qui est passé par derrière pour expliquer que c'était pas les gentilles banques qui réclamaient beaucoup (dont Goldman Sachs, pour la touche d'humour) mais que c'est les grecs qui avaient trop dépensé... Mouhahahaha.
[^] # Re: c'est moi ou bien...
Posté par rewind (Mastodon) . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 2.
Un tri... Sur un tableau, on a tendance à trier le contenu (trier les indices n'a pas grand intérêt), alors que sur une map, on triera plutôt selon les clefs (quand ça a un sens, ce qui n'est pas gagné).
[^] # Re: c'est moi ou bien...
Posté par rewind (Mastodon) . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 3.
Un langage pour les gouverner tous... ça n'existe pas !
Que les tableaux et les maps (et les chaines de caractères) soient intégrés dans un langage de script, ça ne me choque pas, au contraire, je dirais que ça simplifie la vie. Mais que ce soit intégré dans un langage bas niveau comme le C ou comme veut l'être Go, non merci. Quand on utilise un langage bas niveau, c'est pour pouvoir tout contrôler et optimiser là où il faut. Un join sur un tableau de string, ça peut très bien se faire en C de manière très optimisée, sans doute bien plus rapidement que n'importe quel langage qui intègrerait tout.
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par rewind (Mastodon) . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 2.
Je ne disais pas ça, je disais qu'avec des templates C++ (et les concepts qui ne font pas encore partie de C++), on avait un équivalent des interfaces Go. Certes, on peut faire beaucoup plus de choses avec les templates, mais je n'en ai absolument pas parlé.
Déjà croire que les GC sont la solution miracle à tous les problèmes d'allocation mémoire, c'est se mettre le doigt dans l'oeil parce qu'un GC n'est jamais parfait. Ensuite, dans certains domaines comme l'embarqué, la consommation mémoire doit être strictement encadrée parce qu'il y en a peu. Et c'est plus souvent ce point qui pousse à utiliser une allocation manuelle que la "performance". Il est montré qu'un GC peut être aussi performant que l'allocation manuelle mais qu'il prend 5 fois plus de mémoire !
[^] # Re: c'est moi ou bien...
Posté par rewind (Mastodon) . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 4.
Bienvenue dans PHP ! Et tout codeur PHP sait tous les problèmes que ce genre de considération peut poser. Un tableau et une map, ce n'est pas la même chose. Ils n'ont pas la même utilité. Et on peut tout à fait les mettre les deux dans un langage sans les fusionner. Ce qui permettra d'optimiser certaines opérations suivant qu'on a un tableau ou une map.
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par rewind (Mastodon) . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 4.
De même, les templates C++ sont équivalents aux interfaces Go, sauf qu'on ne déclare pas l'interface, on utilise des méthodes d'un type et on peut instancier le template avec n'importe quel type qui implémente les méthodes. La définition des interfaces devaient être incluses dans le nouveau C++ sous le nom de concept mais a été annulé.
[^] # Re: c'est moi ou bien...
Posté par rewind (Mastodon) . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 10.
Non, tu n'es pas seul. Je trouve sa syntaxe vraiment bizarre. Il y a plein de choses que j'aime pas, notamment
make, l'omission des parenthèses (autour de la condition duifpar exemple) qui rendent le code difficilement compréhensible, la différence array/slice, le mélange entre pointeurs et références cachés (comme lesmap) qui fait que suivant le truc, l'argument est passé par valeur ou par référence, legoto, la précédence des opérateurs simpliste qui fait que3 * 2 << 2n'est pas égal à2 << 2 * 3(alors que dans la plupart des autres langages, c'est le cas)...Bref, beaucoup d'inconvénients pour peu d'avantages (pour moi, un gc n'est pas un avantage).
# Dans le même ordre d'idée
Posté par rewind (Mastodon) . En réponse à l’entrée du suivi Autoriser la suppression de tags. Évalué à 2 (+0/-0).
Sur Jamendo, les tags étaient assez bien gérés (je ne sais pas si c'est toujours comme ça). En gros, on pouvait ajouter un tag avec "+tag" et on pouvait en retirer avec "-tag". Si le tag était présent, ça lui donnait plus de poids ou ça lui enlevait du poids (jusqu'à disparaître). Du coup, le système convergeait assez bien vers un consensus.
[^] # Re: Par pitie
Posté par rewind (Mastodon) . En réponse au journal Du livre "Premiers cours de programmation en Scheme". Évalué à 3.
Diviser pour régner
http://fr.wikipedia.org/wiki/Diviser_pour_r%C3%A9gner_%28informatique%29
[^] # Re: XHTML ?
Posté par rewind (Mastodon) . En réponse au journal IE9. Évalué à 4.
Oui c'est bien ce que je dis. HTML5, c'est défini comme du XHTML5 écrit avec les pieds mais tout le monde doit avoir la même déformation des pieds (n'y voyez aucune allusion à GNOME), comme ça les navigateurs qui corrigeait pas de la même manière avant vont maintenant tous faire la même chose.
http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#parsing
[^] # Re: XHTML ?
Posté par rewind (Mastodon) . En réponse au journal IE9. Évalué à 5.
XHTML n'est pas mort, juste le nom. HTML5, c'est un dialecte XML comme les autres, avec en plus une normalisation pour ceux qui savent pas fermer des balises pour que tous les navigateurs "corrigent" de la même manière.
[^] # Re: Justice ?
Posté par rewind (Mastodon) . En réponse à la dépêche Racketiciel : changement de stratégie et grande audition. Évalué à 2.
Sur Wikipedia (Loi) : «Adage (non légal) qui ne signifie pas que l'on doit connaître l'ensemble des lois, mais selon lequel on ne peut invoquer l'ignorance de la loi pour échapper à la loi.»
Plus d'informations : http://www.vie-publique.fr/decouverte-institutions/citoyen/citoyennete/definition/devoirs-definition/que-signifie-nul-n-est-cense-ignorer-loi.html
[^] # Re: Concurrence déloyale ?
Posté par rewind (Mastodon) . En réponse à la dépêche Racketiciel : changement de stratégie et grande audition. Évalué à 2.
Ce que tu dis est vrai selon ta vision où il n'existe que des contrats entre entités économiques privées (et, sous-entendu, peu de lois pour réguler). Malheureusement pour toi, il y a aussi l'État qui peut fourrer son nez dedans et obliger MS à faire autre chose. Et tu le sais parfaitement puisque ça s'est déjà produit aux US, qui ne sont pourtant pas des grands fans de l'État.
[^] # Re: Justice ?
Posté par rewind (Mastodon) . En réponse à la dépêche Racketiciel : changement de stratégie et grande audition. Évalué à 5.
«Nul n'est censé ignorer la loi» (puisque je crois que c'est à ça que tu fais allusion), ça ne concerne que le pénal (meurtres, viols, toussa), pas le reste. Il n'y a aucune «obligation» de connaître les lois, encore moins exhaustive (et heureusement). Il faut juste savoir ce qui est interdit pénalement, ce qui me semble être le minimum dans une société civilisée.
[^] # Re: Et hop !
Posté par rewind (Mastodon) . En réponse à la dépêche Entretien avec des développeurs Python francophones. Évalué à 2.
Stack overflow
# Nommage dans python
Posté par rewind (Mastodon) . En réponse à la dépêche Entretien avec des développeurs Python francophones. Évalué à 7.
Ne faisant pas de python, chaque fois que je regarde du code python, j'ai l'impression que personne n'utilise les mêmes conventions de nommage et que même à l'intérieur de la lib standard, il y a plusieurs conventions. N'est-ce pas un handicap à son adoption, surtout quand on voit Ruby ou Java qui ont des conventions fortes et respectées à peu près partout ?
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par rewind (Mastodon) . En réponse au journal Gnome vs Canonical: l'avis de Aaron Seigo. Évalué à 5.
Chez moi (Debian amd64) : GLib = 934K, QtCore = 2,6M. Mais il faut ajouter GObject parce que même si on peut utiliser GLib sans GObject, tous les projets cités l'utilisent. Donc GObject = 309K. Et bien tu vois, entre l'un et l'autre, honnêtement, il n'y a pas tant de différence. Il y aurait un facteur 10, je dis pas, on pourrait critiquer, mais là, moins de 3, ça va pas chercher très loin, on reste dans le même ordre de grandeur.
Il n'y a aucune dépendance circulaire entre GLib et QtCore, les deux sont implémentés indépendamment l'une de l'autre et n'utilise pas du tout l'autre. Et un projet peut utiliser soit l'une, soit l'autre.
Et Xine ? Et mplayer/ffmpeg ? Sérieusement, tu dis n'importe quoi là. Les dev GNOME ne jurent que par GStreamer qui n'a jamais été massivement adopté pour des raisons à la fois de non-stabilité (comme PulseAudio, ça a mis des plombes à marcher correctement pour des utilisations basiques) et de non compatibilité de l'API entre la 0.8 et la 0.10.
Il est cité comme projet fd.o sur les wikipedia fr et en. Donc il est supporté par fd.o même s'il n'est pas hébergé par fd.o. Et oui Qt avait sa propre solution (et je ne pense pas que l'un ait eu l'antériorité sur l'autre) donc KDE utilisait le truc de Qt. Mais il se trouve qu'un nouveau projet est arrivé pour unifier tout ça : HarfBuzz. Attendons de voir ce que ça donnera.
Ha ça c'est sûr, tout le monde en est convaincu : d'ailleurs, si on regarde les news du projet GStreamer depuis sa création, le développeur s'est rendu plusieurs fois au GUADEC (jamais à l'Akademy), GStreamer est utilisé par GNOME depuis 2002 (alors que seuls quelques applis KDE l'ont utilisé : Juk et Amarok (même si tout le monde utilisait le backend Xine d'Amarok pour les raisons cités précédemment)), et même sur la page wikipedia anglaise de GStreamer a une boite GNOME en bas, le citant parmi les technologies GNOME. Vraiment, là, c'était trop gros, ça ne passe pas.
Tu veux dire "faire comme les devs GNOME" ?
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par rewind (Mastodon) . En réponse au journal Gnome vs Canonical: l'avis de Aaron Seigo. Évalué à 10.
C'est marrant, tu dis plus haut qu'une dépendance à la GLib, c'est pas grave, mais une dépendance à Qt Core (l'équivalent de GLib en somme), c'est inacceptable. Pourtant, quand on regarde de près, c'est à peu près la même chose, et l'un n'est pas plus insensé que l'autre. D'ailleurs, on constatera que dans les dépendances de KDE, il y a GLib mais dans les dépendances de GNOME, point de Qt Core. Du coup, pour moi, ceux qui essaient d'intégrer au mieux les technos de l'autre, c'est pas GNOME.
Et dans les projets FreeDesktop discutables, il y a GStreamer et Pango. L'un comme l'autre ont été imposé par GNOME. GStreamer étant la solution son de GNOME, et Pango étant la solution de rendu de fontes (issue à la base de Gtk si je me souviens bien, qui est quand même le concurrent de Qt Gui). Les deux, en plus de la GLib, se traîne GObject ! On pourrait aussi citer PolicyKit ou DeviceKit ou encore le vénérable HAL. Tous sont dans ce cas d'utiliser GLib+GObject. Hormis Pango (pour lequel il existe un équivalent dans Qt), KDE n'a jamais refusé d'intégrer ces composants développés par RedHat pour la plupart et donc avec GNOME en tête.
Dans le cas présent, pour une fois, c'est KDE qui propose la première implémentation. Et paf, GNOME refuse en donnant les excuses les plus minables que j'ai jamais vues. Ça va de "ça ne nous intéressait pas" (contredit plus loin par "on l'a mis dans GNOME Shell") à "ça s'est fait sans nous" (alors que aseigo montre que KDE a pris en compte les remarques venant de GNOME). Bref, que des justifications très égocentriques.
[^] # Re: Pourquoi CC-BY-ND-NC
Posté par rewind (Mastodon) . En réponse à la dépêche Manifeste pour une Création Artistique Libre par Roberto Di Cosmo. Évalué à 4.
Le fond et la forme sont intimement liés ici. Le choix de la licence n'est pas neutre puisqu'il donne une indication sur le contenu du livre (qui parle lui-même de licences et de diffusion). Et en l'occurrence, ce qui me gêne, que ce soit dans la licence ou dans le contenu du bouquin, c'est "commercial". Je m'explique.
Il est tout à fait louable de vouloir vivre de son art et donc d'en faire commerce, rien de mal à ça. Mais de quoi parle-t-on là ? De création. Or, tout ce qui est créé n'est (heureusement) pas vendu. Les dessins des enfants à la maternelle sont protégés par le droit d'auteur au même titre que la dernière bouse auditive qui passe sur les radios. L'un est vendu, l'autre non. Les licences libres, comme le droit d'auteur, concernent toutes les oeuvres, indépendamment de leur commerce (d'ailleurs, il y a toujours un paragraphe dans les licences pour le dire). Et inutile de dire que les oeuvres qui font l'objet d'un commerce sont ultra-minoritaire par rapport à tout ce qui est protégé par le droit d'auteur.
Associer de telle manière création et commerce revient à dire, peu ou prou, que toute création doit être rémunéré, ce qui est assez dangereux à mon sens et risque justement de tuer la création. Car la création risque d'être guidée uniquement par des aspects commerciaux et pas artistique (et on y est déjà dans l'industrie musicale, inutile de l'étendre). On peut se poser légitimement la question de la rémunération des artistes, le livre y répond en partie. Mais faire croire qu'avec des licences qui permettent la diffusion et en associant systématiquement création et commerce, on va améliorer la création, j'ai un gros doute.
# Pour ceux qui se poseraient la question...
Posté par rewind (Mastodon) . En réponse à la dépêche Manifeste pour une Création Artistique Libre par Roberto Di Cosmo. Évalué à 1.
Le bouquin n'est (doublement) pas libre : CC-BY-NC-ND.
[^] # Re: Position de combats
Posté par rewind (Mastodon) . En réponse au journal L'engagement de Red Hat envers l'open source. Évalué à 10.
Il n'y a pas de suceurs, il est possible de le faire, et ils le font. C'est même dans l'esprit du libre que plein de boites puissent fournir du support pour le même logiciel, parce qu'elles peuvent l'étudier, le modifier, etc (4 libertés toussa). Et si des boîtes ont un mauvais support ou n'apporte aucune valeur ajoutée (RH y compris), elles sont remplacées par d'autres plus compétentes. Que je sache, RH n'a pas codé tous les logiciels qu'ils distribuent. Si tout le monde agissait comme eux, on s'en sortirait pas. RH pense peut-être qu'avec du marketting, on peut rester premier. Dans le propriétaire oui (Apple, MS), mais dans le libre non.
[^] # Re: Marrant
Posté par rewind (Mastodon) . En réponse au journal L'engagement de Red Hat envers l'open source. Évalué à 6.
It's not a problem, it's a feature.
Sérieusement, ça fait partie du jeu du libre. S'ils ne sont pas content, ils laissent tous les softs dont eux profitent également et ils retournent faire du propriétaire. Pas sûr qu'ils y gagnent vraiment.
[^] # Re: Pb franco-français ?
Posté par rewind (Mastodon) . En réponse au journal Les SSII, précurseurs d'un modèle social. Évalué à 5.
Deux choses :
[^] # Re: 10, 20, etc
Posté par rewind (Mastodon) . En réponse à l’entrée du suivi 20 journaux/dépêche/suivi/etc sur la page d'accueil plutôt que 10. Évalué à 2 (+0/-0).
Je ne pense pas. On en avait combien sur l'ancien site ? Une vingtaine je pense, en tout cas plus que maintenant. Et vu que la version RoR semble plus rapide, ça ne devrait pas poser de problème.
Au pire (mais ça demande plus de boulot), on laisse 10 par défaut pour le visiteur et on met une option pour les utilisateurs enregistrés (quand je dis "on", je veux bien sûr dire "notre maître codeur préféré").
[^] # Re: Pb franco-français ?
Posté par rewind (Mastodon) . En réponse au journal Les SSII, précurseurs d'un modèle social. Évalué à 3.
Donc selon toi, ce que tu appelles "l'extrême gauche" doit se contenter de dire amen au programme du PS et ne pas présenter de candidat quand bien même le programme du PS n'avait rien de socialiste (dixit celui qui le portait) ? C'est n'importe quoi...
On t'explique que le PS n'a pas réussi à convaincre les électeurs de voter pour lui parce qu'il avait un programme pourri et toi, tu nous expliques que "l'extrême gauche" n'avait qu'à se ranger derrière ce programme pourri quand même. Vraiment, il y a des raisonnements qui me dépassent...
[^] # Re: Précariat
Posté par rewind (Mastodon) . En réponse au journal Les SSII, précurseurs d'un modèle social. Évalué à 6.
Enfin bon, faut arrêter de généraliser à tout va. Ce n'est pas "les grecs" qui ont foutu le merdier, c'est surtout le gouvernement de droite qui a maquillé les comptes, bien aidé en cela par Goldman Sachs (toujours dans les coups merdiques, mais pourquoi les É-U les ont pas laissé crever...) [1]. Du coup, à l'alternance, ça s'est vu.
Deuxième point, le problème n'est pas qu'ils aient trop emprunté (ils sont dans le haut du classement en % du PIB mais derrière l'Italie à qui on ne va pas chercher des poux). Et en plus, complètement ridicule en valeur absolue par rapport au PIB de l'UE. En plus, ils avaient une croissance remarquable jusqu'en 2008 (entre 3.5 et 4.7% entre 2003 et 2008, à faire rêver n'importe quel ministre de l'économie français). Non, ce qui pêchait, c'était les taux d'intérêt usurier auquel on leur prêtait. Et ça, ça ne vient pas de la nature ni de la main invisible du marché, ce sont des décisions politiques qui en sont à la base, ça vient de l'obsession allemande d'empêcher les états d'emprunter directement à la BCE au taux de 1% (actuellement) et de devoir passer par des banques à 3-5% pour les chanceux, et 15-20% pour la Grèce au plus fort... On est les seuls couillons au monde à le faire : ni les É-U, ni le Japon, ni la Chine ne le font. Mais nous si.
Alors je veux bien que tu m'expliques que tous les grecs sont des cons, fraudeurs et militaristes. N'empêche que le contexte européen, ça ne les a pas aidé. Et le FMI qui est passé par derrière pour expliquer que c'était pas les gentilles banques qui réclamaient beaucoup (dont Goldman Sachs, pour la touche d'humour) mais que c'est les grecs qui avaient trop dépensé... Mouhahahaha.