En fait, emerge/portage est en partie utilisable tel quel sur d'autres distribs, si ce que l'on veut c'est juste compiler à l'occasion un paquet depuis un ebuild.
Tu peux voir (en vraiment très très gros) la bête comme divisée en 2 couches :
- l'une, emerge lui même, en pur Python, fait un peu office d'apt-get et autres urpmi (principalement de la gestion de dépendances donc). Ça n'a pas vraiment d'intérêt si ça n'est pas pour gérer l'ensemble du système (ou au moins une large partie comme dans le cas de gentoo/macosx) ;
- l'autre, en Bash et Python, fait plutôt office de dpkg et autres rpm, c'est à dire gère la compilation et installation d'un ebuild particulier, indépendament du reste du système. Le gentooiste moyen n'en fera pas un usage direct en général, mais c'est pourtant possible avec la commande "ebuild".
C'est cette 2ème partie qui elle est utilisable en l'état à peu près n'importe où. Elle offre toute la collection de fonctions et scripts Bash qui rendent si agréable l'écriture des ebuilds, une méthode d'installation/désinstallation des paquets, etc. Bon maintenant, bien sûr, l'utilisation de certains des ebuilds Gentoo sur une autre distrib posera des problèmes (si par exemple ils utilisent des outils maison fournis par d'autres paquets, etc.). Mais dans pas mal de cas, pour peut que tu te dépatouille pour satisfaire les dépendances "à la main", ça devrait pas mal marcher. En utilisant la variable ROOT="/là/où/tu/veux", tu devrais même pouvoir éviter les mélanges malheureux avec ton système standard.
Oui et non, ça dépend de ce que tu fais avec... Avec un peu d'effort, tu peux te faire un firewall Gentoo sur un flash disk de 64Mo. Et le LiveCD "minimal" est aussi une Gentoo, de 60Mo... Quant à l'utilisation "Desktop", bah... installée depuis des paquets GRP, tu as déjà une distrib assez complète dans ~1Go. Enfin bref, la partie "logiciels+librairies+etc." d'une Gentoo prend une place très variable, et équivalente à ce que prendrait n'importe quelle autre distrib prévue pour le même usage.
Maintenant, là où Gentoo prend de la place en plus, c'est au niveau de la compilation. Sauf à bouger ça sur une autre machine, il faut de l'espace pour :
- télécharger les sources des programmes, et a priori les garder un petit peu pour ne pas avoir à les re-télécharger en cas de révision de l'ebuild. Perso je conserve les sources pour l'ensemble de mon système, et ça fait en gros 2Go (pour quand même pas mal de bazar d'installé...).
- compiler : là c'est d'espace temporaire qu'il s'agit, mais il faut l'avoir quand on en a besoin. Openoffice.org doit être un des paquets les plus gourmants à ce niveau puisque sa compilation peut occuper ~2Go il me semble. Enfin bref, mieux vaut prévoir ~3Go d'espace libre pour laisser enfler et désenfler sont /var/tmp.
Au total donc, oui, pourquoi pas 10 Go, ça parait raisonnable pour être bien à l'aise et voir venir.
> Oui mais ce qui me gène c'est surtout la première install :-/
Une Gentoo n'est pas particulièrement longue à installer. Je me permets de te pointer vers une explication que je donnais pas plus tard qu'hier à un autre futur nouveau sur ce que je pense être la méthode raisonnable pour une installation sans temps mort : http://article.gmane.org/gmane.linux.gentoo.user.french/82(...)
La gentoo de mon portable ne compile que quand je suis devant (parce qu'en veille sinon), et ça ne m'a jamais dérangé pour faire quoi que ce soit. J'ai réglé la valeur de PORTAGE_NICENESS, et puis voilà tout... Et pourtant je tourne en ~arch (testing quoi), avec mise à jour quotidienne par soucis d'exhaustivité de mes tests, donc des compilations, j'en fait en quantité tous les jours.
Dans le genre "présentation depuis un simple texte formaté", il y a MagicPoint, que j'ai vu utilisé au Fosdem par quelques personnes. Ça a ces limites comparé à (par exemple) du Latex/Beamer, mais ça a l'air de bien faire son job pour les besoins simples : http://member.wide.ad.jp/wg/mgp/(...)
Argh, mea maxi culpa, j'y ai pensé un moment pendant la rédaction, et puis j'ai oublié de corriger après. Et pourtant, il est vrai que les trads des docs Gentoo sont de qualité et sont à jour, donc vraiment il n'y a pas de raison de s'en priver.
Je redirige vers nos modéros aux pouvoirs d'édition infinis.
Tiens bah puisqu'on parle documentaires de qualité, si vous tombez sur "The Corporation", et bah je vous le conseille très vivement. C'est une démonstration point par point du caractère psycopathe des grandes sociétés, et vraiment, c'est implacable. Par contre je pense pas qu'il soit encore en salle, ça doit faire genre un mois ou deux que je l'ai vu, mais bon, peut-être en DVD ou assimilé ? http://www.thecorporation.com/(...)
> Je pense qu'il nous faudrait un Eolas pour nous aider a comprendre
> comment ca marche...
Regarde déjà les diverses ressources de Harald Welte (slides, blog, etc.), il explique déjà très bien pas mal de choses (modulo qu'il n'est pas garanti que tout colle à 100% au droit français).
Pourquoi peur ? C'est comme ça que se forme une langue, tout nos mots sont des usages entérinés, certains ils y a des siècles, et d'autres plus récemment. Bien sûr, ça doit se faire avec parcimonie, il ne s'agit pas de valider n'importe quel abus à la mode. Mais là pour le coup je suis plutôt d'accord pour dire que le mot manquait, qu'il n'est pas trop moche, qu'il a une étymologie qui tient la route, donc bref, pourquoi pas...
> C'est un raisonnement valable si le "but" est que linux gagne de la
> popularité auprès des éditeurs. Par contre si le but c'est d'avoir la
> possibilité de tout faire avec des logiciels libres, le portage peut
> avoir des conséquences négatives
Je ne fais pas de l'acceptation de Linux par les éditeurs de proprio un but en soit, et pour moi le but est bien d'aller vers un maximum de libre pour un maximum de gens. Mais je ne crois pas non plus que ça va se faire tant que le clivage entre proprio grand public et libre restera ce qu'il est aujourd'hui. Faudrait pas perdre de vue que la part du proprio dans l'informatique grand public est aujourd'hui de ~95%, et que sa part dans le grand public commercial doit être plus élevée encore. On peut rêver à des lendemains meilleurs, mais ça ne sert à rien si on ne réfléchit pas en termes de transition, si on n'envisage pas les scénarios possibles d'un basculement massif.
C'est avec cette optique que je vois d'un bon oeil la reconnaissance de Linux par les éditeurs de logiciels grand public. Ils sont aujourd'hui presque tous des acteurs du statu quo, parcequ'il vendent du code proprio pour Windows ou MacOS, et qu'ils ont donc intérêt à ce que les systèmes libres restent autant que possible marginaux. Au contraire, ceux qui commencent à éditer aussi leur produits pour Linux deviennent neutres dans la bataille des OS. Ça fait pas beaucoup avancer le schmilblick tu me diras, mais quand même, ça modifie légèrement le rapport de forces en faveur des systèmes libres, parceque c'est autant d'inertie en moins en face. Or sans l'inertie que constitue les applications, les systèmes propriétaires ne seraient plus grand chose, et deviendraient vite marginaux, saugrenus, au mieux un caprice pour quelques nostalgiques fortunés.
Alors tu me diras, avec mon plan, pourtant déjà d'un optimisme à la limite de l'utopie, on arrive à des OS libres pour tous, mais truffés d'applis proprios, et c'est pas terrible. Mais en fait, non, dans mon plan ça ne finit pas comme ça, parcequ'intervient un autre facteur : l'influence vertueuse des systèmes libres sur les éditeurs de proprio. Tous frais débarqués dans un monde nouveau, voilà nos éditeurs qui découvrent d'autres modèles pour le développement et le commerce. C'est par exemple Real qui après avoir livré quelques versions bien proprio et bien pourries de son player se réoriente vers un player essentiellement libre (Helix), et un simple greffon proprio. Je pense qu'en fait la plupart des éditeurs de logiciels ne font pas le choix de leur modèle 100% proprio, mais que simplement ils se conforment à l'existant sans réflechir un instant aux alternatives. Au contact d'un système libre, les voilà forcés de constater que d'autres modèles existent, et qu'ils peuvent par exemple avoir intérêt à fournir un logiciel essentiellement libre et ne vendre que des extensions sous forme propriétaire, ou bien à s'orienter plus vers du service, etc. Les voilà aussi confrontés à une concurrence qu'ils ne pourront de toute façon jamais complètement étoufer, et qui abandonnent donc leurs ambitions de monopôle pour viser plutôt à avoir juste leur place dans un monde ou le choix prime, acceptant ainsi l'indispensable ouverture des formats de leurs fichiers parceque sans intéropérabilité ils se marginaliseraient.
Ouais, bon, je rêve ? Oui, un peu, mais parmis les rêves ambitieux, celui d'une informatique essentiellement libre dans laquelle les éditeurs de proprio existants trouveraient quand même leur place me parait être le moins inaccessible. Nous ne sommes pas en position de gagner une guerre frontale du 100% libre contre le 100% proprio, et c'est pas de passer nos grand-mères sous Mandrake qui va suffir à changer ça. Voilà, en gros, ma position...
> Chouette, Nero sous Linux, on va enfin pouvoir se passer des outils
> libres !
Perso je suis comme à peu près tout le monde ici je pense, j'ai ai rien à foutre de ce logiciel en particulier, je l'utiliserai pas, je l'essaierai même pas, et je suis plutôt content des outils libres (modulo que j'aimerai bien voir libburn avancer un peu plus vite, mais bon, je vais pas me plaindre, je n'y contribue pas non plus).
Cependant, je prends cette release comme une bonne nouvelle, parceque je considère que chaque portage d'un soft proprio grand public vers Linux est un signe supplémentaire que petit à petit, l'oiseau fait son nid. J'ai la même impression quand je vois par exemple portés des jeux 3D-qui-passeront-pas-sur-mon-ati7500, j'me dis que c'est pas pour moi, mais que c'est positif quand même.
En fait, je préfère je crois ces niouzes "soft proprio débarque sur système libre" à celles "soft libre débarque sur système proprio", je les trouve de meilleure augure.
Argh, bon, ça se complique alors. Enfin moi ce que j'ai remarqué sous Gentoo c'est que Gnome 2.10 utilise un certain Howl qui vient de là : http://www.porchdogsoft.com/products/howl/(...)
Et que KDE 3.4 lui utilisera un mDNSResponder qui vient de là : http://developer.apple.com/macosx/rendezvous/(...)
Mais j'avoue n'avoir pas regardé ça de plus près pour voir si l'un était forké de l'autre ou quoi, ou bien si c'était même carrement le même soft.
Ah oui, exact. Et par contre il me semble qu'ils ne se basent pas sur la même implèm' (howl pour Gnome et mDNSResponder pour KDE je crois), à moins que ça ne soit une spécificité de Gentoo ça.
Niveau utilité, j'imagine assez bien que ça pourrait avoir un intérêt pour les vues du style 'network:///', mais à part ça je vois pas trop non plus, d'où ma curiosité.
Je vois qu'est apparu à droite à gauche dans cette release le support de Rendez-Vous, enfin de howl, enfin du DNS Service Discovery, enfin de je sais pas trop quoi je m'y perds un peu. Concrètement, y'en a-t-il parmis vous qui ont déjà joué avec ça, et qui auraient des expériences à partager ?
> L'atout de ces nouveaux noyaux 2.6.Y.Z c'est qu'on y trouve les
> corrections de trous de sécurité et les bugfix [...]
Non, on n'est pas certain du tout d'y trouver tous les correctifs, même de sécurité. Il est clairement annoncé que si une faille connue n'a pas de fix suffisament concis et évident, alors elle restera ouverte dans les 2.6.x.y. Dans les -ac, l'objectif est plus de fermer la faille à tout prix, quitte à ce que ce soit fait de façon un peu crado et différente de ce qui sera fait ensuite dans le 2.6.x+1.
> Je pense que maintenant les distros vont se servir de cette branche
> au lieu d'utiliser la mainline de Linus.
Ça oui, c'est l'objectif premier de factoriser un peu l'intégration des patches que de toute façon tout le monde aurait appliqué de son côté. Ça en fait une bonne base, mais pas forcement pour autant un bon noyau pour l'utilisateur final.
Bon bah vu qu'il n'y avait pas de risque, je suis passé choper rapidos le modèle de la FNAC, l'«USB 939» de chez E-KOM. C'est un peu cher par rapport à ce que j'ai vu sur le net, mais bon, ça marche nickel, avec le driver "pl2303".
Je verrais bien si j'applique la 2ème phase de la méthode doublehp, mais je vais probablement avoir la flemme, je me connais...
> Il y a plusieurs femmes Geek qui se prommenent ici
Avec en gros une chance sur deux pour que leur mec ait voté pour la dernière réponse, je leur suggère une scène de ménage au titre de la présomption de culpabilité, qu'aucun couple ne saurait ignorer.
Intérressant, sur KernelTrap, un aperçu de quelques unes des nouveautés prévues pour le 2.6.12, dont en particulier :
- FUSE (système de fichiers en user space, à la LUFS et compagnie)
- cpusets: un système de partitionnement des resources CPU des machines SMP (en gros si je comprends bien, à la fois de la virtualisation et de l'allocation explicite des ressources CPU à certaines tâches)
Et puis plein d'autres choses, dont rien de garanti bien sûr.
> L'époque des toolkit motif/etc a largement prouvé que le concept de
> customiser par application SUCKS VELU.
Je pense qu'il y a un juste milieu. Avoir par exemple le texte dans les barre d'outil par défaut mais avec la possibilité de le désactiver une fois qu'on est familiarisé avec l'appli me semble être un use-case raisonnable, et pas seulement pour les jacky du desktop, aussi pour les utilisateurs lambda.
Posté par tgl .
En réponse au journal Pango.
Évalué à 3.
Ça me parait presque plausible dans certaine situations. Voir par exemple ces benchs que j'avais fait il y a longtemps pour montrer l'utilité d'une option que je voulais faire accepter dans "emerge" et qui permettait de cacher les gros dump de compilation et la liste des fichiers mergés : http://bugs.gentoo.org/attachment.cgi?id=23318&action=view(...)
Le cas de sources kernel est extrème (pas de compilation, mais une énorme liste de fichiers à merger), et donne un rapport de plus de 300% entre le gnome-terminal le mode silencieux (dont xterm n'était pas bien loin si je me souviens bien, enfin il n'introduisait pas un surcoût délirant, tout comme la console vga d'ailleurs). Mais même pour des cas plus normaux comme la compilation de Ruby, y'avait quand même un petit 150%, or c'était en incluant des temps fixes non négligeables dans le tas, comme le calcul des dépendances.
Ceci dit, je ne prétends pas qu'il faille incriminer Pango pour ça. J'ai souvent refait des benchs de ce genre, et l'influence de facteurs tels que la valeur de nice ou bien le noyau utilisé me fait plus tendre vers les explications incriminant des comportements pathologiques pour le scheduler, du type de ce qui est décrit là : http://marc.theaimsgroup.com/?l=linux-kernel&m=108093070600316&(...)
Et puis aussi j'ai l'impression que ça c'est amélioré ces derniers temps (mais là encore, je ne sais pas si ça viens de gnome-terminal lui même ou bien de changements de noyau).
[^] # Re: Emerge sur une autre distrib
Posté par tgl . En réponse à la dépêche Gentoo 2005.0 et autres nouvelles. Évalué à 5.
Tu peux voir (en vraiment très très gros) la bête comme divisée en 2 couches :
- l'une, emerge lui même, en pur Python, fait un peu office d'apt-get et autres urpmi (principalement de la gestion de dépendances donc). Ça n'a pas vraiment d'intérêt si ça n'est pas pour gérer l'ensemble du système (ou au moins une large partie comme dans le cas de gentoo/macosx) ;
- l'autre, en Bash et Python, fait plutôt office de dpkg et autres rpm, c'est à dire gère la compilation et installation d'un ebuild particulier, indépendament du reste du système. Le gentooiste moyen n'en fera pas un usage direct en général, mais c'est pourtant possible avec la commande "ebuild".
C'est cette 2ème partie qui elle est utilisable en l'état à peu près n'importe où. Elle offre toute la collection de fonctions et scripts Bash qui rendent si agréable l'écriture des ebuilds, une méthode d'installation/désinstallation des paquets, etc. Bon maintenant, bien sûr, l'utilisation de certains des ebuilds Gentoo sur une autre distrib posera des problèmes (si par exemple ils utilisent des outils maison fournis par d'autres paquets, etc.). Mais dans pas mal de cas, pour peut que tu te dépatouille pour satisfaire les dépendances "à la main", ça devrait pas mal marcher. En utilisant la variable ROOT="/là/où/tu/veux", tu devrais même pouvoir éviter les mélanges malheureux avec ton système standard.
[^] # Re: super news !
Posté par tgl . En réponse à la dépêche Gentoo 2005.0 et autres nouvelles. Évalué à 5.
Maintenant, là où Gentoo prend de la place en plus, c'est au niveau de la compilation. Sauf à bouger ça sur une autre machine, il faut de l'espace pour :
- télécharger les sources des programmes, et a priori les garder un petit peu pour ne pas avoir à les re-télécharger en cas de révision de l'ebuild. Perso je conserve les sources pour l'ensemble de mon système, et ça fait en gros 2Go (pour quand même pas mal de bazar d'installé...).
- compiler : là c'est d'espace temporaire qu'il s'agit, mais il faut l'avoir quand on en a besoin. Openoffice.org doit être un des paquets les plus gourmants à ce niveau puisque sa compilation peut occuper ~2Go il me semble. Enfin bref, mieux vaut prévoir ~3Go d'espace libre pour laisser enfler et désenfler sont /var/tmp.
Au total donc, oui, pourquoi pas 10 Go, ça parait raisonnable pour être bien à l'aise et voir venir.
[^] # Re: super news !
Posté par tgl . En réponse à la dépêche Gentoo 2005.0 et autres nouvelles. Évalué à 5.
Une Gentoo n'est pas particulièrement longue à installer. Je me permets de te pointer vers une explication que je donnais pas plus tard qu'hier à un autre futur nouveau sur ce que je pense être la méthode raisonnable pour une installation sans temps mort :
http://article.gmane.org/gmane.linux.gentoo.user.french/82(...)
[^] # Re: Pourquoi lui ?
Posté par tgl . En réponse à la dépêche PearPC vs. CherryOS : appel aux dons en vue d'un procès. Évalué à 2.
Archive: GPL.zip
Length Date Time Name
-------- ---- ---- ----
751701 06-27-03 09:25 busybox.tar.gz
24236327 06-27-03 09:22 uClinux-2.4.17.tar.gz
-------- -------
24988028 2 files
Rien de neuf sous le soleil donc.
[^] # Re: super news !
Posté par tgl . En réponse à la dépêche Gentoo 2005.0 et autres nouvelles. Évalué à 7.
[^] # Re: Abiword et Gnumeric
Posté par tgl . En réponse à la dépêche OpenOffice.org version 2.0 et Java. Évalué à 4.
http://member.wide.ad.jp/wg/mgp/(...)
Il y a aussi S5 qui a l'air sympa, basé lui sur XHTML et CSS :
http://linuxfr.org/2004/10/14/17436.html(...)
http://www.meyerweb.com/eric/tools/s5/(...)
[^] # Re: Docs gentoo en francais ?
Posté par tgl . En réponse à la dépêche Gentoo 2005.0 et autres nouvelles. Évalué à 10.
Je redirige vers nos modéros aux pouvoirs d'édition infinis.
[^] # Re: j'en suis pas sorti indemne
Posté par tgl . En réponse à la dépêche Le Cauchemar de Darwin. Évalué à 2.
Tiens bah puisqu'on parle documentaires de qualité, si vous tombez sur "The Corporation", et bah je vous le conseille très vivement. C'est une démonstration point par point du caractère psycopathe des grandes sociétés, et vraiment, c'est implacable. Par contre je pense pas qu'il soit encore en salle, ça doit faire genre un mois ou deux que je l'ai vu, mais bon, peut-être en DVD ou assimilé ?
http://www.thecorporation.com/(...)
[^] # Re: Violation en masse
Posté par tgl . En réponse à la dépêche 13 violations de la GPL. Évalué à 2.
> comment ca marche...
Regarde déjà les diverses ressources de Harald Welte (slides, blog, etc.), il explique déjà très bien pas mal de choses (modulo qu'il n'est pas garanti que tout colle à 100% au droit français).
[^] # Re: Absolument pas...
Posté par tgl . En réponse à la dépêche La langue française dans l'aventure informatique. Évalué à 7.
Pourquoi peur ? C'est comme ça que se forme une langue, tout nos mots sont des usages entérinés, certains ils y a des siècles, et d'autres plus récemment. Bien sûr, ça doit se faire avec parcimonie, il ne s'agit pas de valider n'importe quel abus à la mode. Mais là pour le coup je suis plutôt d'accord pour dire que le mot manquait, qu'il n'est pas trop moche, qu'il a une étymologie qui tient la route, donc bref, pourquoi pas...
[^] # Re: Pas grave ...
Posté par tgl . En réponse à la dépêche Debian envisage un support partiel des architectures les moins utilisées. Évalué à 5.
> simplifier ce genre d'acrobatie. Il faudrait que je jette un oeil.
Oui, ça facilite bien la création d'une toolchain. En gros, ça permet d'automatiser les étapes décrites ici :
http://dev.gentoo.org/~vapier/CROSS-COMPILE-HOWTO(...)
Y'a une ML gentoo-embedded@ aussi si ça t'intérresse, où ont lieu la plupart des discussions sur les histoires de cross-compilation.
[^] # Re: Bonne nouvelle
Posté par tgl . En réponse à la dépêche NeroLINUX : Un nouveau logiciel de gravure de CD et DVD. Évalué à 6.
> popularité auprès des éditeurs. Par contre si le but c'est d'avoir la
> possibilité de tout faire avec des logiciels libres, le portage peut
> avoir des conséquences négatives
Je ne fais pas de l'acceptation de Linux par les éditeurs de proprio un but en soit, et pour moi le but est bien d'aller vers un maximum de libre pour un maximum de gens. Mais je ne crois pas non plus que ça va se faire tant que le clivage entre proprio grand public et libre restera ce qu'il est aujourd'hui. Faudrait pas perdre de vue que la part du proprio dans l'informatique grand public est aujourd'hui de ~95%, et que sa part dans le grand public commercial doit être plus élevée encore. On peut rêver à des lendemains meilleurs, mais ça ne sert à rien si on ne réfléchit pas en termes de transition, si on n'envisage pas les scénarios possibles d'un basculement massif.
C'est avec cette optique que je vois d'un bon oeil la reconnaissance de Linux par les éditeurs de logiciels grand public. Ils sont aujourd'hui presque tous des acteurs du statu quo, parcequ'il vendent du code proprio pour Windows ou MacOS, et qu'ils ont donc intérêt à ce que les systèmes libres restent autant que possible marginaux. Au contraire, ceux qui commencent à éditer aussi leur produits pour Linux deviennent neutres dans la bataille des OS. Ça fait pas beaucoup avancer le schmilblick tu me diras, mais quand même, ça modifie légèrement le rapport de forces en faveur des systèmes libres, parceque c'est autant d'inertie en moins en face. Or sans l'inertie que constitue les applications, les systèmes propriétaires ne seraient plus grand chose, et deviendraient vite marginaux, saugrenus, au mieux un caprice pour quelques nostalgiques fortunés.
Alors tu me diras, avec mon plan, pourtant déjà d'un optimisme à la limite de l'utopie, on arrive à des OS libres pour tous, mais truffés d'applis proprios, et c'est pas terrible. Mais en fait, non, dans mon plan ça ne finit pas comme ça, parcequ'intervient un autre facteur : l'influence vertueuse des systèmes libres sur les éditeurs de proprio. Tous frais débarqués dans un monde nouveau, voilà nos éditeurs qui découvrent d'autres modèles pour le développement et le commerce. C'est par exemple Real qui après avoir livré quelques versions bien proprio et bien pourries de son player se réoriente vers un player essentiellement libre (Helix), et un simple greffon proprio. Je pense qu'en fait la plupart des éditeurs de logiciels ne font pas le choix de leur modèle 100% proprio, mais que simplement ils se conforment à l'existant sans réflechir un instant aux alternatives. Au contact d'un système libre, les voilà forcés de constater que d'autres modèles existent, et qu'ils peuvent par exemple avoir intérêt à fournir un logiciel essentiellement libre et ne vendre que des extensions sous forme propriétaire, ou bien à s'orienter plus vers du service, etc. Les voilà aussi confrontés à une concurrence qu'ils ne pourront de toute façon jamais complètement étoufer, et qui abandonnent donc leurs ambitions de monopôle pour viser plutôt à avoir juste leur place dans un monde ou le choix prime, acceptant ainsi l'indispensable ouverture des formats de leurs fichiers parceque sans intéropérabilité ils se marginaliseraient.
Ouais, bon, je rêve ? Oui, un peu, mais parmis les rêves ambitieux, celui d'une informatique essentiellement libre dans laquelle les éditeurs de proprio existants trouveraient quand même leur place me parait être le moins inaccessible. Nous ne sommes pas en position de gagner une guerre frontale du 100% libre contre le 100% proprio, et c'est pas de passer nos grand-mères sous Mandrake qui va suffir à changer ça. Voilà, en gros, ma position...
[^] # Re: Bonne nouvelle
Posté par tgl . En réponse à la dépêche NeroLINUX : Un nouveau logiciel de gravure de CD et DVD. Évalué à 9.
> libres !
Perso je suis comme à peu près tout le monde ici je pense, j'ai ai rien à foutre de ce logiciel en particulier, je l'utiliserai pas, je l'essaierai même pas, et je suis plutôt content des outils libres (modulo que j'aimerai bien voir libburn avancer un peu plus vite, mais bon, je vais pas me plaindre, je n'y contribue pas non plus).
Cependant, je prends cette release comme une bonne nouvelle, parceque je considère que chaque portage d'un soft proprio grand public vers Linux est un signe supplémentaire que petit à petit, l'oiseau fait son nid. J'ai la même impression quand je vois par exemple portés des jeux 3D-qui-passeront-pas-sur-mon-ati7500, j'me dis que c'est pas pour moi, mais que c'est positif quand même.
En fait, je préfère je crois ces niouzes "soft proprio débarque sur système libre" à celles "soft libre débarque sur système proprio", je les trouve de meilleure augure.
[^] # Re: Haut les mains !
Posté par tgl . En réponse à la dépêche Sortie de GNOME 2.10. Évalué à 3.
Argh, bon, ça se complique alors. Enfin moi ce que j'ai remarqué sous Gentoo c'est que Gnome 2.10 utilise un certain Howl qui vient de là :
http://www.porchdogsoft.com/products/howl/(...)
Et que KDE 3.4 lui utilisera un mDNSResponder qui vient de là :
http://developer.apple.com/macosx/rendezvous/(...)
Mais j'avoue n'avoir pas regardé ça de plus près pour voir si l'un était forké de l'autre ou quoi, ou bien si c'était même carrement le même soft.
[^] # Re: Haut les mains !
Posté par tgl . En réponse à la dépêche Sortie de GNOME 2.10. Évalué à 2.
Ah oui, exact. Et par contre il me semble qu'ils ne se basent pas sur la même implèm' (howl pour Gnome et mDNSResponder pour KDE je crois), à moins que ça ne soit une spécificité de Gentoo ça.
Niveau utilité, j'imagine assez bien que ça pourrait avoir un intérêt pour les vues du style 'network:///', mais à part ça je vois pas trop non plus, d'où ma curiosité.
# Haut les mains !
Posté par tgl . En réponse à la dépêche Sortie de GNOME 2.10. Évalué à 3.
[^] # Re: Nombre de commentaires faux ?
Posté par tgl . En réponse à la dépêche Changement dans la numérotation du noyau Linux. Évalué à 3.
http://linuxfr.org/tracker/(...)
[^] # Re: progrés
Posté par tgl . En réponse à la dépêche Changement dans la numérotation du noyau Linux. Évalué à 8.
> corrections de trous de sécurité et les bugfix [...]
Non, on n'est pas certain du tout d'y trouver tous les correctifs, même de sécurité. Il est clairement annoncé que si une faille connue n'a pas de fix suffisament concis et évident, alors elle restera ouverte dans les 2.6.x.y. Dans les -ac, l'objectif est plus de fermer la faille à tout prix, quitte à ce que ce soit fait de façon un peu crado et différente de ce qui sera fait ensuite dans le 2.6.x+1.
> Je pense que maintenant les distros vont se servir de cette branche
> au lieu d'utiliser la mainline de Linus.
Ça oui, c'est l'objectif premier de factoriser un peu l'intégration des patches que de toute façon tout le monde aurait appliqué de son côté. Ça en fait une bonne base, mais pas forcement pour autant un bon noyau pour l'utilisateur final.
# Thanks
Posté par tgl . En réponse au message Adaptateur RS232<->USB. Évalué à 2.
Je verrais bien si j'applique la 2ème phase de la méthode doublehp, mais je vais probablement avoir la flemme, je me connais...
Enfin bref, merci à vous trois.
[^] # Re: [X] La table basse de salon connectée en ethernet
Posté par tgl . En réponse au sondage Le gadget geek ultime. Évalué à 9.
Avec en gros une chance sur deux pour que leur mec ait voté pour la dernière réponse, je leur suggère une scène de ménage au titre de la présomption de culpabilité, qu'aucun couple ne saurait ignorer.
# 2.6.12
Posté par tgl . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 8.
- FUSE (système de fichiers en user space, à la LUFS et compagnie)
- cpusets: un système de partitionnement des resources CPU des machines SMP (en gros si je comprends bien, à la fois de la virtualisation et de l'allocation explicite des ressources CPU à certaines tâches)
Et puis plein d'autres choses, dont rien de garanti bien sûr.
http://kerneltrap.org/node/4789(...)
[^] # Re: RSS =D
Posté par tgl . En réponse au journal Consultation journalière du ouaibe. Évalué à 2.
La page est générée à l'arrache ainsi :
- export en OPML depuis Straw
- convertie en HTML par un xsltproc avec la feuille XSL qu'on trouve ici :
http://xset.co.uk/opml_to_li/(...)
- retouchée à la main pour rajouter des balise <html>, <head> et <body>
[^] # Re: Critique d'art. En toute subjectivité.
Posté par tgl . En réponse au journal Un nouveau look pour Gnome 2.12. Évalué à 3.
> customiser par application SUCKS VELU.
Je pense qu'il y a un juste milieu. Avoir par exemple le texte dans les barre d'outil par défaut mais avec la possibilité de le désactiver une fois qu'on est familiarisé avec l'appli me semble être un use-case raisonnable, et pas seulement pour les jacky du desktop, aussi pour les utilisateurs lambda.
[^] # Re: Critique d'art. En toute subjectivité.
Posté par tgl . En réponse au journal Un nouveau look pour Gnome 2.12. Évalué à 2.
> appli et pas sur les autres...non ?
Je crois que non justement, cf. par exemple le hack utilisé dans GEdit (mais on en trouve de similaires dans pas mal d'autres applis) :
http://linuxfr.org/comments/474327.html#474327(...)
[^] # Re: pango
Posté par tgl . En réponse au journal Pango. Évalué à 3.
http://bugs.gentoo.org/attachment.cgi?id=23318&action=view(...)
Le cas de sources kernel est extrème (pas de compilation, mais une énorme liste de fichiers à merger), et donne un rapport de plus de 300% entre le gnome-terminal le mode silencieux (dont xterm n'était pas bien loin si je me souviens bien, enfin il n'introduisait pas un surcoût délirant, tout comme la console vga d'ailleurs). Mais même pour des cas plus normaux comme la compilation de Ruby, y'avait quand même un petit 150%, or c'était en incluant des temps fixes non négligeables dans le tas, comme le calcul des dépendances.
Ceci dit, je ne prétends pas qu'il faille incriminer Pango pour ça. J'ai souvent refait des benchs de ce genre, et l'influence de facteurs tels que la valeur de nice ou bien le noyau utilisé me fait plus tendre vers les explications incriminant des comportements pathologiques pour le scheduler, du type de ce qui est décrit là :
http://marc.theaimsgroup.com/?l=linux-kernel&m=108093070600316&(...)
Et puis aussi j'ai l'impression que ça c'est amélioré ces derniers temps (mais là encore, je ne sais pas si ça viens de gnome-terminal lui même ou bien de changements de noyau).