Sans vouloir faire mon chieur, je trouve ça soit ambigü, soit faux:
- oui, c'est une bibliothèque native, avec des sources et tout et tout
- non, ça n'est pas particulièrement un dévelopement de l'équipe mplayer
- oui les deux projets sont quand même assez liés, mplayer fournissant sa propre version bidouillée de ffmpeg et contribuant beaucoup à cette bibliothèque
Enfin bref, c'est juste pour dire que tout le mérite ne va pas à Mplayer, qui aurait beaucoup moins d'intéret sans le superbe travail de Fabrice Bellard et al.
Si vous voulez être tenu au courant "en temps réel" de tout ça et élargir un peu la problématique, la liste Escape_l est vraiment toute indiquée.
Ouais, je lis aussi depuis qlqs mois escape_l, et c'est vraiment un excellent canal d'information : seulement qlqs messages par jours, mais toujours intérressant, avec plein de refs vers des articles du reste du web ou de la presse écrite, et des contributeurs de qualité (dont notament Philippe Aigrain et Bernard Lang), bref le top niveau rapport signal/bruit. Même P. Bresse y est abonné, c'est dire... :)
C'est vrai que c'est assez sexy. Je vais pas troller sur le côté «pas libre» parceque le débat à déjà été fait 100 fois.
Par contre, Est-ce que c'est vraiment pratique ? Dans le truc d'exemple là, on navigue en cliquant sur des boutons (qui au passage bouffent de la place) : je me vois pas faire ça debout à côté d'un laptop sans perdre un temps fou entre chaque transparent. Y'a des gens qui ont réussi à avoir un truc qui marche bien avec juste PgUp/PgDown par exemple ?
Enfin, ma question est assez formelle ceci dit, parceque moi je suis content jusque ici avec mon Latex+Prosper.
Manifestement, tout le monde n'est pas d'accord sur ce que les macros devraient avoir le droit de faire: en gros, certains trouvent que c'est nécéssaire qu'elles aient par exemple accès à tes fichiers ou à internet et que c'est pas un problème vu que tu n'es pas obligé de les exécuter. D'autres pensent que c'est dangereux pour les utilisateurs qui les exécuteront sans comprendre ce risque ou le message de warning, et qu'il aurait mieux valu restreindre leurs possibilités à la manipulation des documents OOo, pour ne pas prendre de risques.
> 1. Je n'accepterais jamais l'execution d'une macro pour un document dont je ne
> connais pas la provenance
C'est pas toi le problème, c'est l'utilisateur lambda d'un logiciel de bureautique qui ne comprend même pas la question.
> 2. C'est quoi la difference (hormis la convivialite) entre lancer une macro qui se trouve
> sur un site dont on fait la pub sur linuxfr et installer un nouveau logiciel dans les meme
> conditions?
Ça n'est pas "la macro dont on fait la pub sur linuxfr" le problème, c'est celle qui peut se trouver dans n'importe quel document qu'un utilisateur lambda reçoit un jour et qui n'est visualisable que si il clique sur OK (et OK c'est le truc qu'on clique pour que ça marche en général). Bref, ouvrir un document dans un traitement de texte n'est pas la même démarche que de décider d'installer un logiciel, elle n'est pas exécutée par les même personnes.
Évidemment que techniquement n'importe quel bout de code peut être un trojan, mais j'ai plus confiance en un logiciel bien connu, un source ouvert et dont l'auteur est bien identifié et exposé à une communauté (et je suis pas le seul, c'est pour beaucoup un des atouts majeurs du libre), qu'en un document quelconque qu'on ouvre juste en se disant qu'on va consulter du texte.
> 3. J'aime bien le coup des "javascripts", clique ici, si tu utilises Mozilla
Oui, les XPI c'est une connerie, mais une bien moins grave: leur utilisation est clairement présentée comme une "installation de logiciel", pas comme "un truc pour voir la page", et ça les utilisateurs ils font quand même la différence (les adages du genre "n'installe pas n'importe quoi d'internet" commencent quand même à être bien ancrés).
En plus, ça n'a rien de problématique pour une utilisation du logiciel de les désactiver, il suffit que l'administrateur du système installe lui même ce qui manque quand on lui demande. Alors que de désactiver les macros d'un soft de bureautique c'est vraiment l'amputer, et d'ailleurs c'est même pas possible dans OOo (au mieux, on demande à avoir un warning que les utilisateurs ignoreront).
> Associer "macro" à "virus", c'est "comment vous protéger de I Love You" dans le JT de TF1.
Si la macro n'a le droit que de toucher que au document qu'elle concerne, ou qu'elle n'a que des droit limités comme la lecture de certains fichiers bien choisis, alors oui, c'est juste de la parano de micro trottoir.
Si elle a le droit de faire n'importe quoi avec les privilèges de l'utilisateur qui l'execute, alors par contre c'est du bon sens. Prends les javascripts, qui sont des «macros de page web», tu leur filerais le droit de lire/ecrire n'importe quoi sur ton compte toi ?
Ésperons que OpenOffice se retrouve pas trop vite sur les bureaux de messieur tout le monde, ça nous évitera d'avoir à lui expliquer que conformemant au soucis constant de sécurité qui habite le logiciel libre il faut qu'il lise du code pour savoir s'il peut ouvrir de façon sûre un document dans son traitement de texte.
> Je suppose que tu n'utilises pas apt-get, emerge ou urpmi pour la même raison...
Perso je les utilise justement pour ça, parceque ça confine les risques à un seul outil et une seul source dans lesquels j'ai choisi sciemment de placer ma confiance. Bien sûr que le risque zéro n'existe pas, mais il y a quand même une différence énorme entre faire confiance à une équipe de développeurs et faire confiance à la terre entière. Accepter de lancer le premier bout de shell venu, même enrobé dans un .doc, sous prétexte de convivialité est complètement stupide. Faut vraiment attendre les premiers macrovirus pour avoir le droit de le dire sans se faire moinsser ? Le précédent windowsien ne vous suffit pas ? Il me semble pourtant qu'il est sans ambiguité.
> une macro doit pouvoir utiliser les commandes systèmes
Bah ouais, comme un email quoi.
> Si c'est bien le cas, toto n'a qu'un risque, c'est de foutre son répertoire en l'air
Oh bah alors, si ça n'affecte que les utilisateurs mais pas le root, c'est vrai qu'on s'en fout. L'important, c'est que la machine soit sauve, pas qu'elle soit utilisable.
Quelqu'un ici saurait s'il est possible d'avoir d'avoir les noms et les partis politiques (notament francais) auquels appartiennent ceux qui vont ont voté pour ou contre cette directive ?
Primo...
Je tiens à préciser que je partage ta volonté de mettre des linux sur plus de bureaux, et que je suis très content quand je peux convaincre quelqu'un d'installer un mandrake. Par contre contre moi j'utilise une gentoo... Mince, mais alors quelle est la bonne case pour moi ? Je pense que ta distinction entre gentooistes barbus et mandrakeux bien rasés est completement bidon, compare les distribs si tu veux mais les gens avec leur prétendues attitudes ou opinions.
Secundo... Donc, dans ce cas là, faire en sorte que la machine démarre plus vite est intéressaant pour ce genre d'utilisateur
Le "donc" est en trop, et le reste n'engage que toi.
Tu as démontré que fallait mettre linux sur le desktop et que pour ça il fallait qu'il soit convivial, pas trop compliqué, tout ça quoi. Okay, c'est vrai. Que l'installeur pose des question simples, orientées vers ce que l'utilisateur veut faire et sans jargon... Okay, c'est vrai aussi. Et que ça n'installe pas trente six services par défaut... Okay, encore vrai. D'ailleurs sur tous ces points, la mandrake montre la voie (ouais, ok, c'est surement pas la seule).
"Et donc faut que ça boot vite". Gasp! là j'ai du rater un truc... c'est quoi le rapport ? Franchement, à part les gamins qui comparent tout faute de quequette et les jeunes cadres célibataires qui bavent dans le tgv sur le Micro-Achat du mois, est-ce que tu as déjà vu des vrais newbies préocupés parceque leur PC mettait 30 secondes de trop à booter ? Moi pas. C'est typiquement un truc de nerd (et encore), parceque les vrai gens eux il se foutent pas mal de ces détails. Perso, tous ceux que je cotoie ont toujours eu 100 raisons de me demander de l'aide, mais c'était pour des choses qui ne marchait plus ou qu'ils n'arrivait pas faire, mais jamais pour peaufiner un truc de ce style là (y compris ceux qui se cognaient un scandisk à chaque boot par exemple).
Bon, je vote moi aussi pour le "on s'en fout complètement du temps de boot, il est déjà assez court pour une machine domestique et qu'il soit long pour un serveur ne gène personne".
Ceci dit c'est pas parceque c'est un faux problème qu'on peut pas bavarder sur ses solutions... Alors allons-y: le fameux boot parrallèle est implémenté depuis des mois sous gentoo (pour rappel la gentoo n'est pas basée sur le machin avec les liens symboliques Sxxtruc/Kxxtruc, mais sur des scripts qui déclarent leurs dépendances mutuelles), et je l'avais testé quand c'était à debugguer. Résultat (de tête):
- aucun gain quand on a peu de services (ouah, quelle surprise)
- une poignée (une pincée?) de secondes gagnée avec plus de services (ouah, quelle surprise aussi)
Chez moi, le plus long à lancer devait être cups, alors que rien n'en dépendais je crois, donc c'est surtout lui qui fesait gagner des secondes. Mysql peut être aussi. Enfin bon, c''etait pas la r'evolution, et la sortie était un peu confuse si un script de démarrage affichait plusieurs lignes (oui, y'aurait moyen de bidouiller pour éviter ça). Et puis peut-être que pour être plus efficace il faudrait une gestion des dépendances des scripts un peu plus molle, acceptant de lancer certains trucs parcequ'on sait que leur dépendances seront bientôt satisfaites (je m'étais dit ça surtout pour xdm, qui attendait je sais plus quoi de pas indispensable).
Bref, ce que raconte l'auteur de l'article est pas faux, mais pas vraiment intérressant non plus, ni vraiment nouveau, et en plus je l'ai pas lu.
> Les Etats Unis ?
Tiens c'est rigolo ça, il m'a fallu ton commentaire pour que je réalise que en fait ça n'était pas évident que c'était d'eux qu'il s'agissait :)
Bon, allez, j'ouvre le bal des "nous on l'a déjà" qui accompagne immanquablement chaque annonce de release d'un logiciel:
- xawdecode-1.8.0 est dans Portage depuis dimanche;
- un ebuild pour le plugin 1.4.4 est aussi disponible ici: http://tdegreni.free.fr/xawdecode/xawdecode-plugin-1.4.4.ebuild(...)
Mais il est aussi dispo pour Debian, Suse 8.2 et MDK9.1 sur Sourceforge, alors, une fois n'est pas coutume, je déclare tout le monde exaequo :)
> Vous savez peut être enfin que l'enjeu pour une société comme
> Microsoft, qui vise à établir son pouvoir absolu sur TOUTE la chaîne
> de l'information, est ici d'obtenir le dernier outil qui lui manque
> pour étouffer dans l'uf la SEULE concurrence qu'elle craigne : le
> logiciel libre.
Bon, je te l'ai déjà dis sur la mailing list de gulliver, mais j'aime bien insister, ce paragraphe il est vraiment pas à la hauteur du reste... Parler des LL, oui, mais pourquoi réduire finallement toute la problématique à cet aspect, à mon avis assez mineur ? «L'enjeu c'est ÇA!» Bah nan, ce n'en est qu'un petit bout, tu le montres d'ailleurs plus ou moins tout du long du courrier. Je crains que cette caricature conclusive ne décrédibilise un peu tout le reste.
Sinon, en critique un peu plus constructive, je suggère un lien vers le site de la FFII, personnellement c'est là que j'ai vu les analyses du texte et de ses travers les plus détaillées.
Quant au lien sur brevets-logiciels.info, bah... je suis assez mitigé. Pour moi c'est un bon site pour l'organisation de l'action militante, mais pas un site à présenter aux députés. Le côté «lobbying howto», avec les listes d'adresse, les lettres types et les recettes en tout genre est bien trop présent pour que ce soit rendu publique. C'est un peu leur écrire noir sur blanc qu'on les prend pour des cons, on devrait attendre l'après vote pour ça. Mais bon, je sais, c'est trop tard, et puis c'est quand même moins chiant à lire que les pinaillages juriques de la FFII, et puis les wikis c'est bien(tm), et puis on est prem's dans google que même si il est mal(tm) c'est quand même bien(tm), etc.
«Très cher monsieur jz, j'aimerai assez accorder deux minutes au survol du fruit de votre année de travail pour le commenter sur linuxfr, mais seulement voilà, son format ne me rend pas la tâche aussi aisée qu'elle devrait l'être. Vous auriez pu faire un petit effort quand même...»
-- Thomas Walraet, in Guide du Dlfpien Culotté
Ce qui est particulier à galeon :
[...]
- Gestion très complète des bookmarks
Tiens bah tant que j'ai un galeoneur sous la main, puis-je lui poser une petite question ?
Merci, bon bah une deuxième alors : est-ce que dans les galeon-1.3 récents le gestionnaire de bookmark est complètement "panelisable" comme il l'est dans le 1.2 ? Parceque moi, ça, c'est vraiment le truc dont je peux plus me passer : j'ai toujours mes bookmarks dans le panel avec le mode édition enclenché, et je range, je renomme, je copie, je commente, etc., sans jamais le moindre click droit, popup, et autres fenêtres superflue. Et du coup Galeon 1.2 m'a permis d'atteindre pour la première fois de ma vie une collection de bookmarks toujours bien organisée.
Mais à chaque fois que j'ai testé un 1.3, j'ai été atrocement déçu de voir que le panel n'était plus qu'un simple affichage de l'arbre, sans composant d'édition intégré. Du coup, à chaque coup, je suis repassé à la 1.2. La dernière fois c'était y'a 3-4 mois, et comme j'ai un peux la flemme de tester (passer mozilla en gtk2, c'est lourd), et bah je demande...
«Je reproche a gentoo l'obligation d'avoir une station de dev complete qui bouffe beaucoup de place disque (2 Go sur mon portable)»
Ça c'est sûr que faut pas être au giga près si on a pas une autre machine pour les compilations, c'est vraiment inhérent au principe d'une distrib source. En ça je comprends que ça convienne pas à tout le monde. Et il manque vraiment un système moins "manuel" pour le déploiement: genre pas possible pour l'instant de maintenir à jour simplement une gentoo sur un P100 avec 200Go de disque, qui ferait serveur mail, malgré une machine de compil à côté. La notion de cibles (par exemple des machines d'archi différentes, sans portage installé dessus, et sans bien sûr la machinerie de compilation) n'est pas encore intégrée à portage. Tout ce qu'on peut faire facilement avec gentoo pour de telles cibles, c'est une pseudo slackware (on leur prépare des tbz2 quoi, à installer à la main).
«un temps de compil vraiment trop long pour gagner trois fois rien»
Gagner en quoi, en "perf" ? Bah oui c'est clair. Mais en souplesse c'est assez incomparable (use flags, etc.).
«une stabilité inferieure a debian.»
Des détails stp ?
«C'est la librairie avec son numéro de version qui définie la compatibilité et pas autre chose.»
T'as pas dû souvent en écrire des spec de pacquets toi.
«Tout ce qui compte, c'est la facilité réellement fournie et non le nom du paquet.»
J'aurai dis «et non le nom du truc dont on dépend». Ce qui sous Gentoo correspond par définition à la notion de paquet virtuel (genre si on a besoin d'un driver alsa ("virtual/alsa"), on peut se satisfaire soit d'un kernel 2.5/6, soit du driver pour les 2.4).
«L'héritage est aussi utile car il permet de limiter les nombres de dépendances et ne pas tomber dans l'ingérable.»
Je ne vois pas ce que tu veux dire, mais si c'est juste que si "A dépend de B et C" mais que "B dépend aussi de C" alors on peut se contenter de dire que "A dépend de B" (enfin bref pas lister systématiquement tout jusqu'à la glibc), et que ça qu'est génial c'est qu'on peut dire "installe A" et qu'il t'installera les trois, bah c'est pas vraiment un scoop, et je connais pas de système de paquets qui gère pas au moins ça. (Enfin si, je sais plus si rpm le fait, ou le faisais à une époque lointaine en tout cas, ou si c'est urpmi qui le rajoute).
«Rpm peut aussi définir des dépendances virtuels (style require: kde)»
Je sais pas dans le monde .rpm, mais dans le monde .deb c'était plutôt ce qu'on appelait des meta-paquets. Rien à voir avec la notion de paquet virtuel sus-citée.
«des dépendances sur des fichiers»
on en reviens au bon vieux nom/emplacements bien connus. Franchement, je préfère de loin l'abstraction des virtuals (tu fait comment avec un nom de fichier pour dire: un codec divx ?)
«tes fichiers de configuration seront conservés»
Bah manquerai plus que l'install d'un paquet t'écrase ta config existante? Sérieux, c'est encore vraiment la base. (Et la je commence à flipper en me disant que si tu nous les fait tous comme ça je suis pas couché.)
«En fait le système de génération des dépendances utilise des plugins et rien ne t'empêche de devopper de nouveaux plugins»
"inherit plugin" dans un ebuild (Ah nan merde, ça concerne pas que les dépendances mais ça permet de surcharger n'importe quelle methode et d'en définir de nouvelles utilitaires...)
«par exemple sur les symboles fournis par le noyau pour vérifier si un module noyau peut-être installé et marchera»
Faut vraiment être sur une distrib à binaire pour voir ça. C'est merveilleux tellement c'est aller loin contre le bon sens et la simplicité.
«T'as un gnome-2.2.2 spécifique qui utilise un libgnome-2.2.2 spécifique incompatible avec la branche 2.2, si un gnome-2.2.3 "standard" sort, il n'écrasera pas ta version spécifique mais un gnome-2.2.3 avec tes spécificités (marqués par le tag Epoch) sera un candidat pour la mise à jours.»
Cool, ça vous fait un USE flag. Aller, encore un petit effort, c'est presque ça. Mais gaffe à l'explosion combinatoire: 2^(nbre de USE flags) est exponentiel en le nombre de USE flags. Ça va en faire des versions spécifiques à compiler pour RedHat.
«rpm gére aussi les mises à jours sur plusieurs paquets et non seulement sur un seul.»
Ouahouuu!
«Rpm gère les paquets absolètes.»
Pur narcissisme.
«J'en suis sûre. »
Moi je suis sûr grâce à ton post que bientôt rpm aura rattrapé son retard sur apt. Encore qlqs amélioration (vrais paquets virtuels, héritage entre specs, gestion explicite des masques de paquets, mélange aisé de 3 niveaux de stabilité des paquets, système de merge des fichiers de conf, etc), et il sera au niveau de portage pour ce sur quoi il est raisonnable de les comparer. Mais il n'approche qu'à peine (et c'est bien normal, mauvais choix, mauvais résultats) la souplesse que peut offrir un système basé sur les sources (use flags, optimisation, drivers, etc.). Et je n'ai pas parlé d'un autre avantage des ebuilds: le système est tellement simple, et la nécéssité de compiler étant de toute façon là, qu'il devient très vite naturel de modifier un peu l'existant à sa sauce, de se faire ses propres révision bumps, d'écrire des ebuilds nouveaux plutôt que de make installer dans /usr/local, etc. De ce que je vois sur le forum, ou je passe un peu de temps, le "PORTAGE_OVERLAY", c'est à dire ton repository d'ebuilds persos, est une chose connue et utilisée par la quasi totalité des utilisateurs, au moins ponctuellement. Alors que franchement, sur une distrib à la redhat, c'est quoi la proportion d'utilisateurs qui ont un jour fait leur propre srpm ?
c'est simple. malgré les apparences flash est controlé uniquement par macromédia.
Comme PDF par Adobe non ? Ah oui mais non, là on a des implémentations potables sous Linux, donc c'est bon on s'en fout. Faut croire que le contrôle du format n'est pas le fond du problème...
# Re: MPlayer 1.0 pre2 disponible
Posté par tgl . En réponse à la dépêche MPlayer 1.0 pre2 disponible. Évalué à 10.
Sans vouloir faire mon chieur, je trouve ça soit ambigü, soit faux:
- oui, c'est une bibliothèque native, avec des sources et tout et tout
- non, ça n'est pas particulièrement un dévelopement de l'équipe mplayer
- oui les deux projets sont quand même assez liés, mplayer fournissant sa propre version bidouillée de ffmpeg et contribuant beaucoup à cette bibliothèque
Enfin bref, c'est juste pour dire que tout le mérite ne va pas à Mplayer, qui aurait beaucoup moins d'intéret sans le superbe travail de Fabrice Bellard et al.
[^] # Re: Brevets logiciels : la commission JURI devra maintenant se défendre
Posté par tgl . En réponse à la dépêche Brevets logiciels : la commission JURI devra maintenant se défendre. Évalué à 4.
Ouais, je lis aussi depuis qlqs mois escape_l, et c'est vraiment un excellent canal d'information : seulement qlqs messages par jours, mais toujours intérressant, avec plein de refs vers des articles du reste du web ou de la presse écrite, et des contributeurs de qualité (dont notament Philippe Aigrain et Bernard Lang), bref le top niveau rapport signal/bruit. Même P. Bresse y est abonné, c'est dire... :)
[^] # Re: Export en Flash
Posté par tgl . En réponse à la dépêche Sortie d'OpenOffice.org 1.1 finale. Évalué à 1.
Allez, j'ai mérité mon blâme.
[^] # Re: Export en Flash
Posté par tgl . En réponse à la dépêche Sortie d'OpenOffice.org 1.1 finale. Évalué à 0.
C'est vrai que c'est assez sexy. Je vais pas troller sur le côté «pas libre» parceque le débat à déjà été fait 100 fois.
Par contre, Est-ce que c'est vraiment pratique ? Dans le truc d'exemple là, on navigue en cliquant sur des boutons (qui au passage bouffent de la place) : je me vois pas faire ça debout à côté d'un laptop sans perdre un temps fou entre chaque transparent. Y'a des gens qui ont réussi à avoir un truc qui marche bien avec juste PgUp/PgDown par exemple ?
Enfin, ma question est assez formelle ceci dit, parceque moi je suis content jusque ici avec mon Latex+Prosper.
[^] # Re: Sortie d'OpenOffice.org 1.1 finale
Posté par tgl . En réponse à la dépêche Sortie d'OpenOffice.org 1.1 finale. Évalué à 1.
Y'en a deux niouzes plus bas: http://linuxfr.org/2003/09/29/14133.html(...)
Manifestement, tout le monde n'est pas d'accord sur ce que les macros devraient avoir le droit de faire: en gros, certains trouvent que c'est nécéssaire qu'elles aient par exemple accès à tes fichiers ou à internet et que c'est pas un problème vu que tu n'es pas obligé de les exécuter. D'autres pensent que c'est dangereux pour les utilisateurs qui les exécuteront sans comprendre ce risque ou le message de warning, et qu'il aurait mieux valu restreindre leurs possibilités à la manipulation des documents OOo, pour ne pas prendre de risques.
[^] # Re: Sortie de DicOOo 1.0
Posté par tgl . En réponse à la dépêche Sortie de DicOOo 1.0. Évalué à 2.
> connais pas la provenance
C'est pas toi le problème, c'est l'utilisateur lambda d'un logiciel de bureautique qui ne comprend même pas la question.
> 2. C'est quoi la difference (hormis la convivialite) entre lancer une macro qui se trouve
> sur un site dont on fait la pub sur linuxfr et installer un nouveau logiciel dans les meme
> conditions?
Ça n'est pas "la macro dont on fait la pub sur linuxfr" le problème, c'est celle qui peut se trouver dans n'importe quel document qu'un utilisateur lambda reçoit un jour et qui n'est visualisable que si il clique sur OK (et OK c'est le truc qu'on clique pour que ça marche en général). Bref, ouvrir un document dans un traitement de texte n'est pas la même démarche que de décider d'installer un logiciel, elle n'est pas exécutée par les même personnes.
Évidemment que techniquement n'importe quel bout de code peut être un trojan, mais j'ai plus confiance en un logiciel bien connu, un source ouvert et dont l'auteur est bien identifié et exposé à une communauté (et je suis pas le seul, c'est pour beaucoup un des atouts majeurs du libre), qu'en un document quelconque qu'on ouvre juste en se disant qu'on va consulter du texte.
> 3. J'aime bien le coup des "javascripts", clique ici, si tu utilises Mozilla
Oui, les XPI c'est une connerie, mais une bien moins grave: leur utilisation est clairement présentée comme une "installation de logiciel", pas comme "un truc pour voir la page", et ça les utilisateurs ils font quand même la différence (les adages du genre "n'installe pas n'importe quoi d'internet" commencent quand même à être bien ancrés).
En plus, ça n'a rien de problématique pour une utilisation du logiciel de les désactiver, il suffit que l'administrateur du système installe lui même ce qui manque quand on lui demande. Alors que de désactiver les macros d'un soft de bureautique c'est vraiment l'amputer, et d'ailleurs c'est même pas possible dans OOo (au mieux, on demande à avoir un warning que les utilisateurs ignoreront).
[^] # Re: Sortie de DicOOo 1.0
Posté par tgl . En réponse à la dépêche Sortie de DicOOo 1.0. Évalué à 6.
Si la macro n'a le droit que de toucher que au document qu'elle concerne, ou qu'elle n'a que des droit limités comme la lecture de certains fichiers bien choisis, alors oui, c'est juste de la parano de micro trottoir.
Si elle a le droit de faire n'importe quoi avec les privilèges de l'utilisateur qui l'execute, alors par contre c'est du bon sens. Prends les javascripts, qui sont des «macros de page web», tu leur filerais le droit de lire/ecrire n'importe quoi sur ton compte toi ?
[^] # Re: Sortie de DicOOo 1.0
Posté par tgl . En réponse à la dépêche Sortie de DicOOo 1.0. Évalué à 6.
[^] # Re: Sortie de DicOOo 1.0
Posté par tgl . En réponse à la dépêche Sortie de DicOOo 1.0. Évalué à 5.
Perso je les utilise justement pour ça, parceque ça confine les risques à un seul outil et une seul source dans lesquels j'ai choisi sciemment de placer ma confiance. Bien sûr que le risque zéro n'existe pas, mais il y a quand même une différence énorme entre faire confiance à une équipe de développeurs et faire confiance à la terre entière. Accepter de lancer le premier bout de shell venu, même enrobé dans un .doc, sous prétexte de convivialité est complètement stupide. Faut vraiment attendre les premiers macrovirus pour avoir le droit de le dire sans se faire moinsser ? Le précédent windowsien ne vous suffit pas ? Il me semble pourtant qu'il est sans ambiguité.
[^] # Re: Sortie de DicOOo 1.0
Posté par tgl . En réponse à la dépêche Sortie de DicOOo 1.0. Évalué à 5.
Bah ouais, comme un email quoi.
> Si c'est bien le cas, toto n'a qu'un risque, c'est de foutre son répertoire en l'air
Oh bah alors, si ça n'affecte que les utilisateurs mais pas le root, c'est vrai qu'on s'en fout. L'important, c'est que la machine soit sauve, pas qu'elle soit utilisable.
[^] # Re: Mauvaise nouvelle : brevets logiciels adoptés
Posté par tgl . En réponse à la dépêche Directive sur les brevets logiciels adoptée. Évalué à 7.
http://tdegreni.free.fr/files/Votes-McCarthy-20030924.pdf(...)
[^] # Re: Premiers résultats
Posté par tgl . En réponse à la dépêche Brevets logiciels : conférence, manifestation, soutiens et positions. Évalué à 1.
C'est extrait de ça: http://www.europarl.eu.int/direct/documents/fr/vote/Resultats/Mercr(...)
[^] # Re: Un concurrent pour frozen bubble
Posté par tgl . En réponse à la dépêche Un concurrent pour frozen bubble. Évalué à 1.
[^] # Re: Pour un démarrage plus rapide de Linux
Posté par tgl . En réponse à la dépêche Pour un démarrage plus rapide de Linux. Évalué à 1.
Je tiens à préciser que je partage ta volonté de mettre des linux sur plus de bureaux, et que je suis très content quand je peux convaincre quelqu'un d'installer un mandrake. Par contre contre moi j'utilise une gentoo... Mince, mais alors quelle est la bonne case pour moi ? Je pense que ta distinction entre gentooistes barbus et mandrakeux bien rasés est completement bidon, compare les distribs si tu veux mais les gens avec leur prétendues attitudes ou opinions.
Secundo...
Donc, dans ce cas là, faire en sorte que la machine démarre plus vite est intéressaant pour ce genre d'utilisateur
Le "donc" est en trop, et le reste n'engage que toi.
Tu as démontré que fallait mettre linux sur le desktop et que pour ça il fallait qu'il soit convivial, pas trop compliqué, tout ça quoi. Okay, c'est vrai. Que l'installeur pose des question simples, orientées vers ce que l'utilisateur veut faire et sans jargon... Okay, c'est vrai aussi. Et que ça n'installe pas trente six services par défaut... Okay, encore vrai. D'ailleurs sur tous ces points, la mandrake montre la voie (ouais, ok, c'est surement pas la seule).
"Et donc faut que ça boot vite". Gasp! là j'ai du rater un truc... c'est quoi le rapport ? Franchement, à part les gamins qui comparent tout faute de quequette et les jeunes cadres célibataires qui bavent dans le tgv sur le Micro-Achat du mois, est-ce que tu as déjà vu des vrais newbies préocupés parceque leur PC mettait 30 secondes de trop à booter ? Moi pas. C'est typiquement un truc de nerd (et encore), parceque les vrai gens eux il se foutent pas mal de ces détails. Perso, tous ceux que je cotoie ont toujours eu 100 raisons de me demander de l'aide, mais c'était pour des choses qui ne marchait plus ou qu'ils n'arrivait pas faire, mais jamais pour peaufiner un truc de ce style là (y compris ceux qui se cognaient un scandisk à chaque boot par exemple).
# Re: Pour un boot plus rapide de Linux
Posté par tgl . En réponse à la dépêche Pour un démarrage plus rapide de Linux. Évalué à 1.
Ceci dit c'est pas parceque c'est un faux problème qu'on peut pas bavarder sur ses solutions... Alors allons-y: le fameux boot parrallèle est implémenté depuis des mois sous gentoo (pour rappel la gentoo n'est pas basée sur le machin avec les liens symboliques Sxxtruc/Kxxtruc, mais sur des scripts qui déclarent leurs dépendances mutuelles), et je l'avais testé quand c'était à debugguer. Résultat (de tête):
- aucun gain quand on a peu de services (ouah, quelle surprise)
- une poignée (une pincée?) de secondes gagnée avec plus de services (ouah, quelle surprise aussi)
Chez moi, le plus long à lancer devait être cups, alors que rien n'en dépendais je crois, donc c'est surtout lui qui fesait gagner des secondes. Mysql peut être aussi. Enfin bon, c''etait pas la r'evolution, et la sortie était un peu confuse si un script de démarrage affichait plusieurs lignes (oui, y'aurait moyen de bidouiller pour éviter ça). Et puis peut-être que pour être plus efficace il faudrait une gestion des dépendances des scripts un peu plus molle, acceptant de lancer certains trucs parcequ'on sait que leur dépendances seront bientôt satisfaites (je m'étais dit ça surtout pour xdm, qui attendait je sais plus quoi de pas indispensable).
Bref, ce que raconte l'auteur de l'article est pas faux, mais pas vraiment intérressant non plus, ni vraiment nouveau, et en plus je l'ai pas lu.
[^] # Re: Interview de Jonathan Schwartz
Posté par tgl . En réponse à la dépêche Interview de Jonathan Schwartz. Évalué à 3.
Tiens c'est rigolo ça, il m'a fallu ton commentaire pour que je réalise que en fait ça n'était pas évident que c'était d'eux qu'il s'agissait :)
[^] # Re: Livre en français sur OpenOffice.org 1.1
Posté par tgl . En réponse à la dépêche Livre en français sur OpenOffice.org 1.1. Évalué à 7.
Et chez Dunod, «Les outils de l'étudiant sous Linux : StarOffice et OpenOffice», que j'avais offert à ma maman qui a bien aimé, mais moi je peux pas vraiment en dire plus ne l'ayant pas lu :)
http://www.dunod.com/pages/ouvrages/ficheouvrage.asp?Pro_Code_GPE=4(...)
# Course aux paquets...
Posté par tgl . En réponse à la dépêche Sortie de Xawdecode [xdTV] version 1.8.0. Évalué à 6.
- xawdecode-1.8.0 est dans Portage depuis dimanche;
- un ebuild pour le plugin 1.4.4 est aussi disponible ici: http://tdegreni.free.fr/xawdecode/xawdecode-plugin-1.4.4.ebuild(...)
Mais il est aussi dispo pour Debian, Suse 8.2 et MDK9.1 sur Sourceforge, alors, une fois n'est pas coutume, je déclare tout le monde exaequo :)
[^] # Re: La GNU Free Documentation License et Debian
Posté par tgl . En réponse à la dépêche La GNU Free Documentation License et Debian. Évalué à 2.
> pour en discuter quand même !
Oserai-je suggérer que justement les gens sensés trouvent mieux à faire ?
[^] # De la caricature conclusive: critique et application.
Posté par tgl . En réponse à la dépêche Enjeux des Brevets Logiciels en Europe. Évalué à 5.
> Microsoft, qui vise à établir son pouvoir absolu sur TOUTE la chaîne
> de l'information, est ici d'obtenir le dernier outil qui lui manque
> pour étouffer dans l'uf la SEULE concurrence qu'elle craigne : le
> logiciel libre.
Bon, je te l'ai déjà dis sur la mailing list de gulliver, mais j'aime bien insister, ce paragraphe il est vraiment pas à la hauteur du reste... Parler des LL, oui, mais pourquoi réduire finallement toute la problématique à cet aspect, à mon avis assez mineur ? «L'enjeu c'est ÇA!» Bah nan, ce n'en est qu'un petit bout, tu le montres d'ailleurs plus ou moins tout du long du courrier. Je crains que cette caricature conclusive ne décrédibilise un peu tout le reste.
Sinon, en critique un peu plus constructive, je suggère un lien vers le site de la FFII, personnellement c'est là que j'ai vu les analyses du texte et de ses travers les plus détaillées.
Quant au lien sur brevets-logiciels.info, bah... je suis assez mitigé. Pour moi c'est un bon site pour l'organisation de l'action militante, mais pas un site à présenter aux députés. Le côté «lobbying howto», avec les listes d'adresse, les lettres types et les recettes en tout genre est bien trop présent pour que ce soit rendu publique. C'est un peu leur écrire noir sur blanc qu'on les prend pour des cons, on devrait attendre l'après vote pour ça. Mais bon, je sais, c'est trop tard, et puis c'est quand même moins chiant à lire que les pinaillages juriques de la FFII, et puis les wikis c'est bien(tm), et puis on est prem's dans google que même si il est mal(tm) c'est quand même bien(tm), etc.
[^] # Re: pdf vs html
Posté par tgl . En réponse à la dépêche Enjeux des Brevets Logiciels en Europe. Évalué à 4.
-- Thomas Walraet, in Guide du Dlfpien Culotté
[^] # Re: Epiphany vs. Galeon
Posté par tgl . En réponse à la dépêche GNOME 2.4 est disponible. Évalué à 1.
[...]
- Gestion très complète des bookmarks
Tiens bah tant que j'ai un galeoneur sous la main, puis-je lui poser une petite question ?
Merci, bon bah une deuxième alors : est-ce que dans les galeon-1.3 récents le gestionnaire de bookmark est complètement "panelisable" comme il l'est dans le 1.2 ? Parceque moi, ça, c'est vraiment le truc dont je peux plus me passer : j'ai toujours mes bookmarks dans le panel avec le mode édition enclenché, et je range, je renomme, je copie, je commente, etc., sans jamais le moindre click droit, popup, et autres fenêtres superflue. Et du coup Galeon 1.2 m'a permis d'atteindre pour la première fois de ma vie une collection de bookmarks toujours bien organisée.
Mais à chaque fois que j'ai testé un 1.3, j'ai été atrocement déçu de voir que le panel n'était plus qu'un simple affichage de l'arbre, sans composant d'édition intégré. Du coup, à chaque coup, je suis repassé à la 1.2. La dernière fois c'était y'a 3-4 mois, et comme j'ai un peux la flemme de tester (passer mozilla en gtk2, c'est lourd), et bah je demande...
Merci :)
[^] # Re: Test de la Gentoo 1.4
Posté par tgl . En réponse à la dépêche Test de la Gentoo 1.4. Évalué à 2.
Ça c'est sûr que faut pas être au giga près si on a pas une autre machine pour les compilations, c'est vraiment inhérent au principe d'une distrib source. En ça je comprends que ça convienne pas à tout le monde. Et il manque vraiment un système moins "manuel" pour le déploiement: genre pas possible pour l'instant de maintenir à jour simplement une gentoo sur un P100 avec 200Go de disque, qui ferait serveur mail, malgré une machine de compil à côté. La notion de cibles (par exemple des machines d'archi différentes, sans portage installé dessus, et sans bien sûr la machinerie de compilation) n'est pas encore intégrée à portage. Tout ce qu'on peut faire facilement avec gentoo pour de telles cibles, c'est une pseudo slackware (on leur prépare des tbz2 quoi, à installer à la main).
«un temps de compil vraiment trop long pour gagner trois fois rien»
Gagner en quoi, en "perf" ? Bah oui c'est clair. Mais en souplesse c'est assez incomparable (use flags, etc.).
«une stabilité inferieure a debian.»
Des détails stp ?
[^] # Re: Test de la Gentoo 1.4
Posté par tgl . En réponse à la dépêche Test de la Gentoo 1.4. Évalué à 3.
T'as pas dû souvent en écrire des spec de pacquets toi.
«Tout ce qui compte, c'est la facilité réellement fournie et non le nom du paquet.»
J'aurai dis «et non le nom du truc dont on dépend». Ce qui sous Gentoo correspond par définition à la notion de paquet virtuel (genre si on a besoin d'un driver alsa ("virtual/alsa"), on peut se satisfaire soit d'un kernel 2.5/6, soit du driver pour les 2.4).
«L'héritage est aussi utile car il permet de limiter les nombres de dépendances et ne pas tomber dans l'ingérable.»
Je ne vois pas ce que tu veux dire, mais si c'est juste que si "A dépend de B et C" mais que "B dépend aussi de C" alors on peut se contenter de dire que "A dépend de B" (enfin bref pas lister systématiquement tout jusqu'à la glibc), et que ça qu'est génial c'est qu'on peut dire "installe A" et qu'il t'installera les trois, bah c'est pas vraiment un scoop, et je connais pas de système de paquets qui gère pas au moins ça. (Enfin si, je sais plus si rpm le fait, ou le faisais à une époque lointaine en tout cas, ou si c'est urpmi qui le rajoute).
«Rpm peut aussi définir des dépendances virtuels (style require: kde)»
Je sais pas dans le monde .rpm, mais dans le monde .deb c'était plutôt ce qu'on appelait des meta-paquets. Rien à voir avec la notion de paquet virtuel sus-citée.
«des dépendances sur des fichiers»
on en reviens au bon vieux nom/emplacements bien connus. Franchement, je préfère de loin l'abstraction des virtuals (tu fait comment avec un nom de fichier pour dire: un codec divx ?)
«tes fichiers de configuration seront conservés»
Bah manquerai plus que l'install d'un paquet t'écrase ta config existante? Sérieux, c'est encore vraiment la base. (Et la je commence à flipper en me disant que si tu nous les fait tous comme ça je suis pas couché.)
«En fait le système de génération des dépendances utilise des plugins et rien ne t'empêche de devopper de nouveaux plugins»
"inherit plugin" dans un ebuild (Ah nan merde, ça concerne pas que les dépendances mais ça permet de surcharger n'importe quelle methode et d'en définir de nouvelles utilitaires...)
«par exemple sur les symboles fournis par le noyau pour vérifier si un module noyau peut-être installé et marchera»
Faut vraiment être sur une distrib à binaire pour voir ça. C'est merveilleux tellement c'est aller loin contre le bon sens et la simplicité.
«T'as un gnome-2.2.2 spécifique qui utilise un libgnome-2.2.2 spécifique incompatible avec la branche 2.2, si un gnome-2.2.3 "standard" sort, il n'écrasera pas ta version spécifique mais un gnome-2.2.3 avec tes spécificités (marqués par le tag Epoch) sera un candidat pour la mise à jours.»
Cool, ça vous fait un USE flag. Aller, encore un petit effort, c'est presque ça. Mais gaffe à l'explosion combinatoire: 2^(nbre de USE flags) est exponentiel en le nombre de USE flags. Ça va en faire des versions spécifiques à compiler pour RedHat.
«rpm gére aussi les mises à jours sur plusieurs paquets et non seulement sur un seul.»
Ouahouuu!
«Rpm gère les paquets absolètes.»
Pur narcissisme.
«J'en suis sûre. »
Moi je suis sûr grâce à ton post que bientôt rpm aura rattrapé son retard sur apt. Encore qlqs amélioration (vrais paquets virtuels, héritage entre specs, gestion explicite des masques de paquets, mélange aisé de 3 niveaux de stabilité des paquets, système de merge des fichiers de conf, etc), et il sera au niveau de portage pour ce sur quoi il est raisonnable de les comparer. Mais il n'approche qu'à peine (et c'est bien normal, mauvais choix, mauvais résultats) la souplesse que peut offrir un système basé sur les sources (use flags, optimisation, drivers, etc.). Et je n'ai pas parlé d'un autre avantage des ebuilds: le système est tellement simple, et la nécéssité de compiler étant de toute façon là, qu'il devient très vite naturel de modifier un peu l'existant à sa sauce, de se faire ses propres révision bumps, d'écrire des ebuilds nouveaux plutôt que de make installer dans /usr/local, etc. De ce que je vois sur le forum, ou je passe un peu de temps, le "PORTAGE_OVERLAY", c'est à dire ton repository d'ebuilds persos, est une chose connue et utilisée par la quasi totalité des utilisateurs, au moins ponctuellement. Alors que franchement, sur une distrib à la redhat, c'est quoi la proportion d'utilisateurs qui ont un jour fait leur propre srpm ?
[^] # Re: Deux nouveaux lecteurs SVG
Posté par tgl . En réponse à la dépêche Deux nouveaux lecteurs SVG. Évalué à 1.
Comme PDF par Adobe non ? Ah oui mais non, là on a des implémentations potables sous Linux, donc c'est bon on s'en fout. Faut croire que le contrôle du format n'est pas le fond du problème...