Pour moi le fait que RHEL 7 utilise la version "classique" de GNOME 3, ça prouve déjà qu'il est possible d'avoir plusieurs expériences utilisateur avec GNOME 3. De plus il existe un grand nombre d'extension pour le personnaliser et atténuer ses supposés défauts.
J'ai un peu trainé les pieds avant de passer à GNOME 3, mais depuis que je m'y suis mis et que je reviens sous un GNOME 2 et bien je ne le trouve plus aussi sympatique.
C'est visiblement très à la mode de faire du Gtk/GNOME bashing, mais il ne faut pas confondre ses désires et la réalité.
Ce gâchis ? soyons sérieux… Vous pouvez ne pas aimer Gtk+ (voir le détester) sans être obliger d'en faire des caisses.
Je ne comprends pas votre raisonnement. A vous lire on a l'impression que Gtk+/GNOME est responsable de l'échec et de la fragmentation du Bureau Linux.
Si depuis des années, Qt est libre et que KDE n'ai pas parvenu à (clairement) s'imposer face au bureau GNOME, il faut peut-être en tirer la conclusion qui est que, GNOME a lui aussi ses avantages et qu'il convient mieux à certains utilisateurs et (soyons fou) que Gtk+ convient mieux à certains développeurs aussi.
On peut regretter plein de chose, mais l'écosystème Gtk/GNOME ne doit pas être le bouc émissaire de l'échec de Linux sur le desktop.
Ca ne te dérange pas, tu trouves que donner le pouvoir à une seule entreprise n'est pas génant, soit.
C'est sympa de débattre avec toi! J'avais peur d'extrapoler tes propos mais toi tu n'y va pas avec le dos de la cuillère ;)
Si la question est: "Est-ce que tu préfère un système de gouvernance ouverte ou un système contrôlé d'une main de fer par une entreprise ?"
Je préfère une gouvernance ouverte… Mais là on est pas en train de comparer deux projets libres on compare 2 codecs vidéo. Un est "contrôlé" par la MPEG LA, l'autre par Google. Force est de constater que sur ces deux codecs l'un est plus contraignant pour le logiciel libre que l'autre.
Cela n'est pas faire allégeance à Google que de le reconnaître. Si par la suite VP10 est soumis à des royalties et qu'il est en concurrence avec h265+ et bien le débat aura lieu sur un autre terrain que celui de liberté.
Bah… La drogue, c'est toujours la même façon d'amener les nouveaux drogués : la première (et deuxième) dose est gratuite. Ca fonctionne comme ça depuis… Longtemps.
Je tiens à signaler que je ne le diabolise pas
Je ne veux pas faire d'extrapolation hâtive, mais comparer VP8/VP9 à des drogues, j'appelle ça de la diabolisation.
A cause des royalties relative à H264, Mozilla n'a jamais pu implémenté directement ce codec dans Firefox. Implémenté H264 via x264 dans Firefox n'aurai en effet pas exempté Mozilla de passer à la caisse. La solution d'utiliser le codec "indirectement" si il est présent sur le système ne fait que déplacer cette problématique de royalties.
La situation est quand même différente avec VP8 et VP9 où la distribution est libre (par son implémentation) et sans royalties. Ce qui n'est pas le cas x264 et/ou OpenH264 (*).
D'un point de vue des libertés VP9 me semble donc moins contraignant que H265.
De toute façon, l'industrie va choisir pour nous.
(Cisco paye et distribue, mais tu ne peux pas le distribuer toi-même directement)
Je crois qu'il ne faut ni faire trop de prosélytisme, ni diaboliser VP9 (pour le moment).
Comme le dit l'expression "Faute de grives, on mangera des merles". J'entends donc les arguments de Zenitram (sur la liberté, les specs et les brevets), en revanche il me semble que si demain VP9 venait à s'imposer face à h265 la distribution de ce codec serait quand même, plus simple pour les projets libres.
L'initiative de Cisco et de Mozilla avec OpenH264, nous montre bien a quel point il est compliqué de distribuer "légalement" H264 pour un logiciel libre.
De plus la guéguerre entre Motorola et Microsoft sur H264 nous montre aussi que même sous l'égide d'un consortium d'entreprise, comme l'est la MPEG LA, ont pas à l’abri du procès donc…
Alors, bien sûr que Google n'est pas philanthrope, bien sûr qu'il ne faut pas être naïf et rester méfiant. Mais le fait que Google propose une implémentation libre et sans royalties de son codec, ça n'est quand même pas une si mauvaise nouvelle, non ?
C'est un petit peu la "norme" dans se genre de "petit litige" où il est plus facile de montrer les dents d'entrée pour essayer d'obtenir rapidement un résultat que de rentrer vraiment dans une procédure plus sérieuse.
J'ai l'impression que cette histoire a été traité avec pas mal de légèreté et que le cabinet d'avocat n'a simplement pas joué son rôle de conseil par une forme de méconnaissance de l’environnement Internet.
Après je crois qu'il ne faut pas non plus s'étonner qu'il n'est pas de beaucoup plus de remous, la faute si elle existe n'est pas non plus extra-ordinaire.
Je trouve que LinuxFR a parfaitement réagi, sans se laisser faire et est allé au bout de la démarche en prouvant simplement qu'eux aussi était capable de faire un courrier en y incluant des références juridiques. Je trouve que la réponse est proportionné et suffisante.
Il faut voir le "bad buzz" autour de cette histoire que se soit pour Linkeo et pour le cabinet d'avocats comme une forme de réparation.
Pour moi LinuxFR peut sortir la tête haute de cette histoire (ce qui n'est pas le cas des autres protagonistes). J'espère simplement que ça puisse d'un coté servir de leçon à certaines sociétés et certains avocats un peu trop zélés ainsi que à d'autres sites ou assoc qui pourraient se retrouver dans se genre de situation.
Le fait qu'il faille les modifier est une chose, mais le fait que les informations par défaut soit un compte Gmail (qui il me semble est valide) peut faire penser à un oublie.
Le port de l'interface graphique de Gtk vers Qt signifiera-t'il l'arrêt pure et simple des développements sur l'interface Gtk ou il y'aura-t'il simplement moyen de choisir entre les deux toolkit ?
C'est assez surprenant venant d'une agence web (qui est donc censé bien connaitre le web et ses utilisateurs) de faire une telle erreur de communication.
Rajoutez à cela, ce que l'on peut qualifier comme, une demande de "rançon" par intimidation contre l'un des sites les plus consultés par les adminsys UNIX/Linux francophone, personnellement j'appelle cela faire: "tout faux".
Je crois que la réputation sur Internet ne se gagne pas devant un tribunal (même avec un super avocat), mais certains semble penser le contraire.
Outre le fait que se soit un très gros chantier que de changer de Toolkit en cours de route, il me semble que pour sa version en ligne, les développeurs LibreOffice, mise beaucoup sur le backend "broadway" de Gtk+.
Leur toolkit utilise Gtk, comme le fait Mozilla avec ses produits sous Linux. Tout n'est pas parfait, mais ça à le mérite de fonctionner, donc pourquoi changer ?
Ça voudrait dire, à terme, déprécier g_signal_connect dans Gtk+ ?
Si c'est le cas ça va être un sacré boulot. Autrement plus compliqué que de passer de Gtk2 > Gtk3 et pourtant ça traîne encore un peu les pâtes avec les projets "externes" à GNOME.
En ce qui concerne le langage "par défaut" du projet, j'aurais aimé qu'ils orientent vers C/Vala/Python. Mais bon Javascript pourquoi pas.
J'imagine que ce choix, va à l'avenir permettre à GNOME de proposer plus facilement leur "Market" où nous pourrons installer/déinstaller/mettre à jour nos GNOME Apps ?
Si c'est le cas alors Javascript trouve ici un grand intérêt car indépendant de l'architecture cliente (ARM, x86 etc..), et sans les nombreux modules Python qui pourraient ne pas être installés sur la machine (bien que la constitution d'un SDK Python eût été envisageable aussi).
Bref ça semble être le début d'un gros chantier, en espérant que ça donne au final un beau bâtiment :)
Je ne comprend pas trop comment tu peux voir dans GNU une cohérence vu qu'un gros bloc du système (un noyau, c'est pas n'importe quoi quand même) est maintenu par un mec qui n'a rien à foutre de GNU. Bref, pas crédible.
Oui enfin moi tous les jours j'utilise un ensemble d'outils, un shell, un éditeur de texte, bref se que certains peuvent appeler un userland GNU (et d'autres outils bien sûr, là n'est pas la question) et que il se trouve que le noyau Linux permet qu'ils fonctionnent. Après que se soit le noyau Debian, CentOS ou autres ce qui m'intéresse c'est que les outils que j'utilise fonctionne et soit un minimum cohérent. Le fait que les coreutils et GNU Sed partage certains arguments (--help, --version etc …) je trouve ça bien par exemple.
Ca reste à prouver : la nature a horreur du vide, et comme le dit la dépêche, des gens ont l'air de penser que GNU apporte plus d'inconvénients au projet que d'avantages.
Oui enfin ça n'est pas lié au projet GNU. Certains ne voient jamais leurs contributions arriver dans le noyau Linux et vont tenir le même discours à l'encontre de Linus.
Après est-ce que RMS fait les bons ou les mauvais choix pour le projet GNU ? C'est un autre débat.
Mais le fait que le projet GNU soit un élément très important de l'écosystème Linux et que sa mort soit dommageable, ça me parait évident et crédible ;)
Pour répondre à la question pausé dans la dépêche. Je pense que la mort(ou la longue déconfiture) du projet GNU serait évidement très dommageable. Un projet de ce type est une bonne chose. Une sorte de "gage qualité" et "d'uniformité" entre les différentes briques. Ce qui permet au final d'avoir un système cohérent.
Maintenant est-ce que RMS à raison, quand il refuse que certain outils soit recordé en C++ par exemple, c'est plus difficile pour moi de me faire un avis là dessus.
J'ai globalement une préférence pour le C, mais je préfère qu'un outil soit ré-écrit en C++ et qu'il continue d'évoluer, que le même outil en C devenu trop compliqué à maintenir et qui ne reçoit plus que des correctifs mineurs.
L'idéal serait bien évidement un outils en C qui évolue et qui est simple à maintenir, mais bon Noël ne tombe qu'une fois par an :)
J'ajoute que le client Spicy de mon dépôt n'est utile que pour avoir un moyen de visualiser ce que donne spice. Pour le reste sachant que j'ai déactiver pas mal de choses tu ne profitera pas pleinement de l' "expérience" (usbredirect notamment). Il est donc préférable d'utiliser les outils fournit par Cloonix.
En tous cas Spice est très prometteur, j'attends la gestion multi-utilisateur avec impatience.
J'ai fait un package de spicy pour Squeeze, un espèce de "backport" du paquet Wheezy et en déactivant les choses qui pausaient des problèmes de dépendances sous Squeeze (usbredirect etc..).
Sur le screenshot de libreforce, c'est plutôt réussi je trouve. Par contre la barre de menu… qu'est-ce que ça fait vieillot!!! (on se croiraient en 2011 !!!! niark niark niark). (désolé je voulais pas attendre vendredi :/)
J'ai quand même hâte de voir Autralis pour Firefox, car les mockups étaient assez bien.
[^] # Re: Gnome 3
Posté par david.g . En réponse à la dépêche Red Hat Enterprise Linux 7. Évalué à 1.
D'après Phoronix il serait sous GNOME 3.
Pour moi le fait que RHEL 7 utilise la version "classique" de GNOME 3, ça prouve déjà qu'il est possible d'avoir plusieurs expériences utilisateur avec GNOME 3. De plus il existe un grand nombre d'extension pour le personnaliser et atténuer ses supposés défauts.
J'ai un peu trainé les pieds avant de passer à GNOME 3, mais depuis que je m'y suis mis et que je reviens sous un GNOME 2 et bien je ne le trouve plus aussi sympatique.
C'est visiblement très à la mode de faire du Gtk/GNOME bashing, mais il ne faut pas confondre ses désires et la réalité.
[^] # Re: Uchronie
Posté par david.g . En réponse au journal Gtk to Qt - A strange journey. Évalué à 10.
Ce gâchis ? soyons sérieux… Vous pouvez ne pas aimer Gtk+ (voir le détester) sans être obliger d'en faire des caisses.
Je ne comprends pas votre raisonnement. A vous lire on a l'impression que Gtk+/GNOME est responsable de l'échec et de la fragmentation du Bureau Linux.
Si depuis des années, Qt est libre et que KDE n'ai pas parvenu à (clairement) s'imposer face au bureau GNOME, il faut peut-être en tirer la conclusion qui est que, GNOME a lui aussi ses avantages et qu'il convient mieux à certains utilisateurs et (soyons fou) que Gtk+ convient mieux à certains développeurs aussi.
On peut regretter plein de chose, mais l'écosystème Gtk/GNOME ne doit pas être le bouc émissaire de l'échec de Linux sur le desktop.
[^] # Re: google
Posté par david.g . En réponse au journal Le Codec VP9 reçoit le soutien de l'industrie.. Évalué à 6. Dernière modification le 05 janvier 2014 à 22:20.
C'est sympa de débattre avec toi! J'avais peur d'extrapoler tes propos mais toi tu n'y va pas avec le dos de la cuillère ;)
Si la question est: "Est-ce que tu préfère un système de gouvernance ouverte ou un système contrôlé d'une main de fer par une entreprise ?"
Je préfère une gouvernance ouverte… Mais là on est pas en train de comparer deux projets libres on compare 2 codecs vidéo. Un est "contrôlé" par la MPEG LA, l'autre par Google. Force est de constater que sur ces deux codecs l'un est plus contraignant pour le logiciel libre que l'autre.
Cela n'est pas faire allégeance à Google que de le reconnaître. Si par la suite VP10 est soumis à des royalties et qu'il est en concurrence avec h265+ et bien le débat aura lieu sur un autre terrain que celui de liberté.
[^] # Re: google
Posté par david.g . En réponse au journal Le Codec VP9 reçoit le soutien de l'industrie.. Évalué à 6.
Je ne veux pas faire d'extrapolation hâtive, mais comparer VP8/VP9 à des drogues, j'appelle ça de la diabolisation.
A cause des royalties relative à H264, Mozilla n'a jamais pu implémenté directement ce codec dans Firefox. Implémenté H264 via x264 dans Firefox n'aurai en effet pas exempté Mozilla de passer à la caisse. La solution d'utiliser le codec "indirectement" si il est présent sur le système ne fait que déplacer cette problématique de royalties.
La situation est quand même différente avec VP8 et VP9 où la distribution est libre (par son implémentation) et sans royalties. Ce qui n'est pas le cas x264 et/ou OpenH264 (*).
D'un point de vue des libertés VP9 me semble donc moins contraignant que H265.
De toute façon, l'industrie va choisir pour nous.
[^] # Re: google
Posté par david.g . En réponse au journal Le Codec VP9 reçoit le soutien de l'industrie.. Évalué à 5. Dernière modification le 05 janvier 2014 à 17:09.
Je crois qu'il ne faut ni faire trop de prosélytisme, ni diaboliser VP9 (pour le moment).
Comme le dit l'expression "Faute de grives, on mangera des merles". J'entends donc les arguments de Zenitram (sur la liberté, les specs et les brevets), en revanche il me semble que si demain VP9 venait à s'imposer face à h265 la distribution de ce codec serait quand même, plus simple pour les projets libres.
L'initiative de Cisco et de Mozilla avec OpenH264, nous montre bien a quel point il est compliqué de distribuer "légalement" H264 pour un logiciel libre.
De plus la guéguerre entre Motorola et Microsoft sur H264 nous montre aussi que même sous l'égide d'un consortium d'entreprise, comme l'est la MPEG LA, ont pas à l’abri du procès donc…
Alors, bien sûr que Google n'est pas philanthrope, bien sûr qu'il ne faut pas être naïf et rester méfiant. Mais le fait que Google propose une implémentation libre et sans royalties de son codec, ça n'est quand même pas une si mauvaise nouvelle, non ?
# La page a changé.
Posté par david.g . En réponse au journal SaaS vs Open Source: WiziShop a tout compris.. Évalué à 3. Dernière modification le 25 novembre 2013 à 11:52.
Entre temps ils ont changés la page! On nous observe :)
# Correction.
Posté par david.g . En réponse au journal SaaS vs Open Source: WiziShop a tout compris.. Évalué à 3. Dernière modification le 24 novembre 2013 à 13:41.
Est-il possible à un admin de corriger les deux très vilaines fautes dans le titre du journal ?
-à+a -tous+tout
Je n'ai jamais été très fort avec l'orthographe, mais là je me suis surpassé :/
Merci.
[^] # Re: malheureuses récentes transitions
Posté par david.g . En réponse à la dépêche GTK+ 3 disponible officiellement pour Win32 !. Évalué à 10. Dernière modification le 28 octobre 2013 à 20:18.
Si certains pouvaient s'en "contre ficher" sans se sentir obliger de nous en faire part ;).
En tous cas c'est une bonne nouvelle et je sais que Tarnyko a travaillé pour que ses binaires arrive enfin sur le site officiel :) (Bravo et merci).
On peut lui trouver tout les défauts du monde je maintiens des applications Gtk+ Windows/Linux et je ne suis pas "maso".
[^] # Re: Si je comprends bien...
Posté par david.g . En réponse à la dépêche Mise en demeure, suite et fin. Évalué à 10. Dernière modification le 25 octobre 2013 à 18:57.
Salut,
C'est un petit peu la "norme" dans se genre de "petit litige" où il est plus facile de montrer les dents d'entrée pour essayer d'obtenir rapidement un résultat que de rentrer vraiment dans une procédure plus sérieuse.
J'ai l'impression que cette histoire a été traité avec pas mal de légèreté et que le cabinet d'avocat n'a simplement pas joué son rôle de conseil par une forme de méconnaissance de l’environnement Internet.
Après je crois qu'il ne faut pas non plus s'étonner qu'il n'est pas de beaucoup plus de remous, la faute si elle existe n'est pas non plus extra-ordinaire.
Je trouve que LinuxFR a parfaitement réagi, sans se laisser faire et est allé au bout de la démarche en prouvant simplement qu'eux aussi était capable de faire un courrier en y incluant des références juridiques. Je trouve que la réponse est proportionné et suffisante.
Il faut voir le "bad buzz" autour de cette histoire que se soit pour Linkeo et pour le cabinet d'avocats comme une forme de réparation.
Pour moi LinuxFR peut sortir la tête haute de cette histoire (ce qui n'est pas le cas des autres protagonistes). J'espère simplement que ça puisse d'un coté servir de leçon à certaines sociétés et certains avocats un peu trop zélés ainsi que à d'autres sites ou assoc qui pourraient se retrouver dans se genre de situation.
[^] # Re: 2 questions
Posté par david.g . En réponse à la dépêche GooglePlayDownloader : télécharger les APK sans rien demander à Google. Évalué à 2. Dernière modification le 20 août 2013 à 17:17.
Dans se cas là, mea culpa :)
Cependant, Google risque de bloquer le compte assez rapidement.
[^] # Re: 2 questions
Posté par david.g . En réponse à la dépêche GooglePlayDownloader : télécharger les APK sans rien demander à Google. Évalué à 1.
Le fait qu'il faille les modifier est une chose, mais le fait que les informations par défaut soit un compte Gmail (qui il me semble est valide) peut faire penser à un oublie.
[^] # Re: 2 questions
Posté par david.g . En réponse à la dépêche GooglePlayDownloader : télécharger les APK sans rien demander à Google. Évalué à 8.
Salut,
Je ne sais pas si c'est volontaire ou pas mais on trouve vos identifiants dans le code source de l'application. Il semble qu'ils soient valide.
https://codingteam.net/project/googleplaydownloader/browse/googleplaydownloader.py
# Interface graphique.
Posté par david.g . En réponse à la dépêche Wireshark 1.10. Évalué à 5.
Le port de l'interface graphique de Gtk vers Qt signifiera-t'il l'arrêt pure et simple des développements sur l'interface Gtk ou il y'aura-t'il simplement moyen de choisir entre les deux toolkit ?
[^] # Re: Triste
Posté par david.g . En réponse à la dépêche Première mise en demeure pour l'association LinuxFr. Évalué à 5.
C'est quoi l'expression déjà ? Ah oui:
"Qui sème le vent récolte la tempête!"
[^] # Re: Triste
Posté par david.g . En réponse à la dépêche Première mise en demeure pour l'association LinuxFr. Évalué à 10. Dernière modification le 01 juin 2013 à 00:09.
C'est assez surprenant venant d'une agence web (qui est donc censé bien connaitre le web et ses utilisateurs) de faire une telle erreur de communication.
Rajoutez à cela, ce que l'on peut qualifier comme, une demande de "rançon" par intimidation contre l'un des sites les plus consultés par les adminsys UNIX/Linux francophone, personnellement j'appelle cela faire: "tout faux".
Je crois que la réputation sur Internet ne se gagne pas devant un tribunal (même avec un super avocat), mais certains semble penser le contraire.
[^] # Re: Pousser le concept ?
Posté par david.g . En réponse à la dépêche GNOME offre un service ownCloud à ses développeurs. Évalué à 5.
Ce serait super, la synchronisation avec OwnCloud. Est-ce que tu peux nous renvoyer vers la page de wiki en question ?
# Pour rester dans l'esprit.
Posté par david.g . En réponse à la dépêche Un fonds qatari entre au capital de Red Hat. Évalué à 3.
Bonsoir à tous,
Dans la catégorie libre et 1er Avril il y'a aussi Mandriva qui se lance dans la F1 .
http://blog.mandriva.com/fr/2013/04/01/formule1-3/
Et vous qu'avez vous péché de beau aujourd'hui ?
[^] # Re: Pourquoi VCL et automake ?
Posté par david.g . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à 3.
Outre le fait que se soit un très gros chantier que de changer de Toolkit en cours de route, il me semble que pour sa version en ligne, les développeurs LibreOffice, mise beaucoup sur le backend "broadway" de Gtk+.
Leur toolkit utilise Gtk, comme le fait Mozilla avec ses produits sous Linux. Tout n'est pas parfait, mais ça à le mérite de fonctionner, donc pourquoi changer ?
[^] # Re: QML bis?
Posté par david.g . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 2.
Ça voudrait dire, à terme, déprécier g_signal_connect dans Gtk+ ?
Si c'est le cas ça va être un sacré boulot. Autrement plus compliqué que de passer de Gtk2 > Gtk3 et pourtant ça traîne encore un peu les pâtes avec les projets "externes" à GNOME.
En ce qui concerne le langage "par défaut" du projet, j'aurais aimé qu'ils orientent vers C/Vala/Python. Mais bon Javascript pourquoi pas.
J'imagine que ce choix, va à l'avenir permettre à GNOME de proposer plus facilement leur "Market" où nous pourrons installer/déinstaller/mettre à jour nos GNOME Apps ?
Si c'est le cas alors Javascript trouve ici un grand intérêt car indépendant de l'architecture cliente (ARM, x86 etc..), et sans les nombreux modules Python qui pourraient ne pas être installés sur la machine (bien que la constitution d'un SDK Python eût été envisageable aussi).
Bref ça semble être le début d'un gros chantier, en espérant que ça donne au final un beau bâtiment :)
[^] # Re: Les compétences de Stallman
Posté par david.g . En réponse à la dépêche Grabuge à la FSF : GnuTLS quitte le projet GNU et sed et grep perdent leur mainteneur. Évalué à 6.
Oui enfin moi tous les jours j'utilise un ensemble d'outils, un shell, un éditeur de texte, bref se que certains peuvent appeler un userland GNU (et d'autres outils bien sûr, là n'est pas la question) et que il se trouve que le noyau Linux permet qu'ils fonctionnent. Après que se soit le noyau Debian, CentOS ou autres ce qui m'intéresse c'est que les outils que j'utilise fonctionne et soit un minimum cohérent. Le fait que les coreutils et GNU Sed partage certains arguments (--help, --version etc …) je trouve ça bien par exemple.
Oui enfin ça n'est pas lié au projet GNU. Certains ne voient jamais leurs contributions arriver dans le noyau Linux et vont tenir le même discours à l'encontre de Linus.
Après est-ce que RMS fait les bons ou les mauvais choix pour le projet GNU ? C'est un autre débat.
Mais le fait que le projet GNU soit un élément très important de l'écosystème Linux et que sa mort soit dommageable, ça me parait évident et crédible ;)
[^] # Re: Les compétences de Stallman
Posté par david.g . En réponse à la dépêche Grabuge à la FSF : GnuTLS quitte le projet GNU et sed et grep perdent leur mainteneur. Évalué à 8. Dernière modification le 24 décembre 2012 à 17:15.
Pour répondre à la question pausé dans la dépêche. Je pense que la mort(ou la longue déconfiture) du projet GNU serait évidement très dommageable. Un projet de ce type est une bonne chose. Une sorte de "gage qualité" et "d'uniformité" entre les différentes briques. Ce qui permet au final d'avoir un système cohérent.
Maintenant est-ce que RMS à raison, quand il refuse que certain outils soit recordé en C++ par exemple, c'est plus difficile pour moi de me faire un avis là dessus.
J'ai globalement une préférence pour le C, mais je préfère qu'un outil soit ré-écrit en C++ et qu'il continue d'évoluer, que le même outil en C devenu trop compliqué à maintenir et qui ne reçoit plus que des correctifs mineurs.
L'idéal serait bien évidement un outils en C qui évolue et qui est simple à maintenir, mais bon Noël ne tombe qu'une fois par an :)
Joyeuses fêtes!
[^] # Re: Paquets
Posté par david.g . En réponse à la dépêche Virtualisation avec bureau SPICE. Évalué à 1.
J'ajoute que le client Spicy de mon dépôt n'est utile que pour avoir un moyen de visualiser ce que donne spice. Pour le reste sachant que j'ai déactiver pas mal de choses tu ne profitera pas pleinement de l' "expérience" (usbredirect notamment). Il est donc préférable d'utiliser les outils fournit par Cloonix.
En tous cas Spice est très prometteur, j'attends la gestion multi-utilisateur avec impatience.
[^] # Re: Paquets
Posté par david.g . En réponse à la dépêche Virtualisation avec bureau SPICE. Évalué à 3. Dernière modification le 31 octobre 2012 à 22:03.
J'ai fait un package de spicy pour Squeeze, un espèce de "backport" du paquet Wheezy et en déactivant les choses qui pausaient des problèmes de dépendances sous Squeeze (usbredirect etc..).
http://deb.accelance.net/debian/pool/main/s/spice-gtk/
http://deb.accelance.net/sources/spice-gtk_0.12-5~bpo60+1.debian.tar.gz
[^] # Re: Pétard mouillé
Posté par david.g . En réponse à la dépêche Broadcom libère la pile graphique du Raspberry Pi. Évalué à 1.
Je suis d'accord avec ton constat, mais sans suivre la LWN, existe t'il une autre alternative plus "fiable" ?
ArsTechnica est tombé de le panneau les deux pieds en avant.
H-Online attire le lecteur avec un titre racoleur, ensuite l'article est de meilleur qualité et nous parle du firmware "closed source", mais bon.
Je suis toujours à la recherche d'un site dans la veine de Phoronix, mais sans les saucisses, existe-t'il ?
[^] # Re: Australis
Posté par david.g . En réponse à la dépêche Firefox et Thunderbird : appelez le 15. Évalué à 0. Dernière modification le 29 août 2012 à 20:42.
Sur le screenshot de libreforce, c'est plutôt réussi je trouve. Par contre la barre de menu… qu'est-ce que ça fait vieillot!!! (on se croiraient en 2011 !!!! niark niark niark). (désolé je voulais pas attendre vendredi :/)
J'ai quand même hâte de voir Autralis pour Firefox, car les mockups étaient assez bien.