tgl a écrit 1743 commentaires

Jusqu'ici, la seule chose que j'ai jamais gcjisé c'est "pdftk" (http://www.accesspdf.com/pdftk(...)), parcequ'il est vraiment prévu pour ça (l'appli est en c++ et la lib en Java). C'est un peut maigre, et j'ai pas vraiment l'impression d'avoir vraiment rentabilisé l'installation du bestiau.

D'où ma question : vous l'utilisez sur quelle appli gcj, uniquement des trucs spécifiques juste à vous, ou bien sur des trucs que moi je fais tourner comme un couillon dans une jvm ?

Bah j'sais pas, c'est pas comme la clope non plus, enfin par exemple je me bougerais pas à la gare un dimanche soir parceque je suis en rade de Coca, mais bon quand même, y'a un truc. « P't'être de la betterave... »

> (j'en ai gouté qui on exactement le meme gout)

Je veux des noms ! Sincèrement, je cherche depuis longtemps. Jusque là le meilleurs remplaçant que j'ai trouvé c'est le Breizh Cola, enfin il est différent mais bon quand même. Par contre je le trouve que le samedi matin au marché, c'est pas viable à long termes. Mais un Coca vraiment Cola, non, je n'en connais qu'un, produit par une grosse boîte américaine puante, et je suis dépendant et désespéré. Comme avec les clopes quoi. Heeelp...

J'ai longtemps utilisé (G)Vim, mais me voilà finalement sous Cream. Je vous rassure, ça n'est qu'une demi infidélité, puisqu'il s'agit en fait d'un _gros_ mode pour GVim. Ça se trouve ici, même les vimeurs peuvent l'essayer, je suis la preuve qu'on peut aimer :
http://cream.sourceforge.net(...)
Comme c'est Vim, pas de pb pour rajouter des plugins cvs, ftp et compagnie, et comme c'est Cream, pas de problème pour s'y faire très vite.

PS: Deux pages où l'auteur de Cream explique pourquoi il adore et il déteste Vim. Un genre de troll narcissique quoi... :
http://cream.sourceforge.net/love.html(...)
http://cream.sourceforge.net/hate.html(...)

Juste pour que ce soit clair, "emerge -f" ne télécharge bien sûr que les fichiers qui ne le sont pas encore. Donc depuis une Gentoo, le pb ne se pose pas. Là où ça se complique, c'est pour faire la liste des fichiers manquant par exemple pour les télécharger ensuite depuis un autre système, et ce parceque "emerge -pf" liste tous les fichiers, manquant ou pas. En plus de la solution que tu donnes, on peut aussi jeter un oeil au forum, y'a pas mal d'autres scripts pratiques qui trainent. Par exemple :
http://forums.gentoo.org/viewtopic.php?p=888098#888098(...)
http://forums.gentoo.org/viewtopic.php?t=79884(...)

> il restera toujours le problème de la glibc et des fontes

Ajoute aussi toutes les images distribuées applaties. Qu'on ne me disent pas que c'est la forme préférrée pour leur modification (ou bien tiggert, jimmac et tant d'autres bosseraient-ils sous paintbrush ?). Faudra qu'on m'explique la différence avec les firmware binaires livrés dans le noyau...

Le "make install", très mauvaise idée. Enfin t'installe ton paquet sans que portage n'en contrôle le contenu (donc pas désinstallable), et en perdant toute la valeur ajoutée par le packageur (les ebuilds ne sont que rarement de simples "./configure ; make ; make install"). Regarde vraiment du coté de "man ebuild", il y a ce qu'il faut pour finir proprement le boulot sans que rien n'échappe au gestionnaire de paquets.

--resume

Non, pas pour reprendre la compilation d'un paquet. Le "--resume" sert à reprendre la liste des paquets à émerger là où ça s'est arreté (au 10ème sur 36 si c'est au 10 que ça s'est arreté), mais le paquet sur lequel ça s'est arreté et qui était à moitié compilé est lui recompilé entièrement.

- Le fait que çà ne soit pas tout à fait "figé"

C'est comme tu veux que se soit, rien ne t'oblige à te mettre à jour quotidiennement. La différence est principalement qu'il n'y a aucune raison que le moment où toi tu te figes corresponde à une quelconque version officielle. Ne mettre à jour que les paquets dans lesquels des bugs nous énervent ou sur lesquels il y a des alertes est parfaitement possible. Pour les mises à jours de sécurité, l'automatisation n'est effectivement pas encore super bien intégrée (cf. mon post un peu plus bas sur "glsa-check"), mais bon, de toute façon si ça t'importe vraiment, les GLSA tu t'y abonnes par mail et tu les appliques à la main (je dirais qu'il y en a 2 ou 3 par semaine, c'est pas la mer à boire). Si tu fouine un peu dans le forum, tu verras que des gens avec des serveurs sérieux ou des parcs de station sous Gentoo, il y en a de plus en plus. La politique des admins n'est alors clairement pas de faire des "emerge -uD world" quotidien, mais se base plutôt sur des màj parcimonieuses, avec pour les parcs un snapshot de l'arbre et des paquets binaires partagés sur le réseau, ce genre de chose. Bref, question de méthode, mais y'en a pour tout les goût.

- Certains codes sources récupérés chez sourceforge lors d'un emerge n'arrivent pas à être téléchargés facilement.

Bah y'en a quand même pas mal des mirroirs sourceforge, ça ferait un peu double emploi de coller ces fichiers là sur les mirroirs Gentoo (or c'est quand même une grosse quantité de fichiers qui est concernée). Par contre ils ne sont effectivement pas tous listés dans le profiles/thirdpartymirrors officiel, et ceux qui y sont privilégient surtout les US et le Japon. Perso j'en ai rajouté deux dans mon /etc/portage/mirrors qui le font mieux pour la France, et je n'ai jamais le moindre problème.

- Enfin, il est rageant de voir la compilation de Ooo échouer [...] Je n'ai apparament pas trouvé de mécanisme pour faire ceci et çà doit se gérer en bricolant à la mano.

Perso je trouve absurde de compiler soit même OOo (même si je l'ai déjà fait), il n'y a ni optimisation possible (OOo est très strict sur les CFLAGS acceptés), ni option de configuration commandée par des USE flags. Ça reviens donc en gros à refaire les GRP chez soit, ça ne sert à peu près rien. Mais sur d'autres exemples, la reprise de compilation est effectivement un truc qui sert parfois (perso je suis en ~x86, et des paquets qui compilent pas, ça arrive. Alors je patch et je relance.) : c'est avec la commande "ebuild" que ça se fait. En gros, "emerge" fait lui systématiquement toute les étapes, du unpack des sources au merge, alors que justement "ebuild" permet de faire ces étapes individuellement.

il ne faut pas vouloir être pressé pour essayer certains paquets et se rendre compte au final que le logiciel installé n'était pas tip top

Pour essayer sur un coup de tête un gros logiciel, ayez le réflexe GRP. Et ça le fait mais que ça pourrait être mieux avec d'autres USE flags, ou bien qu'il y a peut-être à gratter niveau optimisation, ou encore qu'il n'y avait pas de GRP pour la dernière version toute fraiche, alors lancer l'emerge normal en tâche de fond, tout en continuant à jouer avec la version binaire.

Le code n'est pas intégré à emerge, mais il est depuis quelques temps déjà en test dans un outils séparé :

# glsa-check -l
[...]
200404-17 [U] ipsec-tools and iputils contain a remote DoS vulnerability ( net-misc/iputils net-firewall/ipsec-tools )
200404-18 [U] Multiple Vulnerabilities in ssmtp ( net-mail/ssmtp )
200404-19 [U] Buffer overflows and format string vulnerabilities in LCDproc ( app-misc/lcdproc )
200404-20 [N] Multiple vulnerabilities in xine ( media-video/xine-ui media-libs/xine-lib )

# glsa-check -f new
fixing 200404-20
>>> merging media-libs/xine-lib-1_rc3-r3
Calculating dependencies ...done!
>>> emerge (1 of 1) media-libs/xine-lib-1_rc3-r3
[...]

C'est encore expérimental, mais pour l'instant moi je trouve que ça marche pas mal. Les détails là :
http://www.gentoo.org/proj/en/portage/glsa-integration.xml(...)

M'enfin, on va pas le plaindre, il aura surement négocié son départ de Gentoo Inc. avec une petite licence lui permettant de réutiliser l'ensemble du code de la Gentoo à des fins personnelles illimitées

BeTa, la rancœur te fait sombrer dans le FUD.

Pour ceux qui veulent des détails sur la création de la fondation ou bien des quelques éléments d'explication sur le départ de Daniel, les archives de la liste gentoo-nfp sont là :
http://news.gmane.org/gmane.linux.gentoo.nfp(...)

Un peu dans le même genre, pour Gentoo (m'enfin bon, avec 90% du contenu qui est en fait indépendant de la distrib) :
http://www.gentoo.org/doc/en/gentoo-security.xml(...)

Si tu regardes les propriétés d'un bmp sans extension (c'est dans le menu contextuel), tu verras en bas du dialogue que le type "magique" est bien reconnu (en fait, rox utilise la base shared-mime-info de freedesktop, qui dispose d'un /usr/share/mime/magic). Mais ce qui manque à rox c'est une option pour donner la priorité à ce type là pour les fichiers sans extension (voir pour tous les fichiers, mais ça ramerait probablement), ou bien j'ai pas trouvé comment faire non plus si c'est possible. Il me semble d'ailleurs qu'il y avait ça dans rox-1.2. Ça pourrait valoir le coup de se fendre d'une petite feature request pour voir...

Ça marche ici avec :
- d'une part "gtk-can-change-accels = 1" dans mon ~/.gtkrc.mine (vérifie qu'il est bien inclus par ~/.gtkrc-2.0, sinon colle le direct là)
- d'autre part /desktop/gnome/interface/can_change_accels à 1 dans ma base gconf. ("gconftool -t boolean -s /desktop/gnome/interface/can_change_accels 1" en ligne de commande pour l'activer)

Je ne sais pas si c'est vraiment la peine d'avoir les deux, mais je suis assez ceinture et bretelles...

Ce commentaire ne sera probablement jamais lu vu que le journal à plus de 24H, mais bon...

La réponse est "oui et non". L'expansion que bash fait sur les nom de fichiers est loin d'être aussi puissante que les regexp, mais ne se limite pas pour autant au joker "*". En gros, de tête les trucs dont je sais qu'ils marchent parceque je les utilises :
- * est substituable par une chaine quelconque, éventuellement vide
- ? est substituable par exactement un caractère quelconque
- [X-Y] est substituable par exactement un caractère de l'intervale X-Y (ça peut être [0-9], [a-z], [A-Z], etc.)
- [XY] est substituable par exactement X ou Y
- [^X] est substituable par n'importe quel caractère différent de X
- les 3 syntaxes précédentes sont combinables évidement : [0-9abcdef] ou bien encore [0-9a-f] sont substituables par 0, 1, ..., a, b, ..., ou f.
- toutes ces substitutions sont cantonnées à exactement un nom de fichier ou répertoire, c'est à dire qu'elles ne concernent que les caractères valides pour les noms de fichiers, et qu'elle ne peuvent en particulier pas être à cheval sur un slash (elle ne matchent pas un path). Par contre, on peut bien sûr les enchainer explicitement avec des slash pour matcher un path : h*/t* matchera bien /home/thomas.
- le shell fait l'expansion des paramètres avant d'appeler effectivement la commande, et c'est donc utilisable quelle que soit la commande (pas seulement les commandes standard de bash donc). Par exemple, 'gvim foo[0-9].bar' dans un répertoire ou existent 'foo1.bar' et 'foo2.bar' deviendra 'gvim foo1.bar foo2.bar'.

Voilà pour ce que moi j'utilise et je sais, après `man bash` en dira sûrement plus...

Mais quand on veut faire des choses un peu plus fines, il faut quand même ce rabattre sur une combinaison de find et de grep.

> n'en déduit-on pas que justement leurs stats sont faites à partir des requêtes ?

Oui. Mais justement, dans le scénario "multiples aller-retours car navigation dans une seule page", on fait bien plusieurs requêtes. À moins que google ne stocke sur ses serveurs la dernière requête de chaque utilisateur pour éviter de la compter plusieurs fois quand elle est ainsi répetée... Ça c'est effectivement plausible.

Tu sais, je pense que tu peux tranquillement arrêter d'argumenter. Comme tu l'as déjà à maintes reprises patiemment expliqué, il s'agit d'un troll. Tes réponses sont convaincantes, et c'est pas bien grave si tu n'as pas le dernier mot, ça ne te donnera pas tord pour autant, loin de là.

le nombre de couples/navigateur

"le nombre de couples utilisateur/navigateur"

En fait, le navigateur influençant le nombre de hits moyen de l'utilisateur (onglets, page d'accueil, panel de recherche, etc.), ce qu'il faudrait c'est pas une stats basée sur les hits mais une stats basée sur le nombre de couples/navigateur, avec un cooky valable un mois, qui compterait juste une voix quand il est délivré/renouvelé. Bon, ça ne reglerait pas le biais du spoofing d'Id navigateur, et puis ça introduirait peut-être un autre biais qui est que les utilisateurs les plus éclairés sont à la fois les plus enclins à utiliser mozilla et à refuser les cookies, mais se serait quand même mieux, non ?

> Il y'a aussi les onglets qui permettent d'ouvrir moins le browser.
> Euh t'es sérieux là ?

Je pense que ce qu'il veut dire c'est ça :

- sous IE, l'utilisateur de base il navigue presque toujours dans une seule fenêtre à la fois (je l'ai vu, de mes yeux vu). Ça veut dire qu'il fait sa recherche google, suit le premier lien avec un clic gauche, lit la page, se dit que c'est pas ce qu'il cherche, et clique sur le bouton retour. Hop, ça fait un nouveau hit. Il arrive comme ça à un hit par résultat consulté, disons une petite dizaine pour une recherche donnée.

- sous Mozilla, l'utilisateur il lance sa recherche, fait des clics milieu sur toutes les pages qui semblent intérressantes, et ensuite se ballade dans les nouveaux onglets. Ça fait un seul hit pour une recherche donnée.

Les stats d'OS, elles reposent sur quoi ? Parceque si c'est sur l'Id du navigateur, tous les biais déjà décris pour les stats navigateurs se reflètent aussi sur les stats d'OS.

Sinon, je suis un peu étonné que Linux ne représente qu'un vingtaine de % des systèmes non Windows/Mac. C'est quoi les autres ? Ok, y'a les BSD, mais bon je pense que sur le desktop ils sont quand même loin derrière Linux. Et puis y'a les Solaris qui eux par contre doivent avoir une bonne part (enfin, sûrement marginal chez les particuliers, mais par contre y'a pas mal de facs avec des Sun en libre service, et puis des postes en entreprise, etc). Et peut-être quelques BeOS ou autres bizarreries, mais bon quand même, que ça arrive à faire 4 fois plus que les Linux ça me parait beaucoup (enfin mon étonnement est très subjectif hein...). Ou bien peut-être y a-t-il aussi des services webs reposant sur Google (genre recherche au sein d'un site) qui sont comptabilisés là dedans ?

Ah, les disques en Mo... Depuis mon premier PC, j'ai multiplié mon espace disque par environ 2000. Alors que ma puissance de traitement de l'information, elle, n'a été multipliée que par, aller, disons 50. Ce qui prouve donc que l'information était plus dense à cette époque. Les bits, z'étaient mieux au vent.

Moi pour dromadaire vs. chameau, je me dis que c'est le chien l'ami de l'homme, que donc les autres animaux sont des faux amis (au besoin je conforte cette opinion en pensant au penguin manchot), et que donc le "camel" n'est qu'un dromadaire. Après j'ai plus qu'à sortir mon paquet de clopes pour y compter la bosse.

Arf, maintenant que tu le dis, ça parait en effet évident. Qu'est-ce que je suis premier degré moi parfois...